Inertial vs Transport Delay in Verilog — Why a Pulse Can Vanish

Chapter 17 · Section 17.2 · Delay Modeling

1. The Engineering Problem

An engineer builds a 2 ns strobe pulse and routes it through a buffer that has a 5 ns delay — just to line it up with another signal. They run the simulation expecting to see the strobe, delayed by 5 ns, arrive downstream.

   // strobe: a 2 ns-wide pulse on 'pulse_in'
   //   pulse_in = 0;  #10 pulse_in = 1;  #2 pulse_in = 0;   // 2 ns wide
 
   assign #5 pulse_out = pulse_in;   // route it through a 5 ns buffer
 
   // Expected: pulse_out is the same 2 ns pulse, shifted 5 ns later.
   // Actual:   pulse_out is FLAT. The pulse never appears. At all.

The strobe vanishes. pulse_out stays at 0 for the entire simulation — no delayed pulse, no glitch, nothing. The engineer checks the generator, the connectivity, the timescale… everything looks right, yet the pulse is gone.

A delay does not only make a signal late — it also decides the fate of pulses narrower than itself. The default delay in Verilog is inertial, and an inertial delay swallows any pulse shorter than the delay. The 2 ns pulse was narrower than the 5 ns delay, so the model rejected it entirely.

This is not a bug in the simulator. It is the single most surprising — and most instructive — behaviour in delay modelling, and this page is about understanding it.

2. Mental Model — A Gate Has Inertia; A Wire Does Not

3. The Hardware View

The two behaviours are two different physical things — a gate versus a wire.

Visual A — inertial: the narrow pulse is swallowed

Visual B — transport: the pulse is preserved, just shifted

Same delay value (5), same narrow input pulse — opposite outcomes. Inertial decides the pulse is too fast for a gate to pass; transport carries it like a wire.

4. Inertial Delay — The Default

Gate delays, net delays, and continuous-assignment delays are all inertial by default. You do not ask for inertial delay; you get it.

   and  #5 g1 (out, a, b);    // gate delay  — inertial
   wire #5 w;                 // net delay   — inertial
   assign #5 out = a & b;     // assign delay — inertial

The defining behaviour is pulse rejection:

   assign #5 out = in;
   // in:  ___|‾‾|________     a 3 ns pulse  (narrower than 5)
   // out: ________________     FLAT — the pulse is rejected
   //
   // in:  ___|‾‾‾‾‾‾|_____     a 7 ns pulse  (wider than 5)
   // out: ________|‾‾‾‾‾‾|_     the pulse propagates, delayed by 5

When in rises, an output transition is scheduled for 5 ns later. If in falls again before that 5 ns matures (the pulse is narrower than the delay), the scheduled output event is cancelled — the output never rises. Only pulses at least as wide as the delay survive. This is exactly what a real gate does, which is why it is the default.

5. Transport Delay

Transport delay propagates every transition, delayed, regardless of width. In Verilog you model it with an intra-assignment delay on a non-blocking assignment inside a procedural block:

   // Each change of 'in' schedules an INDEPENDENT update of 'out', 5 ns later.
   always @(in)
       out <= #5 in;          // non-blocking intra-assignment delay → transport
 
   // in:  ___|‾‾|________     a 2 ns pulse
   // out: ________|‾‾|___     SAME 2 ns pulse, shifted 5 ns later

Why this preserves the pulse: each edge of in samples in and schedules its own delayed non-blocking update of out. The rising edge schedules out → 1 at +5; the falling edge, 2 ns later, schedules out → 0 at +5 from its time — so the two updates land 2 ns apart, reproducing the pulse. Nothing is cancelled; every edge gets its own future event. This is the behaviour of a wire or a pure delay line, where a pulse travels through unchanged in shape.

