Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Is this legal?

Reply
Thread Tools

Is this legal?

 
 
Valentin Tihomirov
Guest
Posts: n/a
 
      10-21-2003
architecture ARCH orRX_UNIT is
signal BitPos: integer range 0 to 10;
begin

SAMPLING : process(CLK)
begin
if Rising_Edge(CLK) then
BitPos <= BitPos + 1; -- increase by default
if BitPos = 10 then -- stop bit
BitPos <= 0;
DONE <= '1'; -- signal available data
else
DATA[BitPos] <= Rx; -- store data bit
end if;
end process;

end ARCH;


Simulator stops complaining about that string where BitPos is incremented.
In fact, the logic is a bit more complex and using this style with default
assertion is very convenient. What are the problems inherent to the
situation where 11 is calculated to be written into variable that can only
keep vales in range 0..10? The calculated value 11 is ignored in any case.


 
Reply With Quote
 
 
 
 
Peter Molesworth
Guest
Posts: n/a
 
      10-21-2003
On Tue, 21 Oct 2003 22:13:42 +0300, Valentin Tihomirov
<(E-Mail Removed)> wrote:

> architecture ARCH orRX_UNIT is
> signal BitPos: integer range 0 to 10;
> begin
>
> SAMPLING : process(CLK)
> begin
> if Rising_Edge(CLK) then
> BitPos <= BitPos + 1; -- increase by default
> if BitPos = 10 then -- stop bit
> BitPos <= 0;
> DONE <= '1'; -- signal available data
> else
> DATA[BitPos] <= Rx; -- store data bit
> end if;
> end process;
>
> end ARCH;
>
>
> Simulator stops complaining about that string where BitPos is
> incremented.
> In fact, the logic is a bit more complex and using this style with
> default
> assertion is very convenient. What are the problems inherent to the
> situation where 11 is calculated to be written into variable that can
> only
> keep vales in range 0..10? The calculated value 11 is ignored in any
> case.
>
>


Hi Valentin,

The only things I can say about the above is that when BitPos = 10 you are
assigning a value to BitPos in two places simmultaneously. In this case it
dosen't really matter as the assignment BitPos <= BitPos + 1 will result
in a value of 0 anyway and not 11. If you had not specified a range when
you declared BitPos you would have a the problem of the signal have two
drivers of a different value. The other thing to note is that DONE and
DATA are only assigned in one half of the second IF statement and
therefore latches are inferred. Other than that it's basically okay. Also
you probably should have a reset signal to initialise BitPos to a known
value. Depending on your target device registers may initialize to a known
value or they may be undefined. To summarise I would have written the
process as follows:

SAMPLING : process (nReset, Clk)
begin
if (nReset = '0') then
BitPos <= 0;
DONE <= '0';
DATA <= (others => '0');
elsif rising_edge (Clk) then
BitPos <= BitPos + 1;
if (BitPos = 10) then
DONE <= '1';
DATA <= DATA;
else
DONE <= DONE;
DATA[BitPos] <= Rx;
end if;
end if;
end process;

Note that in the above the DATA assignment in the second half of the IF
statement only assigns to one element of DATA so latches are inferred on
the others bits. I personally don't like inferred latches but in this case
it is okay and is the most elegant way of doing it.

I hope this has been of some use to you.

Cheers,

Pete.
 
Reply With Quote
 
 
 
 
Mike Treseler
Guest
Posts: n/a
 
      10-21-2003
Valentin Tihomirov wrote:

> Simulator stops complaining about that string where BitPos is incremented.
> In fact, the logic is a bit more complex and using this style with default
> assertion is very convenient.


With a signal, it doesn't matter if you put

BitPos <= BitPos + 1;

before or after the limit check.
The value tested is from the previous loop.

I find that using process variables to
mold values makes the logic more understandable.

also

DATA[BitPos] <= Rx;

ought to be inside the clk clause.
Nothing should be in the else clause.

> What are the problems inherent to the
> situation where 11 is calculated to be written into variable that can only
> keep vales in range 0..10?


The simulator will enforce your limits.
Why not use unsigned(3 downto 0) or the range 0 to 15.
At least four bits will be synthesized in any case.

-- Mike Treseler


 
Reply With Quote
 
Valentin Tihomirov
Guest
Posts: n/a
 
      10-22-2003
Thanks for the attempt to help me.

1. If I assign a signal inside synchonized section I do not surprise getting
flip-flop. Using default values lets to avoid many assignment statemnts in
the complex branching. It is the first lesson of VHDL class.

2. The second lesson learns that assignments inside process are not
concurrent, they are serial as opposed to concurrent blocks.

3. I could not understand the correct way of dealing with BitPos counter in
my example. How can I highlight that the register is intended to hold values
only in range 0 to 10. And what goes on when 11 is asserted to NEXT_VALUE
but is never asserted to the value? This is a corner situation.


 
Reply With Quote
 
Peter Molesworth
Guest
Posts: n/a
 
      10-22-2003
On Wed, 22 Oct 2003 12:18:14 +0300, Valentin Tihomirov
<(E-Mail Removed)> wrote:

> Thanks for the attempt to help me.
>
> 1. If I assign a signal inside synchonized section I do not surprise
> getting
> flip-flop. Using default values lets to avoid many assignment statemnts
> in
> the complex branching. It is the first lesson of VHDL class.


