Signal assignments

[Tim Frink]

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

 

[Paul Uiterlinden]

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.

 

[Stephan Ceram]

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?

 

[Paul Uiterlinden]

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.

 

[Tricky]

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.

 

[Andy]

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

 

[Paul Uiterlinden]

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.

 

[Andy]

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:


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.

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