The VHDL Simulation Cycle

1. Engineering intuition — a strict, repeating algorithm

A simulator is not vague about how it runs your design; it follows a fixed recipe over and over. It keeps a queue of future events (signal changes scheduled to happen at some time), jumps to the next one, applies it, wakes the processes that care, lets them run until they suspend — accumulating new scheduled changes — and repeats. The two non-obvious truths fall straight out of this recipe: processes run in zero time (they execute fully between time advances), and signal updates are deferred to the next step while variable updates are immediate. Once you can run this recipe in your head, simulation stops being mysterious — every waveform, every race, every delta is just the recipe playing out.

2. Formal explanation — the steps of one simulation cycle

-- One SIMULATION CYCLE (event-driven scheduler):
--  1. ADVANCE TIME to the earliest scheduled event time T.
--  2. UPDATE SIGNALS whose scheduled value is due at T.
--       → this CHANGES signal values, which triggers processes sensitive to those signals.
--  3. RESUME the triggered processes; each runs to its next wait/suspension in ZERO time.
--       • VARIABLE assignments take effect IMMEDIATELY, in order, inside the process.
--       • SIGNAL assignments only SCHEDULE a future update (default: next delta).
--  4. DELTA CYCLE: if any scheduled signal updates are for the SAME time T,
--       repeat steps 2–3 WITHOUT advancing time (a delta step). Loop until no T-events remain.
--  5. When nothing more is scheduled at T, GO TO 1 (advance to the next time).
--  Simulation ends when no events remain (or a stop is requested).

A cycle: advance time, update due signals (triggering sensitive processes), run those processes to suspension in zero time (variables immediate, signal writes scheduled), then delta-iterate at the same time until the design settles, and finally advance time again. Signals change between steps; variables change within a process — the distinction is structural to the algorithm.

3. Production usage — reading behavior through the cycle

-- Two clocked processes communicating: the cycle explains why this is safe (no race).
process (clk) begin if rising_edge(clk) then a <= b; end if; end process;   -- reads b's OLD value
process (clk) begin if rising_edge(clk) then b <= a; end if; end process;   -- reads a's OLD value
-- At the clock edge BOTH processes run in the same cycle; each reads the signal value present
-- BEFORE this cycle's updates, then SCHEDULES its write → values swap cleanly. (Signals defer.)
 
-- A combinational settling example resolved by DELTA cycles:
x <= y;     -- concurrent
y <= z;     -- concurrent
-- When z changes, y updates (delta 1), which triggers x to update (delta 2) — same time,
-- successive deltas — until the chain settles, all at one simulated time T.

What hardware does this become? The cycle is the simulator's behavior, not hardware — but it is precisely what makes simulation model hardware correctly. Deferred signal updates are why two flip-flops can swap values in one edge (each sees the pre-edge value), exactly like real registers. Delta cycles are how a combinational chain settles at a single instant without consuming real time. So the cycle is the bridge: understanding it lets you predict what the hardware will do and spot where a coding mistake makes simulation diverge from it.

4. Structural interpretation — the simulation cycle loop

5. Why this is structural, not timing

The simulation cycle is a scheduler mechanism — a fixed sequence of steps the simulator repeats — so the loop diagram above is the right picture, not a waveform. Waveforms are the output of running this loop (and reading them is the next lesson); the cycle itself is the algorithm that produces them. Its defining features — deferred signal updates, immediate variables, zero-time process execution, delta iteration — are structural properties of how the engine works, independent of any particular trace, which is exactly why understanding it as structure unlocks the debugging that follows.

6. Debugging example — expecting a signal to update mid-process

Expected: a signal written earlier in a process is readable with its new value later in the same process execution. Observed: the later code sees the old value, producing an off-by-one-delta result or an unexpected extra delta. Root cause: the model assumed signal assignments take effect immediately (like software), but in the cycle a signal write only schedules an update for the next delta — within this process execution the signal still holds its old value. Fix: use a variable for a value that must update and be re-read immediately within the process; use a signal when the deferred, between-steps update is what you want (e.g. register behavior). Engineering takeaway: signals update between simulation steps, variables within — if you need an immediate read-after-write inside a process, use a variable; mixing this up is the root of countless delta-timing bugs.

-- BUG: reading a signal right after writing it sees the OLD value (update is deferred).
-- s <= a + b;   y <= s;   -- y gets s's PREVIOUS value, not a+b, this cycle
-- FIX: a variable updates immediately within the process.
v := a + b;   y <= v;       -- y sees the just-computed value

7. Common mistakes & what to watch for

• Treating signals like variables. Signal writes are deferred to the next delta; for immediate read-after-write inside a process, use a variable.
• Assuming processes consume time. Processes run to suspension in zero time; time advances only between cycles (or at wait for).
• Ignoring delta cycles. A chain of combinational signals settles over successive deltas at one time T; expecting it in a single step misreads the trace.
• Relying on process execution order. Within a delta, do not depend on which process runs first; design so order does not matter (deferred signals make this safe).
• Confusing wait for 0 ns with a delta. A delta advances no time but is the scheduler's settling step; reason in deltas, not zero-time waits.

8. Engineering insight & continuity

The simulation cycle is the simulator's exact algorithm: advance time, update due signals (triggering sensitive processes), run those processes to suspension in zero time (variables immediate, signals scheduled), and delta-iterate until settled before advancing time again. This deferred-signal, immediate-variable, delta-stepping loop is why registers swap cleanly, combinational logic settles, and certain coding mistakes desync simulation from hardware. It is the bedrock model for all debugging. With the engine understood, the next lesson turns to its primary output and your main diagnostic instrument: Reading Waveforms — interpreting the traces this cycle produces to locate bugs.