Signal assignments

Discussion in 'VHDL' started by Tim Frink, Nov 26, 2007.

  1. Tim Frink

    Tim Frink Guest

    Hi,

    I've a question about the simulation of VHDL signals.

    In the VHDL standard, it's said for the inertial delay
    model (for example here
    http://tams-www.informatik.uni-hamburg.de/vhdl/doc/P1076-2000-D3/
    P1076_Chap_08.pdf p126):

    8.4.1 Updating a projected output waveform
    a) All of the new transactions are marked;
    b) An old transaction is marked if the time at which it is projected to
    occur is less than the time at which the first new transaction is
    projected to occur minus the pulse rejection limit;
    c) For each remaining unmarked, old transaction, the old transaction is
    marked if it immediately precedes a marked transaction and its value
    component is the same as that of the marked transaction;
    d) The transaction that determines the current value of the driver is
    marked;
    e) All unmarked transactions (all of which are old transactions) are
    deleted from the projected output waveform.

    I don't understand c).
    Let's say, I've a signal "sig_a" which at the current time (t=2ns)
    is assigned the value "0" and I've two more assignments which are
    executed at the same time (t=2ns):
    sig_a <= '1' after 10ns;
    sig_a <= '1' after 11ns;

    For the first assignment I would add a transaction at time
    t=12ns (1 for sig_a). For the next transaction, I would add
    another 1 at time t=13ns. Due to rule c), transaction at time
    t=12ns would be kept.

    This does not fit to my understanding of real hardware. In my opinion,
    "sig_a <= '1' after 11ns" means that the hardware needs 11ns to
    "charge" before it can change its state. So, any signal changes in between
    which where previously executed (like sig_a <= '0' after 5ns;) are
    omitted. However, in my example this would mean that "charging" which
    should take 11ns is shorten to 10ns due to the first assignment
    to sig_a since (due to c)) this transaction has the same value
    and will be kept.

    Could you help me understanding the simulation.

    Thank you.

    Best regards,
    Tim
     
    Tim Frink, Nov 26, 2007
    #1
    1. Advertising

  2. Tim Frink wrote:

    > Let's say, I've a signal "sig_a" which at the current time (t=2ns)
    > is assigned the value "0" and I've two more assignments which are
    > executed at the same time (t=2ns):
    > sig_a <= '1' after 10ns;
    > sig_a <= '1' after 11ns;
    >
    > For the first assignment I would add a transaction at time
    > t=12ns (1 for sig_a). For the next transaction, I would add
    > another 1 at time t=13ns. Due to rule c), transaction at time
    > t=12ns would be kept.
    >
    > This does not fit to my understanding of real hardware.


    That's right, because AFTER statements are ignored during synthesis.
    They are only meaningfull during simulation.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Nov 26, 2007
    #2
    1. Advertising

  3. On Mon, 26 Nov 2007 17:39:56 +0100, Paul Uiterlinden wrote:

    > Tim Frink wrote:
    >
    >> Let's say, I've a signal "sig_a" which at the current time (t=2ns)
    >> is assigned the value "0" and I've two more assignments which are
    >> executed at the same time (t=2ns):
    >> sig_a <= '1' after 10ns;
    >> sig_a <= '1' after 11ns;
    >>
    >> For the first assignment I would add a transaction at time
    >> t=12ns (1 for sig_a). For the next transaction, I would add
    >> another 1 at time t=13ns. Due to rule c), transaction at time
    >> t=12ns would be kept.
    >>
    >> This does not fit to my understanding of real hardware.

    >
    > That's right, because AFTER statements are ignored during synthesis.
    > They are only meaningfull during simulation.


    But what happens during simulation with all events in the transaction
    list between the current time and the AFTER statement?
    As in the example, let's assume the current time is t=2ns and
    the next statement is
    sig_a <= '1' after 11ns;

    What happens to all transaction between t=2ns and t=13ns?
     
    Stephan Ceram, Nov 26, 2007
    #3
  4. Stephan Ceram wrote:

    > On Mon, 26 Nov 2007 17:39:56 +0100, Paul Uiterlinden wrote:
    >
    >> Tim Frink wrote:
    >>
    >>> Let's say, I've a signal "sig_a" which at the current time (t=2ns)
    >>> is assigned the value "0" and I've two more assignments which are
    >>> executed at the same time (t=2ns):
    >>> sig_a <= '1' after 10ns;
    >>> sig_a <= '1' after 11ns;


    > But what happens during simulation with all events in the transaction
    > list between the current time and the AFTER statement?


    The signal will go to '1' at 12 ns. The second signal assignment does not
    cancel the first, because the value of the second assignment is same as the
    first.

    In the case of:

    sig_a <= '1' after 10 ns;
    sig_a <= '0' after 11 ns;
    (note that there must be a space before 'ns')

    Then the second signal assignment cancels the first and the signal goes
    to '0' at 13 ns.

    My advice is get a book where all this is explained (e.g. A VHDL Primer, J.
    Bhasker), and simply try out some examples in a simulator.

    I must say, I do not always know the answer myself. This area is quite
    complicated. And then there is the difference between inertial delay (used
    above) and transport delay to add to the confusion.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Nov 28, 2007
    #4
  5. Tim Frink

    Tricky Guest

    A Point to note in modelsim, is that it has a habbit of doing
    assignments and canceling the previous ones, but not cancel the time.

    consider this code:

    ...
    ..
    signal my_signal : boolean;
    begin
    ..
    ..
    process
    begin
    my_signal <= false, true after SOME_TIME;
    wait until SOME_EVENT = true;
    my_signal <= false;
    wait;
    end process;
    ..
    ..

    Assuming the clock has stopped (and all other assignments are
    finished) after SOME_EVENT, Modelsim should end the simulation, but
    infact it runs the simulation, with no scheduled assignments until
    SOME_TIME. ActiveHDL will finish the simulation after SOME_EVENT in
    this case.
     
    Tricky, Nov 29, 2007
    #5
  6. Tim Frink

    Andy Guest

    On Nov 29, 4:14 am, Tricky <> wrote:
    > A Point to note in modelsim, is that it has a habbit of doing
    > assignments and canceling the previous ones, but not cancel the time.
    >
    > consider this code:
    >
    > ..
    > ..
    > signal my_signal : boolean;
    > begin
    > ..
    > ..
    > process
    > begin
    > my_signal <= false, true after SOME_TIME;
    > wait until SOME_EVENT = true;
    > my_signal <= false;
    > wait;
    > end process;
    > ..
    > ..
    >
    > Assuming the clock has stopped (and all other assignments are
    > finished) after SOME_EVENT, Modelsim should end the simulation, but
    > infact it runs the simulation, with no scheduled assignments until
    > SOME_TIME. ActiveHDL will finish the simulation after SOME_EVENT in
    > this case.


    Other simulators do that too (e.g. nc-vhdl). The reason is because an
    event is scheduled at time now+some_time as a result of the first
    assignment. The simulator doesn't stops until all events are
    exhausted, including that one, even though nothing will occur because
    of it. I've had it happen with a wait until ... for... statement too.
    AFAIK, events never get canceled.

    Andy
     
    Andy, Nov 29, 2007
    #6
  7. Andy wrote:

    > On Nov 29, 4:14 am, Tricky <> wrote:
    >> A Point to note in modelsim, is that it has a habbit of doing
    >> assignments and canceling the previous ones, but not cancel the time.
    >>
    >> consider this code:
    >>
    >> ..
    >> ..
    >> signal my_signal : boolean;
    >> begin
    >> ..
    >> ..
    >> process
    >> begin
    >> my_signal <= false, true after SOME_TIME;
    >> wait until SOME_EVENT = true;
    >> my_signal <= false;
    >> wait;
    >> end process;
    >> ..
    >> ..
    >>
    >> Assuming the clock has stopped (and all other assignments are
    >> finished) after SOME_EVENT, Modelsim should end the simulation, but
    >> infact it runs the simulation, with no scheduled assignments until
    >> SOME_TIME. ActiveHDL will finish the simulation after SOME_EVENT in
    >> this case.

    >
    > Other simulators do that too (e.g. nc-vhdl). The reason is because an
    > event is scheduled at time now+some_time as a result of the first
    > assignment. The simulator doesn't stops until all events are
    > exhausted, including that one, even though nothing will occur because
    > of it. I've had it happen with a wait until ... for... statement too.
    > AFAIK, events never get canceled.


    Oh yes they do! Paragraph 8.4.1 of the 93 LRM (Updating a projected output
    waveform) contains some nice bed time reading (you fall asleep before you
    know it) about this.

    Line 249 and next:

    <quote>
    Updating a projected output waveform consists of the deletion of zero or
    more previously computed transactions (called old transactions) from the
    projected output waveform and the addition of the new transactions, as
    follows:

    a) All old transactions that are projected to occur at or after the time at
    which the earliest new transaction is projected to occur are deleted from
    the projected output waveforms.
    </quote>

    So in the case of the original poster:

    > ..
    > ..
    > signal my_signal : boolean;
    > begin
    > ..
    > ..
    > process
    > begin
    > my_signal <= false, true after SOME_TIME;
    > wait until SOME_EVENT = true;
    > my_signal <= false;
    > wait;
    > end process;
    > ..
    > ..


    I certainly would expect the transaction to true at SOME_TIME to be canceled
    by the second signal assignment, if SOME_EVENT happens before SOME_TIME.

    I too have observed the behaviour of ModelSim, that is simulates to
    SOME_TIME, even if there are no transactions anymore. It does not take any
    time, but it can crash the waveform viewer if SOME_TIME is equal to
    time'HIGH.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Nov 29, 2007
    #7
  8. Tim Frink

    Andy Guest

    On Nov 29, 10:04 am, Paul Uiterlinden <> wrote:
    > Andy wrote:
    > > On Nov 29, 4:14 am, Tricky <> wrote:
    > >> A Point to note in modelsim, is that it has a habbit of doing
    > >> assignments and canceling the previous ones, but not cancel the time.

    >
    > >> consider this code:

    >
    > >> ..
    > >> ..
    > >> signal my_signal : boolean;
    > >> begin
    > >> ..
    > >> ..
    > >> process
    > >> begin
    > >> my_signal <= false, true after SOME_TIME;
    > >> wait until SOME_EVENT = true;
    > >> my_signal <= false;
    > >> wait;
    > >> end process;
    > >> ..
    > >> ..

    >
    > >> Assuming the clock has stopped (and all other assignments are
    > >> finished) after SOME_EVENT, Modelsim should end the simulation, but
    > >> infact it runs the simulation, with no scheduled assignments until
    > >> SOME_TIME. ActiveHDL will finish the simulation after SOME_EVENT in
    > >> this case.

    >
    > > Other simulators do that too (e.g. nc-vhdl). The reason is because an
    > > event is scheduled at time now+some_time as a result of the first
    > > assignment. The simulator doesn't stops until all events are
    > > exhausted, including that one, even though nothing will occur because
    > > of it. I've had it happen with a wait until ... for... statement too.
    > > AFAIK, events never get canceled.

    >
    > Oh yes they do! Paragraph 8.4.1 of the 93 LRM (Updating a projected output
    > waveform) contains some nice bed time reading (you fall asleep before you
    > know it) about this.
    >
    > Line 249 and next:
    >
    > <quote>
    > Updating a projected output waveform consists of the deletion of zero or
    > more previously computed transactions (called old transactions) from the
    > projected output waveform and the addition of the new transactions, as
    > follows:
    >
    > a) All old transactions that are projected to occur at or after the time at
    > which the earliest new transaction is projected to occur are deleted from
    > the projected output waveforms.
    > </quote>
    >
    > So in the case of the original poster:
    >
    > > ..
    > > ..
    > > signal my_signal : boolean;
    > > begin
    > > ..
    > > ..
    > > process
    > > begin
    > > my_signal <= false, true after SOME_TIME;
    > > wait until SOME_EVENT = true;
    > > my_signal <= false;
    > > wait;
    > > end process;
    > > ..
    > > ..

    >
    > I certainly would expect the transaction to true at SOME_TIME to be canceled
    > by the second signal assignment, if SOME_EVENT happens before SOME_TIME.
    >
    > I too have observed the behaviour of ModelSim, that is simulates to
    > SOME_TIME, even if there are no transactions anymore. It does not take any
    > time, but it can crash the waveform viewer if SOME_TIME is equal to
    > time'HIGH.
    >
    > --
    > Paul Uiterlindenwww.aimvalley.nl
    > e-mail addres: remove the not.


    I think we are confusing transaction with event (my use of "event" is
    as in "event driven simulator", not the vhdl 'event attribute). When
    the simulator executes the first assignement, it sets an event for
    time=now+some_time, and a transaction associated with that event. You
    are correct that it then deletes the corresponding transaction, but
    the event (with no corresponding transaction) is still there, and the
    simulator will execute the event and do nothing except advance time to
    that point.

    I suppose that a simulator could have an optimization so that when it
    deletes a transaction, it checks to see if the associated event has no
    more transactions associated with it, then it would remove the event.
    However, there is seldom a significant performance penalty from "empty
    events", and the work to check and remove them is probably more than
    executing them.

    Andy
     
    Andy, Nov 29, 2007
    #8
    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. Alex Rast
    Replies:
    3
    Views:
    669
  2. Michael Pronath
    Replies:
    1
    Views:
    1,194
    Diez B. Roggisch
    Jan 3, 2005
  3. Jack Orenstein

    threading.Thread vs. signal.signal

    Jack Orenstein, Sep 18, 2005, in forum: Python
    Replies:
    0
    Views:
    477
    Jack Orenstein
    Sep 18, 2005
  4. Neil
    Replies:
    14
    Views:
    914
  5. mamu
    Replies:
    4
    Views:
    610
    Barry
    Dec 11, 2008
Loading...

Share This Page