# VHDL: when is process sensitivity list triggered?

In VHDL simulation, there is a concept of "delta time," which is loosely interpreted as "group of events triggered by the previous delta time." After a change, once all cascading changes have settled, and no more delta time events are generated, the simulation time advances. (Also, simulation time may advance after N delta time events, as there is some upper limit to the length of a cascade.)

In a given process, when is a change to the process sensitivity list triggered? Is it only triggered when the state of a signal is different at one simulation time as compared to the previous simulation time, or can it be triggered as a result of any delta time event? If it is triggered at any delta time, a process may be triggered more than once if there are ephemeral combinatoric logic?

Consider this example:

simulate this circuit – Schematic created using CircuitLab

Let's say we start with steady state A=1, B=0, C=1. Also, let's assume there is no external entity inspecting signal B -- it is purely internal.

Now, introduce a simulation event: A=0.

This will generate an output event for B=1, and an output event for C=0, for the next delta time. At the next delta time, a new output event for C=1 will be generated, and no more events will be generated, so simulation time can advance.

Now, let's say I have a process with C in the sensitivity list. Let's say this process increments a counter each time it is invoked.

Will that counter be incremented twice as a result of A change? That would be the case if delta-time changes provoke/trigger/invoke processes.

Or will that counter be incremented zero times? That would be the case if only simulation-time changes provoke/trigger/invoke processes.

Or is the relation between change-in-A and process-counter undefined? For example, if the simulator (or synthesizer, for hardware,) optimizes the NOT-and-XOR truth table, it will say that C is always 1, but if it doesn't optimize it, it may generate two changes for C and thus trigger the process twice?

Second question: What's the correct word to use for "provoking/triggering/invoking" a process by changing some signal in its sensitivity list?

• Twice. Such a counter would work in simulation but it would of course be physically unrealisable. Simulator is not allowed to optimise logic : the fact that it exposes a potential glitch here is a feature, not a bug! Oct 29, 2013 at 19:07
• Using an signal event as a clock requires qualification (e.g. if C'event and C = '1' then ... ) which has the mystical properties of a) only catching one edge, b) being synthesis eligible and c) reflecting hardware. The word you are looking for is event, along with understanding the distinction from transaction. See entries in the IEEE Std 1076 glossary as well as the sub clause on execution of a model and it's subsection on the simulation cycle. Besides the LRM try Peter Ashenden's 'The VHDL Designer's Guide' 3rd edition as an authoritative reference.
– user8352
Oct 29, 2013 at 20:04
• @Brian I think some kind of lint message or warning would be appropriate, rather than calling it a feature. Also, why would that behaviour not be synthesizable? (I'm trying to build a robust mental model here.) Oct 29, 2013 at 22:49
• You increment hardware counters with clock edges, either 0->1 or 1->0 but not both, while you described operating the counter on both which doesn't synthesize. A counter driven by C would count pairs of transitions by counting rising or falling clock edges. As far as a warning, would you require one when hooking up combinatorial gates to the output of a say a 4 bit asynchronous counter? Think hardware description, not software. C pulse width is the inverter delay plus any difference in rise and fall time. Without modeling those delays the pulse width is one delta cycle. (A glitch).
– user8352
Oct 30, 2013 at 0:49
• David answered it very well. This Q/A may also help. stackoverflow.com/questions/13954193/… Oct 30, 2013 at 8:33

Time is only advanced when no more processes can be awakened by any event. If process "P" is awakened by its sensitivity list, it will execute in zero time and schedule signal assignments, and these assignments may awaken other processes. If at the next delta (which does not advance time) any process (including itself) affects P's sensitivity list, then P will be re-awakened. This happens as many times as necessary (or until the simulator gives up or the set maximum number of deltas have occurred).

In the particular example of your question with ABC = 101, if you had:

process(A,B) begin
B <= not A;
C <= A xor B;
end process;

process(C) begin
end process;


When A changes to 0, BC are scheduled with assignments of 10. A delta passes, B becomes 1 and re-awakens the process, which schedules C back to 1. At the end of this second delta the values are 011, and there are no more events that could awaken the process, and when no other process can be awakened, time advances.

Consequently, process(A,B) is awakened once when A changes, and a second time when B is changed. As a result, the "process awakening counter" counts twice.

In the case of process(C), it will also be awakened twice, because C will "delta glitch" due to process(A,B).

However, if B was implicit:

process(A) begin
C <= A xor (not A);
end process;

process(C) begin
end process;


Or if B was a local variable:

process(A)
variable B : std_logic_vector;
begin
B := not A;
C <= A xor (not B);
end process;

process(C) begin
end process;


Then process(A) would only be awakened once, but process(C) would remain suspended.

• But my question was whether the counter process would be triggered twice our zero ties, or whether that was actually not well defined. I already described what would happen to A, B and C. Oct 29, 2013 at 22:45
• Technically it will not awaken when A or B change. It will awaken whenever C changes; i.e. twice, on the delta cycles AFTER A and B change, since A wakes the XOR process, which schedules an event on C (and B ditto). Oct 30, 2013 at 8:37
• @Brian I was referring to process(A,B), I edited the question to clear this up and explicitly mention process(C) as well. Oct 30, 2013 at 17:36