'event attribute & modelsim 6.0 problem

Discussion in 'VHDL' started by Nicolas Matringe, Nov 15, 2006.

  1. Hello all

    I have a process (without sensitivity list) with a wait condition on two
    signals followed by a falling edge test (see following code excerpt)
    What happens is that the falling edge remains true as long as the signal
    doesn't change. Further investigations showed that the 'event attribute
    remained true after the signal had changed, instead of being true only
    for one simulation cycle.
    What went wrong with ModelSim ? (or have I been misunderstanding the
    'event attribute for many years ?)

    code snippet :

    process
    begin
    ...
    wait on sig1, sig2;
    if falling_edge(sig1) then
    ...
    end process

    Function falling_edge returned "true" even after an event on sig2 but
    not on sig1.

    Nicolas
    Nicolas Matringe, Nov 15, 2006
    #1
    1. Advertising

  2. Nicolas Matringe wrote:

    > Hello all
    >
    > I have a process (without sensitivity list) with a wait condition on
    > two signals followed by a falling edge test (see following code
    > excerpt) What happens is that the falling edge remains true as long
    > as the signal doesn't change. Further investigations showed that the
    > 'event attribute remained true after the signal had changed, instead
    > of being true only for one simulation cycle.
    > What went wrong with ModelSim ? (or have I been misunderstanding the
    > 'event attribute for many years ?)
    >
    > code snippet :
    >
    > process
    > begin
    > ...
    > wait on sig1, sig2;
    > if falling_edge(sig1) then
    > ...
    > end process
    >
    > Function falling_edge returned "true" even after an event on sig2
    > but not on sig1.


    What version of ModelSim are you using?

    I whipped up a small testcase and it runs OK in version 6.2d:

    ENTITY test IS
    END ENTITY test;

    LIBRARY ieee;
    USE ieee.std_logic_1164.ALL;

    ARCHITECTURE arch OF test IS
    SIGNAL s1: std_ulogic;
    SIGNAL s2: std_ulogic;
    BEGIN
    s1 <= '0', '1' AFTER 1 ns, '0' AFTER 3 ns, '1' AFTER 5 ns,
    '0' AFTER 7 ns;
    s2 <= '0', '1' AFTER 2 ns, '0' AFTER 4 ns, '1' AFTER 6 ns,
    '0' AFTER 8 ns;

    p: PROCESS IS
    BEGIN
    WAIT ON s1, s2;

    REPORT "fe(s1)=" & boolean'IMAGE(falling_edge(s1)) &
    ", fe(s2)=" & boolean'IMAGE(falling_edge(s2)) &
    ", s1'EVENT=" & boolean'IMAGE(s1'EVENT) &
    ", s2'EVENT=" & boolean'IMAGE(s2'EVENT) &
    ".";
    END PROCESS p;
    END ARCHITECTURE arch;

    The result:

    # ** Note: fe(s1)=false, fe(s2)=false, s1'EVENT=true, s2'EVENT=true.
    # Time: 0 ps Iteration: 1 Instance: /test

    # ** Note: fe(s1)=false, fe(s2)=false, s1'EVENT=true, s2'EVENT=false.
    # Time: 1 ns Iteration: 0 Instance: /test

    # ** Note: fe(s1)=false, fe(s2)=false, s1'EVENT=false, s2'EVENT=true.
    # Time: 2 ns Iteration: 0 Instance: /test

    # ** Note: fe(s1)=true, fe(s2)=false, s1'EVENT=true, s2'EVENT=false.
    # Time: 3 ns Iteration: 0 Instance: /test

    # ** Note: fe(s1)=false, fe(s2)=true, s1'EVENT=false, s2'EVENT=true.
    # Time: 4 ns Iteration: 0 Instance: /test

    # ** Note: fe(s1)=false, fe(s2)=false, s1'EVENT=true, s2'EVENT=false.
    # Time: 5 ns Iteration: 0 Instance: /test

    # ** Note: fe(s1)=false, fe(s2)=false, s1'EVENT=false, s2'EVENT=true.
    # Time: 6 ns Iteration: 0 Instance: /test

    # ** Note: fe(s1)=true, fe(s2)=false, s1'EVENT=true, s2'EVENT=false.
    # Time: 7 ns Iteration: 0 Instance: /test

    # ** Note: fe(s1)=false, fe(s2)=true, s1'EVENT=false, s2'EVENT=true.
    # Time: 8 ns Iteration: 0 Instance: /test

    --
    Paul.
    www.aimcom.nl
    email address: switch x and s
    Paul Uiterlinden, Nov 15, 2006
    #2
    1. Advertising

  3. Paul Uiterlinden a écrit :
    > What version of ModelSim are you using?


    6.0c
    I didn't have time to test your case or to investigate any further, I
    had found a workaround anyway.

    I'll try and have a look when I have 5mn spare.

    Nicolas
    Nicolas Matringe, Nov 16, 2006
    #3
  4. Nicolas Matringe

    Andy Guest

    sig1 and sig2 aren't elements of the same aggregate (i.e. bits of the
    same SLV), are they?

    If that is the case, it seems like there is a feature of the language
    that whenever one bit of a vector changes, it causes an event on the
    entire vector, which in turn propagates to events on each bit. So,
    sig(1)'event will be true if a change occurred on sig(2), even though
    sig(1) itself did not change. However, IINM, rising_edge() should be
    checking previous state as well as current state of the signal, in
    which case it would return false if there was an event with no value
    change on sig(1).

    This can be handled by concurrently assigning temporary signals to the
    bits you want, and using those (assuming you can tolerate the delta
    delay for the concurrent assignments).

    Andy


    Nicolas Matringe wrote:
    > Hello all
    >
    > I have a process (without sensitivity list) with a wait condition on two
    > signals followed by a falling edge test (see following code excerpt)
    > What happens is that the falling edge remains true as long as the signal
    > doesn't change. Further investigations showed that the 'event attribute
    > remained true after the signal had changed, instead of being true only
    > for one simulation cycle.
    > What went wrong with ModelSim ? (or have I been misunderstanding the
    > 'event attribute for many years ?)
    >
    > code snippet :
    >
    > process
    > begin
    > ...
    > wait on sig1, sig2;
    > if falling_edge(sig1) then
    > ...
    > end process
    >
    > Function falling_edge returned "true" even after an event on sig2 but
    > not on sig1.
    >
    > Nicolas
    Andy, Nov 16, 2006
    #4
  5. Nicolas Matringe wrote:

    > Paul Uiterlinden a écrit :
    >> What version of ModelSim are you using?

    >
    > 6.0c
    > I didn't have time to test your case or to investigate any further,
    > I had found a workaround anyway.
    >
    > I'll try and have a look when I have 5mn spare.


    I really would be surprised if things really are as you said in your
    first post. The style you use is something that use a lot myself. I
    never have had a problem with that. Please let us know what you find.

    --
    Paul.
    www.aimcom.nl
    email address: switch x and s
    Paul Uiterlinden, Nov 16, 2006
    #5
  6. Andy wrote:

    > sig1 and sig2 aren't elements of the same aggregate (i.e. bits of
    > the same SLV), are they?


    Ah, interesting point. However:

    I modified my test and combined the two separate signals into a single
    vector. It does not change anything. It still works the same.

    > If that is the case, it seems like there is a feature of the
    > language that whenever one bit of a vector changes, it causes an
    > event on the entire vector, which in turn propagates to events on
    > each bit. So, sig(1)'event will be true if a change occurred on
    > sig(2), even though sig(1) itself did not change.


    That's not true. I do not have the LRM or any other VHDL book at hand
    at the moment. However, I seem to recall the LRM claims the opposite:
    if there is an event on any of the members making up the aggregate,
    the whole aggregate is said to have an event (and not all the other
    members).

    > However, IINM,
    > rising_edge() should be checking previous state as well as current
    > state of the signal, in which case it would return false if there
    > was an event with no value change on sig(1).


    Indeed:

    FUNCTION falling_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN IS
    BEGIN
    RETURN (s'EVENT AND (To_X01(s) = '0') AND
    (To_X01(s'LAST_VALUE) = '1'));
    END;

    > This can be handled by concurrently assigning temporary signals to
    > the bits you want, and using those (assuming you can tolerate the
    > delta delay for the concurrent assignments).


    It's not necessary.

    The only thing that you cannot do is use a variable or loop index on
    the vector to find out which bit(s) had an event. So this is not
    possible:

    WAIT ON vec;
    FOR i IN vec'RANGE LOOP
    -- ** Error: Attribute "event" requires a static signal prefix
    IF vec(i)'EVENT THEN
    ...
    END IF;
    END LOOP;

    You have the use a variable, store the previous state an compare the
    bits in the loop. I never understood why this limitation exists.

    --
    Paul.
    www.aimcom.nl
    email address: switch x and s
    Paul Uiterlinden, Nov 16, 2006
    #6
  7. Paul Uiterlinden a écrit :

    > I really would be surprised if things really are as you said in your
    > first post. The style you use is something that use a lot myself. I
    > never have had a problem with that. Please let us know what you find.


    I too was very surprised, hence my posting here.
    I was also surprised, when stepping the simulation through this portion
    of code, that it entered the falling_edge function.

    Nicolas
    Nicolas Matringe, Nov 16, 2006
    #7
  8. Andy a écrit :
    > sig1 and sig2 aren't elements of the same aggregate (i.e. bits of the
    > same SLV), are they?


    No they are not.


    > If that is the case, it seems like there is a feature of the language
    > that whenever one bit of a vector changes, it causes an event on the
    > entire vector, which in turn propagates to events on each bit.


    As Paul already said, the attributes are signal attributes, whether this
    signal is an array or not.

    Nicolas
    Nicolas Matringe, Nov 16, 2006
    #8
  9. Nicolas Matringe

    Andy Guest

    Paul,

    Thanks for the clarification. I checked the LRM (2000), and I believe
    your interpretation is correct. For some reason, I remember being told
    a long time ago not to use bits of a vector for clocks, because they
    would not simulate as expected. Maybe that was just an old wives' tale,
    or maybe it had to do with non-static prefixes. Nevertheless, it is not
    the source of your problem anyway (you're not using bits of a vector
    for this).

    Good luck,

    Andy


    Paul Uiterlinden wrote:
    > Andy wrote:
    >
    > > sig1 and sig2 aren't elements of the same aggregate (i.e. bits of
    > > the same SLV), are they?

    >
    > Ah, interesting point. However:
    >
    > I modified my test and combined the two separate signals into a single
    > vector. It does not change anything. It still works the same.
    >
    > > If that is the case, it seems like there is a feature of the
    > > language that whenever one bit of a vector changes, it causes an
    > > event on the entire vector, which in turn propagates to events on
    > > each bit. So, sig(1)'event will be true if a change occurred on
    > > sig(2), even though sig(1) itself did not change.

    >
    > That's not true. I do not have the LRM or any other VHDL book at hand
    > at the moment. However, I seem to recall the LRM claims the opposite:
    > if there is an event on any of the members making up the aggregate,
    > the whole aggregate is said to have an event (and not all the other
    > members).
    >
    > > However, IINM,
    > > rising_edge() should be checking previous state as well as current
    > > state of the signal, in which case it would return false if there
    > > was an event with no value change on sig(1).

    >
    > Indeed:
    >
    > FUNCTION falling_edge (SIGNAL s : std_ulogic) RETURN BOOLEAN IS
    > BEGIN
    > RETURN (s'EVENT AND (To_X01(s) = '0') AND
    > (To_X01(s'LAST_VALUE) = '1'));
    > END;
    >
    > > This can be handled by concurrently assigning temporary signals to
    > > the bits you want, and using those (assuming you can tolerate the
    > > delta delay for the concurrent assignments).

    >
    > It's not necessary.
    >
    > The only thing that you cannot do is use a variable or loop index on
    > the vector to find out which bit(s) had an event. So this is not
    > possible:
    >
    > WAIT ON vec;
    > FOR i IN vec'RANGE LOOP
    > -- ** Error: Attribute "event" requires a static signal prefix
    > IF vec(i)'EVENT THEN
    > ...
    > END IF;
    > END LOOP;
    >
    > You have the use a variable, store the previous state an compare the
    > bits in the loop. I never understood why this limitation exists.
    >
    > --
    > Paul.
    > www.aimcom.nl
    > email address: switch x and s
    Andy, Nov 16, 2006
    #9
    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. Bostonasian
    Replies:
    1
    Views:
    816
    Joris Gillis
    Sep 18, 2005
  2. Replies:
    2
    Views:
    1,075
    Henry S. Thompson
    Mar 6, 2006
  3. Donnal Walter

    class attribute to instance attribute

    Donnal Walter, Jun 30, 2005, in forum: Python
    Replies:
    4
    Views:
    463
    Greg Ewing
    Jul 6, 2005
  4. Russell Warren
    Replies:
    5
    Views:
    467
    Russell Warren
    Jan 17, 2006
  5. Aray
    Replies:
    0
    Views:
    550
Loading...

Share This Page