Note: a blocking intra-assignment (out = #5 in;) is not clean transport — the procedural block stalls for 5 ns and can miss the next edge. The non-blocking form is the correct transport idiom.

6. The Pulse-Rejection Rule

The precise rule that governs inertial delay:

• A pulse must be at least as wide as the delay to propagate through an inertial delay. A pulse narrower than the delay is rejected (swallowed) — the pending output transition is cancelled when the input reverses within the delay window.
• Transport delay has no rejection — every transition propagates, delayed, no matter how narrow.

The whole surprise lives in the last row: under inertial delay a narrow pulse disappears; under transport it survives.

7. Why Inertial Is the Default

It would be reasonable to ask: why is the pulse-eating behaviour the default? Because it is the physically honest model of a gate.

A real logic gate has a propagation delay because its transistors take real time to switch. A glitch narrower than that delay does not produce a correspondingly narrow output glitch — the gate simply cannot react and recover that fast; the output stays put. So inertial delay is not a quirk; it is the accurate model of gate behaviour, and it doubles as natural glitch filtering — a real gate suppresses spikes shorter than its delay, and so does an inertial model. Transport delay, by contrast, models interconnect, where pulses really do travel through unchanged. Defaulting to inertial means a gate-level model behaves like gates without the engineer having to ask.

8. Where Each Is Used

• Inertial (default) — models gates and continuous-assignment logic. Its pulse rejection is a feature: it reproduces a real gate's inability to pass sub-delay spikes, giving free, physically-correct glitch filtering. This is what you want for almost all logic modelling.
• Transport — models interconnect / delay lines / transmission paths, where a pulse must travel through unchanged in shape (just later). Used when the thing being modelled genuinely preserves narrow pulses — a wire, a routing delay, a pure buffer chain modelled as a delay line.
• At the cell-model level, pulse handling on module paths is controlled more finely (pulse-control on specify paths — the territory of 17.4). Distributed/lumped (17.1) decided where delay lives; inertial/transport decides how a pulse survives the trip; path delays (17.4) make both precise per pin.

9. Common Mistakes

1. Expecting a narrow pulse to survive a delayed gate/assign. The default is inertial — pulses narrower than the delay are swallowed (§4, DebugLab).
2. Reaching for transport delay to "fix" a vanishing pulse without asking what is being modelled. If you are modelling a gate, the rejection is correct and the design is wrong (a real gate would eat the pulse too). Transport is only the fix when modelling a wire/delay line (§7, §10).
3. Using a blocking intra-assignment for transport. out = #5 in; stalls the block and can miss edges; use the non-blocking out <= #5 in; (§5).
4. Forgetting it is all simulation-only. Neither inertial nor transport delay is synthesised; they shape model behaviour, not silicon (Chapter 17 overview).

10. Debugging Lab

11. Interview Q&A

12. Exercises

Exercise 1 — Predict the output

For assign #4 y = x; with x pulsing high for 3 ns and then (separately) for 6 ns, state what y does in each case and why.

Exercise 2 — Inertial or transport?

For each, choose the model that is physically honest: (a) a logic gate with a propagation delay; (b) a length of routing wire; (c) a buffer chain you are abstracting as a pure delay line; (d) an AND gate that should suppress input glitches.

Exercise 3 — The vanishing pulse

A 1 ns strobe routed through assign #3 disappears. Give the two possible correct responses depending on what the #3 element is meant to model, and explain why only one of them is "switch to transport delay."

Exercise 4 — Blocking vs non-blocking transport

Explain why out <= #5 in; reproduces a narrow pulse but out = #5 in; (blocking) can miss it.

13. Summary

Inertial vs transport delay is about what happens to a pulse narrower than the delay:

• Inertial (the default) — for gate, net, and continuous-assignment delays. Rejects pulses narrower than the delay (the pending output edge is cancelled when the input reverses within the delay window). Models a real gate; gives free glitch filtering.
• Transport — modelled with a non-blocking intra-assignment (out <= #5 in;). Preserves every pulse, shifted by the delay. Models a wire / delay line.
• The rejection rule — a pulse must be at least as wide as the delay to survive an inertial delay; transport has no such rule.
• The judgement — when a pulse vanishes, ask whether you are modelling a gate (inertial is honest — fix the design) or a wire (use transport). Don't switch to transport just to make a pulse reappear.

Both are simulation-only; neither is synthesised.

The next sub-topic moves from which pulses survive to which delay value applies: Chapter 17.3 Min:Typ:Max & Rise/Fall/Turn-off Delays — process corners and per-transition delay.

Related Tutorials

• Distributed vs Lumped Delay — Chapter 17.1; where delay lives, the companion to how a pulse survives.
• Delay Modeling — Chapter 17 overview; why timing-aware simulation exists.
• Blocking and Non-Blocking Assignments — Chapter 14.3; the non-blocking intra-assignment that models transport delay.
• Gate Delays — Chapter 11.2; the gate # delay whose default inertial behaviour this page explains.