Is this legal?

Discussion in 'VHDL' started by Valentin Tihomirov, Oct 21, 2003.

  1. 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.
    Valentin Tihomirov, Oct 21, 2003
    #1
    1. Advertising

  2. On Tue, 21 Oct 2003 22:13:42 +0300, Valentin Tihomirov
    <> 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.
    Peter Molesworth, Oct 21, 2003
    #2
    1. Advertising

  3. 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
    Mike Treseler, Oct 21, 2003
    #3
  4. I've asked about not assigning value 11 to integer (0..10)

    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.
    Valentin Tihomirov, Oct 22, 2003
    #4
  5. Re: I've asked about not assigning value 11 to integer (0..10)

    On Wed, 22 Oct 2003 12:18:14 +0300, Valentin Tihomirov
    <> 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.
    Peter Molesworth, Oct 22, 2003
    #5
  6. Re: I've asked about not assigning value 11 to integer (0..10)

    Peter Molesworth <> 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
    Colin Marquardt, Oct 24, 2003
    #6
  7. Re: I've asked about not assigning value 11 to integer (0..10)

    >
    >> 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.
    Peter Molesworth, Oct 24, 2003
    #7
  8. Re: I've asked about not assigning value 11 to integer (0..10)

    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.
    Paul Uiterlinden, Oct 24, 2003
    #8

  9. > 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.
    Valentin Tihomirov, Oct 28, 2003
    #9
  10. I do worry because ModelSim does

    > 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:
    Valentin Tihomirov, Oct 28, 2003
    #10
  11. Valentin Tihomirov wrote:
    >> 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.


    You're right. Sorry.


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


    You can answer this question yourself just by running
    a simulation and looking at the waveform values.

    You might find that:

    if BitPos = 10 then -- stop bit

    is comparing the value that existed at
    the previous clock so that the you end
    up off by one on your limit.

    Try it and see.

    -- Mike Treseler
    Mike Treseler, Oct 28, 2003
    #11
  12. >
    >
    >> > 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.
    >
    >


    Valentin,

    That will teach me to try and answer a post too quickly! I just simulated
    your code sample in modelsim and I now see why you are asking the question
    again. Your absolutely right, your assignment BitPos <= BitPos + 1 does
    cause it to go wrong in the simulation. The reason for this is that when
    the value of BitPos is 10 the "Next Cycle" value calculated becomes out of
    the range of BitPos as the result is just an integer so the simulator
    throws an error. Fortunately the solution is simple. You can either create
    a subtype BitPosType to be your integer 0 to 10 and then convert your
    BitPos + 1 (which is just an integer not BitPosType) as follows:

    architecture ARCH of RX_UNIT is
    subtype BitPosType is integer range 0 to 10;
    signal BitPos: BitPosType;
    begin

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

    end ARCH;

    or move the increment of BitPos inside the second if clause as follows:

    architecture ARCH of RX_UNIT is
    signal BitPos: integer range 0 to 10;
    begin

    SAMPLING : process(CLK)
    begin
    if Rising_Edge(CLK) then
    if BitPos >= 10 then -- stop bit
    BitPos <= 0; -- reset counter to 0
    DONE <= '1'; -- signal available data
    else
    BitPos <= BitPos + 1; -- otherwise increment
    DATA(BitPos) <= Rx; -- store data bit
    end if;
    end if;
    end process;

    end ARCH;

    I hope this is what you are after.

    Cheers,

    Pete.
    Peter Molesworth, Oct 28, 2003
    #12
  13. > >>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.

    >
    > You can answer this question yourself just by running
    > a simulation and looking at the waveform values.
    >
    > You might find that:
    >
    > if BitPos = 10 then -- stop bit
    >
    > is comparing the value that existed at
    > the previous clock so that the you end
    > up off by one on your limit.
    >
    > Try it and see.
    >
    > -- Mike Treseler


    May be "stop bit" expression is misleadind, simulator stops in different
    place.

    if SampleCnt = 7 then
    BitPos <= BitPos + 1; -- ModelSim stops here
    if BitPos = 10 then -- STOP condition (UART stop bit)
    BitPos <= 0;
    .. -- check stop bit is '1'


    I'm writing here just because when Sample = 7 and BitPos = 10 ModelSim shows
    me message "Value 11 is out of range 0 to 10" and does not proceed. I
    understand which signals I have at which cycles. There is no condition where
    BitPos = 11; my logic prevents this. Please, tell me where is my (0..10)
    constraint violated? I expect simulator to warn me only when things go wrong
    due to inconsistency or a hole in my logic. I don't not want it to stall
    when everithing is going as planed.

    May be the problem is in a ref. point, a tradition or a definition but not
    in my logic? Logically, I could not understand why does millenium start at
    year 2001 until I was informed that the first century started in year 001.
    Valentin Tihomirov, Oct 28, 2003
    #13
  14. Re: I do worry because ModelSim does

    On Tue, 28 Oct 2003 23:17:51 +0200, Valentin Tihomirov
    <> wrote:

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


    See my other post aswell but basically:

    BitPos is integer (restricted in range but still integer) therefore the
    result of BitPos + 1 is also an integer which is not constrained by the
    range of BitPos so the calculated next value for BitPos when the current
    value is 10 is 11 not 0. I know that you have overridden this further down
    with the assignment BitPos <= 0 but at the point the increment is
    calculated there is an error.

    Cheers,

    Pete.
    Peter Molesworth, Oct 28, 2003
    #14
  15. Re: I do worry because ModelSim does

    > value is 10 is 11 not 0. I know that you have overridden this further down
    > with the assignment BitPos <= 0 but at the point the increment is
    > calculated there is an error.


    YES! SUCCESS! I caught Model Sim out!!!

    As we all know from basic courses and simulation tutorials, assertion in
    VHDL takes place when all branches has been analyzed and process is frozen.
    ModelSim does not know such a basic rule! Should I report this behaviour to
    support?
    Valentin Tihomirov, Oct 28, 2003
    #15
  16. Re: I do worry because ModelSim does

    On Wed, 29 Oct 2003 00:36:04 +0200, Valentin Tihomirov
    <> wrote:

    >> value is 10 is 11 not 0. I know that you have overridden this further
    >> down
    >> with the assignment BitPos <= 0 but at the point the increment is
    >> calculated there is an error.

    >
    > YES! SUCCESS! I caught Model Sim out!!!
    >
    > As we all know from basic courses and simulation tutorials, assertion in
    > VHDL takes place when all branches has been analyzed and process is
    > frozen.
    > ModelSim does not know such a basic rule! Should I report this behaviour
    > to
    > support?
    >
    >


    I'm glad I was finally able to help :) I would probably run this one past
    modeltech support if I were you just to see what they have to say for
    themselves. The only thing that I can think of in their defense is that
    they are calculating the value ready to be assigned after the next clock
    edge. In their internal data structure this will probably be of the same
    type as BitPos and therefore you are assigning an out of range value to
    this data structure. However I reckon it's still a bug!

    Cheers,

    Pete.
    Peter Molesworth, Oct 28, 2003
    #16
  17. Valentin Tihomirov wrote:

    > I'm writing here just because when Sample = 7 and BitPos = 10 ModelSim shows
    > me message "Value 11 is out of range 0 to 10" and does not proceed. I


    What happens to your simulation if you use 9 instead of 10?

    if BitPos = 9 then -- stop bit

    Does that get it lined up?

    -- Mike Treseler

    -- This thread is one case for the
    -- clarity of unsigned variables over
    -- integer signals when doing math.
    Mike Treseler, Oct 28, 2003
    #17

  18. > What happens to your simulation if you use 9 instead of 10?
    >
    > if BitPos = 9 then -- stop bit


    When BitPos = 9 it increments to 10 as proceeded. At the next cycle
    simulator fails to calculate next value of 0. Where do you see comparison to
    9? It doesn't matter. Peter has got myproblem, see last posts. May be you
    have to add something.
    Valentin Tihomirov, Oct 28, 2003
    #18
  19. Re: I do worry because ModelSim does

    Despite LRM stands for my logic ...



    > "internal data structure this will probably be of the same type as BitPos

    ".

    This internal data structure is a model of combinational logic calculating
    next state of register. Which type will it have? Only synthesier/optimizer
    knows the answer. Simulator just should predict HW as precisely as possible.
    Will both synthesis and simulation agree that 4-bit is enaught if BitPos
    range 0 to15? What about different encoding schemes? That is why, I've
    called this issue a corner case waiting VHDL community to explain me
    details. I start wondering why the issue is not well understood.
    Valentin Tihomirov, Oct 28, 2003
    #19
  20. Re: I do worry because ModelSim does

    Hi,

    Peter Molesworth wrote:
    > On Wed, 29 Oct 2003 00:36:04 +0200, Valentin Tihomirov
    > <> wrote:
    >
    >>> value is 10 is 11 not 0. I know that you have overridden this further
    >>> down
    >>> with the assignment BitPos <= 0 but at the point the increment is
    >>> calculated there is an error.

    >>
    >>
    >> YES! SUCCESS! I caught Model Sim out!!!
    >>
    >> As we all know from basic courses and simulation tutorials, assertion in
    >> VHDL takes place when all branches has been analyzed and process is
    >> frozen.
    >> ModelSim does not know such a basic rule! Should I report this
    >> behaviour to
    >> support?
    >>
    >>

    >
    > I'm glad I was finally able to help :) I would probably run this one
    > past modeltech support if I were you just to see what they have to say
    > for themselves. The only thing that I can think of in their defense is
    > that they are calculating the value ready to be assigned after the next
    > clock edge. In their internal data structure this will probably be of
    > the same type as BitPos and therefore you are assigning an out of range
    > value to this data structure. However I reckon it's still a bug!


    IMHO, it is bug. The following is cited from Section
    8.4.1 "Updating a projected output waveform" of the LRM:

    "...
    No subtype check is performed on the value component of a
    new transaction when it is added to a driver. Instead, a
    subtype check that the value component of a transaction
    belongs to the subtype of the signal driven by the driver
    is made when the driver takes on that value. See 12.6.1."

    It look like ModelSim is doing range checking when the
    new transaction is *added* to the driver. I guess the major
    reason for this is to improve simulation speed.

    --
    Edwin
    Edwin Naroska, Oct 29, 2003
    #20
    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. Divyang M
    Replies:
    9
    Views:
    623
    Divyang M
    May 18, 2005
  2. Divyang M
    Replies:
    1
    Views:
    569
    Jerzy Gbur
    May 15, 2005
  3. Weng Tianxiang
    Replies:
    12
    Views:
    1,397
  4. =?Utf-8?B?RGF2ZQ==?=

    Legal ViewState Characters

    =?Utf-8?B?RGF2ZQ==?=, May 24, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    367
    Patrice
    May 24, 2004
  5. John Smith

    Button the only legal PostBack control?

    John Smith, Jan 17, 2005, in forum: ASP .Net
    Replies:
    7
    Views:
    1,839
    John Smith
    Jan 19, 2005
Loading...

Share This Page