z <= y AFTER 30 ns
z <= y after 15 ns
why after the change above ,the value of w never updates ?
Besides providing a picture as a code example:
ENTITY top IS END ENTITY; ARCHITECTURE example of top IS SIGNAL w, x, y,z : integer := 0; -- initialised to 0 (zero) BEGIN p1: PROCESS (z) VARIABLE a, b : integer := 0; -- initialised to 0 (zero) BEGIN b := a - 8; w <= a + b; a := a + 20; x <= a + b + w AFTER 20 ns; END PROCESS; p2: y <= x + w; p3: z <= y AFTER 30 ns; END example;
We see X does change:
Making your change:
p3: z <= y after 15 ns;
x no longer shows a different value, yet the simulation continues:
The reason we see any continued action is because the process is sensitive to
The reason we see
x is 0 and never changes is because how projected waveforms are scheduled for signal events.
A new event on
z comes along and causes a new assignment to
x before the scheduled previously projected waveform resulting in the previously scheduled transaction being deleted from the projected output waveform.
See IEEE Std 1076-2008 10.5.2.2 Executing a simple assignment statement, paragraph 7:
The sequence of transactions is then used to update the projected output waveform representing the current and future values of the driver associated with the simple waveform assignment statement. 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 waveform.If the initial delay is inertial delay according to the definitions of 10.5.2.1, the projected output waveform is further modified as follows:
b) The new transactions are then appended to the projected output waveform in the order of their projected occurrence.
1) All of the new transactions are marked.
2) 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.
3) For each remaining unmarked, old transaction, the old transaction is marked if it immediately pre- cedes a marked transaction and its value component is the same as that of the marked transaction.
4) The transaction that determines the current value of the driver is marked.
5) All unmarked transactions (all of which are old transactions) are deleted from the projected output waveform.
Our first transaction on
x is scheduled to occur at Time 20 ns.
An event on
z causes a new
x transaction to be scheduled for Time 35 ns. This does not result in the old transaction being marked and it is removed.
The why of this comes from the delay model. See 10.5.2 Simple signal assignments, 10.5.2.1 General, the difference between inertial and transport delays. An inertial delay model is the default (when the transport delay model isn't specified).
See 10.5.2.1 paragraph 6:
Every inertially delayed signal assignment has a pulse rejection limit. If the delay mechanism specifies inertial delay, and if the reserved word reject followed by a time expression is present, then the time expression specifies the pulse rejection limit. In all other cases, the pulse rejection limit is specified by the time expression associated with the first waveform element.
The previously scheduled transaction on
x is within the pulse rejection limit for the new transaction on
x and is dropped. This happens for every
z transaction scheduled to occur within the pulse rejection limit of
It happens because the rejection limit is taken from the first scheduled waveform (the expression after 20 ns), which tells you the delay represents the switching time for
x. You could change the delay mechanism to transport and remove the pulse rejection limit or artificially shorted in by providing an explicit reject time.
VHDL by default expects you to use switching delays and not transport delays.