Delta Cycles and the Simulation Engine

1. Engineering intuition — two axes of time

Real hardware settles "instantly" after an edge: a clock rises and combinational logic ripples to a new steady state with (ideally) zero modelled delay. But "everything at once" is ambiguous for a simulator — in what order do the gates evaluate? VHDL resolves this with a second time axis. At each real-time instant the engine runs as many delta cycles as needed to let zero-delay logic propagate and settle, all while the wall clock (ns) stays frozen. Deltas are ordered (delta 0, delta 1, …) but consume no real time.

So a signal you assign "now" updates at now + 1 delta: the same nanosecond, the next ordered step. That single fact — already met as the delta delay in lessons 3.1/3.2 — is the whole engine.

2. Formal explanation — the simulation cycle

The simulator repeats a fixed loop. At the current time it updates the signals scheduled for now, resumes every process sensitive to those changes, runs each until it suspends (scheduling new updates one delta ahead), and repeats. When a pass produces no further signal changes at this time, the design is stable and real time advances to the next pending event.

3. Production-quality RTL — propagation takes deltas

Consider three concurrent assignments forming a chain. They do not all update together; the value ripples one delta per stage, all at the same nanosecond:

-- concurrent signal assignments (each is its own driver, lesson 3.5):
b <= a;        -- when a changes, b updates one delta later
c <= b;        -- when b changes, c updates one delta after THAT
d <= c;        -- ... and d one delta after that
-- A change on 'a' reaches 'd' after 3 delta cycles — all at the SAME real time.

What hardware does this become? Three buffers/wires in series. In silicon the propagation is a tiny real delay; in zero-delay RTL simulation that ordering is represented by delta cycles, so the sequence (a before b before c before d) is preserved without inventing arbitrary times.

4. Hardware interpretation — deltas model order, not delay

Delta cycles are how VHDL represents causal ordering of zero-delay logic. Real combinational paths have nonzero delay that naturally orders events; RTL deliberately models them as zero delay for speed and clarity, so the engine needs another way to keep "a causes b causes c" ordered. Deltas supply that ordering at zero real time. They are a simulation device — they do not exist in hardware and have no bearing on synthesis — but they make zero-delay simulation match the causal behaviour the gates would have.

5. Simulation interpretation — many deltas at one nanosecond

On a waveform, delta updates all sit at the same ns grid line; a tool shows them as successive infinitesimal steps. The chain above propagates within a single time instant:

6. Debugging example — the zero-delay combinational loop

Expected: combinational logic settles to a steady state. Observed: the simulator hangs or aborts with "iteration limit exceeded" / "delta cycle limit," and the waveform shows a signal toggling endlessly at a single time point. Root cause: a zero-delay feedback loop with no stable solution — each delta re-triggers the next, so the design never settles and real time never advances. Fix: break the comb loop (register it, or remove the unintended feedback). Engineering takeaway: an unbounded burst of delta cycles at one time is the simulator telling you the combinational graph has no fixed point — almost always an accidental comb loop.

-- WRONG: y depends on itself with zero delay → oscillates across deltas forever.
y <= not y;          -- each delta flips y, scheduling another flip → no fixed point
-- The engine spins deltas at the same ns until it gives up (iteration-limit error).
 
-- RIGHT: make the feedback cross a register so each value lasts a full clock.
process (clk) begin
  if rising_edge(clk) then
    y <= not y;      -- a toggle flip-flop: one change per clock, settles each cycle
  end if;
end process;

7. Common mistakes & what to watch for

• Assuming concurrent statements update simultaneously. They ripple one delta per dependency; a chain of N stages needs N deltas (all at the same ns).
• Reading a signal expecting "this delta's" new value. A signal assigned now updates next delta; the current evaluation still sees the old value (use a variable for same-step results).
• Building unintended zero-delay loops. Comb feedback with no fixed point causes a delta-iteration-limit error — break it with a register.
• Confusing delta count with real time. Deltas are zero real time; many deltas at one ns is normal and costs no simulated time.
• Expecting deltas to affect synthesis. They are a simulation construct only; gates have real delay and synthesis ignores the delta model entirely.

8. Engineering insight

Delta cycles are VHDL's answer to a deep question: how do you simulate "instantaneous" hardware deterministically? By splitting each instant into ordered, zero-time steps, the engine evaluates zero-delay logic in causal order and reaches the same fixed point every run — no races, no tool-dependent ordering. This is also a diagnostic lens: a burst of deltas means propagation (normal); an unbounded burst means no fixed point (a comb loop). Once you see signal updates as "scheduled one delta ahead and settled before time moves," drivers, multiple-driver resolution, and clocked behaviour all read as consequences of this one loop.

9. Summary

Simulated time has two axes: real time and delta cycles. A scheduled signal update lands one delta later at the same real time; waking processes can schedule more updates, spinning additional deltas until the design is stable, after which real time advances. Deltas give deterministic, race-free ordering of zero-delay logic, are a simulation-only construct, and turn an unsolvable comb loop into a visible iteration-limit error.

10. Learning continuity

You now have the engine: updates are scheduled one delta ahead and applied by the simulation loop. But what holds those scheduled values? The next lesson details the driver model — how each assignment creates a driver that carries a projected waveform of pending transactions, the object the delta cycle actually reads when it updates a signal. That sets up the lesson after it, multiple drivers and contention, where two drivers on one net force the resolution you first met with std_logic back in Chapter 2.