Concurrent Logic Timing

[rickman]

I suppose this is something that you need to expect, but I just have
never come across this before. I have some concurrent logic equations
using integers where one input common to two assignments changes and
because one gets updated before the other, one is set to a value that
is outside the range of the integer and flags an error in
simulation.

C <= B - A * stuff;
D <= A + C; -- A changes and puts D outside of its range until C is
updated

In the real world, this is not really an issue since all sorts of
intermediate states are expected when doing arithmetic. But VHDL
doesn't seem to accommodate this well. The only way I can think of to
fix this, without changing the logic, is to do these calculations
inside a combinatorial process using variables. Then I can control
the sequence of updates explicitly.

The only other thing I can think is to assign A to A' and use A' in
place of A in the assignment for D. That may still allow an error,
but if A'' is used, then there will be two delta delays in D
assignment path. However, if C grows because A has shrunk, then that
could cause the same sort of out of bounds error on D.

Is there another way make this work that isn't so cumbersome?

Rick

 

[glen herrmannsfeldt]

I suppose this is something that you need to expect, but I just have
never come across this before. I have some concurrent logic equations
using integers where one input common to two assignments changes and
because one gets updated before the other, one is set to a value that
is outside the range of the integer and flags an error in
simulation.

C <= B - A * stuff;
D <= A + C; -- A changes and puts D outside of its range until C is
updated

In the real world, this is not really an issue since all sorts of
intermediate states are expected when doing arithmetic. But VHDL
doesn't seem to accommodate this well.

I don't think verilog has this problem, but it might just be
because I would do it with reg [32] and not integer. I think
you can do something similar to reg [32] in VHDL, and likely
avoid the problem.

(snip)

-- glen

 

[Jonathan Ross]

I suppose this is something that you need to expect, but I just have
never come across this before.  I have some concurrent logic equations
using integers where one input common to two assignments changes and
because one gets updated before the other, one is set to a value that
is outside the range of the integer and flags an error in
simulation.

C <= B - A * stuff;
D <= A + C;  -- A changes and puts D outside of its range until C is
updated

In the real world, this is not really an issue since all sorts of
intermediate states are expected when doing arithmetic.  But VHDL
doesn't seem to accommodate this well.  The only way I can think of to
fix this, without changing the logic, is to do these calculations
inside a combinatorial process using variables.  Then I can control
the sequence of updates explicitly.

The only other thing I can think is to assign A to A' and use A' in
place of A in the assignment for D.  That may still allow an error,
but if A'' is used, then there will be two delta delays in D
assignment path.  However, if C grows because A has shrunk, then that
could cause the same sort of out of bounds error on D.

Is there another way make this work that isn't so cumbersome?

Rick

Try using either the SIGNED or UNSIGNED type instead of integer.

 

[rickman]

Try using either the SIGNED or UNSIGNED type instead of integer.

I see what the two of you are saying. By using integer it will be
tested for range bounds. std_logic_vector types don't get that level
of analysis. The range testing is useful when it is done properly.
By properly, I mean so that it is checking the logic, not your skill
at eliminating glitches in combinatorial logic...

For the short term I put it in a combinatorial process. The other
thing that would have been pretty easy would be to combine the two
into one assignment. The first assignment was just an intermediate to
facilitate debugging.

I guess I'm just surprised that I've never been bitten by this
before.

Rick

 

[sridar]

Re:

But, there will be no problem, when it is programmed in hardware. Your concern is for simulation?

 

[Kolja Sulimma]

I see what the two of you are saying.  By using integer it will be
tested for range bounds.  std_logic_vector types don't get that level
of analysis.  The range testing is useful when it is done properly.
By properly, I mean so that it is checking the logic, not your skill
at eliminating glitches in combinatorial logic...

Use signed or unsigned from the numeric_std package and perform the
range check yourself
at times when you know the intermediate states have settled:

if rising_edge(clk) then
assert c >= lower_bound and c <= upper_bound report "C out of
range";
end if;

I believe that virtually all HDL-Designers should use a lot more
assertions than they do.
(Myself included.)

Kolja

 

[rickman]

Use signed or unsigned from the numeric_std package and perform the
range check yourself
at times when you know the intermediate states have settled:

if rising_edge(clk) then
  assert c >= lower_bound and c <= upper_bound report "C out of
range";
end if;

I believe that virtually all HDL-Designers should use a lot more
assertions than they do.
(Myself included.)

Kolja

That's an interesting approach. I'm not accustomed to using
assertions in my synthesizable code, but there is certainly no reason
not to.

Rick

 

[Newman]

That's an interesting approach.  I'm not accustomed to using
assertions in my synthesizable code, but there is certainly no reason
not to.

Rick- Hide quoted text -

- Show Iquoted text -

I have not tried it, but what is below may do what you want also.

signal G_sv : signed(10 downto 0);
signal Signed_int : integer range -128 to 127; -- specified valid
range here
..................

if rising_edge(clk) then
Signed_int <= TO_INTEGER(G_sv);
end if;

 

[Newman]

I have not tried it, but what is below may do what you want also.

signal G_sv             : signed(10 downto 0);
signal Signed_int   : integer range -128 to 127;   -- specified valid
range here
.................

if rising_edge(clk) then
  Signed_int <=   TO_INTEGER(G_sv);
end if;- Hide quoted text -

- Show quoted text -

I might have wrongly assumed that the combinatorial result was going
to be eventually registered. Oops!

 

[Andy]

I think I would use a function for the intermediate calculation, and
then call the function in both concurrent assignment statements per
the original implementation.

Integers give you the benefits of bounds checking in simulation (even
below the 2^n granularity if desired), and a big improvement in
simulation performance, especially if integers are widely used in the
design (instead of vectors).

Andy

 

[rickman]

I think I would use a function for the intermediate calculation, and
then call the function in both concurrent assignment statements per
the original implementation.

Integers give you the benefits of bounds checking in simulation (even
below the 2^n granularity if desired), and a big improvement in
simulation performance, especially if integers are widely used in the
design (instead of vectors).

Andy

I know everyone says that integers run faster, but is this a
significant effect? Has it been measured or at least verified on
current simulators?

Rick

 

[Andy]

I know everyone says that integers run faster, but is this a
significant effect?  Has it been measured or at least verified on
current simulators?

Rick

A few years back, I had a design for a small FPGA with several modules
on a common bus. I started out with unsigned(4 downto 0) for the
address, and each module decoded its own address (each was given a
generic for address and size). Then I changed only that address to a
natural with equivalent range. Just that one change sped up my RTL
simulation from over 2.5 hours down to less than 1 hour. I considered
it very significant...

Andy