0
\$\begingroup\$

enter image description here

Question: change z <= y AFTER 30 ns to z <= y after 15 ns
why after the change above ,the value of w never updates ?

\$\endgroup\$
  • \$\begingroup\$ I tried to simulate it. the value of w is changing. you mean x? \$\endgroup\$ – nidhin Feb 11 '15 at 7:08
2
\$\begingroup\$

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:

top w,x,y and z (clickable)

Making your change:

        p3: z <= y after 15 ns;

We see x no longer shows a different value, yet the simulation continues:

enter image description here (clickable)

The reason we see any continued action is because the process is sensitive to z.

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.
b) The new transactions are then appended to the projected output waveform in the order of their projected occurrence.
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:
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 x.

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.