Inertial vs Transport Delay

1. Engineering intuition — does a glitch survive the delay?

A real logic gate cannot switch infinitely fast: a pulse at its input that is narrower than the gate's own propagation delay does not have enough "energy" to flip the output — the gate's inertia swallows it. A wire, by contrast, has no such filtering: whatever goes in comes out, just later. VHDL gives you both behaviours so your delay models match what you are modelling.

The question every after must answer is therefore: if a new value arrives before a previously scheduled one has appeared, does the brief intervening pulse propagate? Inertial says no (filter it); transport says yes (pass it).

2. Formal explanation — the two models and the reject clause

y <= x after 5 ns;                 -- INERTIAL (default): pulses on x shorter than 5 ns are rejected
y <= transport x after 5 ns;       -- TRANSPORT: every change on x is reproduced 5 ns later
y <= reject 2 ns inertial x after 5 ns;  -- custom: reject pulses shorter than 2 ns, delay 5 ns

• Inertial is the default for signal <= expr after t. It rejects pulses shorter than t (the rejection limit defaults to the delay t).
• Transport (transport keyword) reproduces every transition delayed by t, regardless of width.
• reject t1 inertial … after t2 decouples the two: reject pulses narrower than t1 while delaying by t2 (with t1 <= t2), so you can model a gate whose rejection time differs from its delay.

3. Production-quality RTL — when each model fits

-- Modelling a GATE with ~3 ns delay that filters sub-3 ns glitches:
y_gate <= (a and b) after 3 ns;                    -- inertial (default) — realistic gate
 
-- Modelling an interconnect / delay line that must preserve a narrow strobe:
strobe_dl <= transport strobe after 1 ns;          -- transport — keep the pulse intact
 
-- A gate that filters very short spikes but has a longer output delay:
y_filt <= reject 1 ns inertial noisy after 4 ns;   -- reject <1 ns, delay 4 ns

What hardware does this become? Nothing structural — after and its delay model are not synthesizable (lesson 2.13); synthesis drops the delay entirely. These statements live in testbenches, behavioural models, and gate-level/SDF-annotated simulations, where the delay model governs whether modelled glitches propagate.

4. Hardware interpretation — inertia vs pure delay

5. Simulation interpretation — projecting onto the driver's waveform

Both models are about how a new transaction interacts with ones already pending on the driver's projected waveform (lesson 3.5). Inertial assignment, when it schedules a new value, removes recently-scheduled transactions that would form a too-short pulse; transport simply appends the new transaction, preserving all of them.

6. Debugging example — the glitch that should (not) be there

Expected: a testbench injects a narrow strobe and the model passes it to the next stage. Observed: the strobe vanishes — the downstream block never sees it. Root cause: the delay was modelled with the default inertial after, whose rejection limit (equal to the delay) swallowed the sub-delay strobe. Fix: model the path as a delay line with transport, or set a small reject limit so legitimate narrow pulses survive. Engineering takeaway: if narrow pulses mysteriously disappear (or unexpectedly appear) in a delay model, the inertial-vs-transport choice is the first thing to check — the default inertial filters anything shorter than the delay.

-- WRONG (for a delay line): default inertial rejects the narrow strobe.
strobe_o <= strobe after 5 ns;             -- a <5 ns strobe is filtered out
-- RIGHT: a wire/delay line preserves the pulse.
strobe_o <= transport strobe after 5 ns;   -- strobe reproduced intact, 5 ns later

7. Common mistakes & what to watch for

• Forgetting inertial is the default. Plain after filters pulses shorter than the delay; if you need them preserved, say transport.
• Using transport where you want glitch filtering. Transport passes every spike — wrong for modelling a real gate that should reject them.
• Confusing rejection limit with delay. They are equal by default but separable via reject t1 inertial … after t2; use it to model gates whose filtering time differs from delay.
• Expecting either model to synthesize. after and its delay model are simulation-only; synthesis ignores them. Real glitch behaviour comes from actual gate delays post-synthesis.
• Modelling timing-critical hardware with after instead of clocked logic. Use registers for real timing; reserve delay models for behavioural/gate-level simulation.

8. Engineering insight

Inertial and transport are VHDL's way of letting a behavioural model match physical reality: gates have inertia and filter glitches, wires do not. Defaulting to inertial is deliberate — it matches the common case (modelling logic) and keeps spurious sub-delay glitches out of simulation. Reach for transport only when you are explicitly modelling lossless propagation (a delay line, an interconnect). And keep the whole topic on the simulation side of the line: these delays shape modelled waveforms, never synthesized hardware. Understanding them also sharpens your reading of gate-level/SDF simulations, where inertial rejection explains why some glitches seen in zero-delay RTL never appear in the timing-annotated netlist.

9. Summary

after supports two delay models. Inertial (the default) rejects pulses shorter than the rejection limit (default: the delay), modelling a gate's glitch-filtering inertia; transport reproduces every transition delayed, modelling an ideal wire. The reject clause tunes the rejection limit independently of the delay. Both are simulation constructs that synthesis ignores; the choice decides whether modelled glitches propagate.

10. Learning continuity

You have now seen how a signal's value (multiple drivers) and its timing (inertial/transport) behave in the non-ideal cases. One piece of the signal model remains: what value a signal holds before anything drives it, and how the unknown propagates. The next lesson, Initial Values, U, and Uninitialized Hardware, examines 'U' and 'X' — why real flip-flops power up unknown, why an initializer is a simulation/FPGA convenience rather than an ASIC guarantee, and how to stop unknowns from contaminating a design.