Concurrent Logic Timing

Discussion in 'VHDL' started by rickman, Dec 4, 2010.

  1. rickman

    rickman Guest

    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
     
    rickman, Dec 4, 2010
    #1
    1. Advertising

  2. In comp.arch.fpga rickman <> 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.


    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
     
    glen herrmannsfeldt, Dec 4, 2010
    #2
    1. Advertising

  3. On Dec 4, 5:32 pm, rickman <> 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.
     
    Jonathan Ross, Dec 5, 2010
    #3
  4. rickman

    rickman Guest

    On Dec 4, 8:05 pm, Jonathan Ross <>
    wrote:
    > On Dec 4, 5:32 pm, rickman <> 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...

    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
     
    rickman, Dec 5, 2010
    #4
  5. rickman

    sridar

    Joined:
    Jun 5, 2007
    Messages:
    51
    Re:

    But, there will be no problem, when it is programmed in hardware. Your concern is for simulation?
     
    sridar, Dec 6, 2010
    #5
  6. On 5 Dez., 04:55, rickman <> wrote:
    > On Dec 4, 8:05 pm, Jonathan Ross <>
    > wrote:
    >
    >
    >
    > > On Dec 4, 5:32 pm, rickman <> 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
     
    Kolja Sulimma, Dec 6, 2010
    #6
  7. rickman

    rickman Guest

    On Dec 6, 5:09 am, Kolja Sulimma <> wrote:
    > On 5 Dez., 04:55, rickman <> wrote:
    >
    >
    >
    > > On Dec 4, 8:05 pm, Jonathan Ross <>
    > > wrote:

    >
    > > > On Dec 4, 5:32 pm, rickman <> 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
     
    rickman, Dec 6, 2010
    #7
  8. rickman

    Newman Guest

    On Dec 6, 8:57 am, rickman <> wrote:
    > On Dec 6, 5:09 am, Kolja Sulimma <> wrote:
    >
    >
    >
    >
    >
    > > On 5 Dez., 04:55, rickman <> wrote:

    >
    > > > On Dec 4, 8:05 pm, Jonathan Ross <>
    > > > wrote:

    >
    > > > > On Dec 4, 5:32 pm, rickman <> 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;
     
    Newman, Dec 6, 2010
    #8
  9. rickman

    Newman Guest

    On Dec 6, 9:30 am, Newman <> wrote:
    > On Dec 6, 8:57 am, rickman <> wrote:
    >
    >
    >
    >
    >
    > > On Dec 6, 5:09 am, Kolja Sulimma <> wrote:

    >
    > > > On 5 Dez., 04:55, rickman <> wrote:

    >
    > > > > On Dec 4, 8:05 pm, Jonathan Ross <>
    > > > > wrote:

    >
    > > > > > On Dec 4, 5:32 pm, rickman <> 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 might have wrongly assumed that the combinatorial result was going
    to be eventually registered. Oops!
     
    Newman, Dec 6, 2010
    #9
  10. rickman

    Andy Guest

    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
     
    Andy, Dec 6, 2010
    #10
  11. rickman

    rickman Guest

    On Dec 6, 1:00 pm, Andy <> 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
     
    rickman, Dec 6, 2010
    #11
  12. rickman

    Andy Guest

    On Dec 6, 12:50 pm, rickman <> wrote:
    > On Dec 6, 1:00 pm, Andy <> 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


    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
     
    Andy, Dec 6, 2010
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nicolas Matringe
    Replies:
    9
    Views:
    770
    Mike Treseler
    Jun 14, 2004
  2. Taras_96

    Concurrent Assignment

    Taras_96, Apr 1, 2005, in forum: VHDL
    Replies:
    6
    Views:
    8,684
    Taras_96
    Apr 4, 2005
  3. Taras_96
    Replies:
    5
    Views:
    2,260
    Taras_96
    Apr 14, 2005
  4. Pep
    Replies:
    6
    Views:
    876
  5. spike
    Replies:
    8
    Views:
    1,546
    Steve Holden
    Feb 9, 2010
Loading...

Share This Page