Concurrent Logic Timing

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 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

On Dec 4, 5:32 pm, rickman <gnu...@gmail.com> wrote:



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.

On Dec 4, 8:05 pm, Jonathan Ross <TheProperN...@psychophile.com
wrote:



On Dec 4, 5:32 pm, rickman <gnu...@gmail.com> wrote:

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.

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...

On 5 Dez., 04:55, rickman <gnu...@gmail.com> wrote:



On Dec 4, 8:05 pm, Jonathan Ross <TheProperN...@psychophile.com
wrote:

On Dec 4, 5:32 pm, rickman <gnu...@gmail.com> wrote:

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.

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

On Dec 6, 5:09 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:





On 5 Dez., 04:55, rickman <gnu...@gmail.com> wrote:

On Dec 4, 8:05 pm, Jonathan Ross <TheProperN...@psychophile.com
wrote:

On Dec 4, 5:32 pm, rickman <gnu...@gmail.com> wrote:

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.

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

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 -

On Dec 6, 8:57 am, rickman <gnu...@gmail.com> wrote:





On Dec 6, 5:09 am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

On 5 Dez., 04:55, rickman <gnu...@gmail.com> wrote:

On Dec 4, 8:05 pm, Jonathan Ross <TheProperN...@psychophile.com
wrote:

On Dec 4, 5:32 pm, rickman <gnu...@gmail.com> wrote:

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.

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

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;- Hide quoted text -

- Show quoted text -

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

On Dec 6, 1:00 pm, Andy <jonesa...@comcast.net> wrote:

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