Yes I agree that this makes the vhdl much neater rather than having to
explicitly declare all other assignments. The only reason I try to avoid
inferred latches is to stop warnings from the synthesis tool. I find that
if there are loads of warnings about inferred latches it is easy to miss a
real warning that I should be concerned about. Sorry if I came across as
telling you stuff you already knew, that was not my intention.

> 2. The second lesson learns that assignments inside process are not
> concurrent, they are serial as opposed to concurrent blocks.
>
> 3. I could not understand the correct way of dealing with BitPos counter
> in
> my example. How can I highlight that the register is intended to hold
> values
> only in range 0 to 10. And what goes on when 11 is asserted to NEXT_VALUE
> but is never asserted to the value? This is a corner situation.
>
>


As you have declared BitPos with a range 0 to 10 the simulator will do the
range checking for you so you need not worry about it. An assertion to 11
will not occur as it will automatically wrap the value back to 0. For
synthesis you will end up with a 4-bit counter which can have a range 0 to
15. The synthesis tool will know from your type declaration that 11 to 15
are not allowed values and will generate additional logic in the counter
to rollover once 10 is reached. If you want to make it explicit anyway
then the example I provided can be modified by simply moving the
assignment to BitPos into the second IF statement. so my example would
become:

SAMPLING : process (nReset, Clk)
begin
if (nReset = '0') then
BitPos <= 0;
DONE <= '0';
DATA <= (others => '0');
elsif rising_edge (Clk) then
if (BitPos >= 10) then
BitPos <= 0;
DONE <= '1';
DATA <= DATA;
else
BitPos <= BitPos + 1;
DONE <= DONE;
DATA[BitPos] <= Rx;
end if;
end if;
end process;

I hope this is what you are after.

Cheers,

Pete.
 
Reply With Quote
 
Colin Marquardt
Guest
Posts: n/a
 
      10-24-2003
Peter Molesworth <(E-Mail Removed)> writes:

> if (BitPos >= 10) then
> BitPos <= 0;
> [...]


Or, even nicer,
if (BitPos >= BitPos'high) then
BitPos <= BitPos'low; -- if this is what's wanted

Cheers,
Colin
 
Reply With Quote
 
Peter Molesworth
Guest
Posts: n/a
 
      10-24-2003
>
>> if (BitPos >= 10) then
>> BitPos <= 0;
>> [...]

>
> Or, even nicer,
> if (BitPos >= BitPos'high) then
> BitPos <= BitPos'low; -- if this is what's wanted
>
> Cheers,
> Colin


Yes very good point. I do use this technique myself as it can make
maintaining things much easier as there will be less parts of the code to
change if the range of something needs to change.

Cheers,

Pete.
 
Reply With Quote
 
Paul Uiterlinden
Guest
Posts: n/a
 
      10-24-2003
Peter Molesworth wrote:

>>
>>> if (BitPos >= 10) then
>>> BitPos <= 0;
>>> [...]

>>
>> Or, even nicer,
>> if (BitPos >= BitPos'high) then
>> BitPos <= BitPos'low; -- if this is what's
>> wanted
>>
>> Cheers,
>> Colin

>
> Yes very good point. I do use this technique myself as it can make
> maintaining things much easier as there will be less parts of the
> code to change if the range of something needs to change.


Indeed. Less "magical numbers" is better.

But the example won't work: the attributes 'high and 'low only are
allowed types and arrays. So the example should be something like
this:

SUBTYPE BitPos_type IS integer RANGE 0 TO 10;
...
IF BitPos >= BitPos_type'HIGH THEN
BitPos <= BitPos_type'LOW;

Paul.
 
Reply With Quote
 
Valentin Tihomirov
Guest
Posts: n/a
 
      10-28-2003


> DATA[BitPos] <= Rx;
>
> ought to be inside the clk clause.
> Nothing should be in the else clause.


Why to mention this? It is inside clk.




> > What are the problems inherent to the
> > situation where 11 is calculated to be written into variable that can

only
> > keep vales in range 0..10?

>
> The simulator will enforce your limits.


I understand that it inforces. I wait anyone who explains me which limits it
enforces. I never assign 11 to the variable.I just intend but I have a logic
to refuse this assignment. That is why I think my code is right.




> Why not use unsigned(3 downto 0) or the range 0 to 15.
> At least four bits will be synthesized in any case.
>
> -- Mike Treseler


Curious to know a well.


 
Reply With Quote
 
Valentin Tihomirov
Guest
Posts: n/a
 
      10-28-2003
> As you have declared BitPos with a range 0 to 10 the simulator will do the
> range checking for you so you need not worry about it.


I do worry because ModelSim does. It abandons simulation alerting that 11
cannot be assigned to BitPos. This also means that no aoutomatic rollback
from 10 to 0 is generated. Therefore, these your words are not true and
making the wrap explicit makes sense.

> An assertion to 11
> will not occur as it will automatically wrap the value back to 0. For
> synthesis you will end up with a 4-bit counter which can have a range 0 to
> 15. The synthesis tool will know from your type declaration that 11 to 15
> are not allowed values and will generate additional logic in the counter
> to rollover once 10 is reached. If you want to make it explicit anyway
> then the example I provided can be modified by simply moving the
> assignment to BitPos into the second IF statement. so my example would
> become:





 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments