Delay Modeling in Verilog — Chapter 17 Overview

Chapter 17 · Delay Modeling (Overview)

1. The Engineering Problem

A team finishes an RTL design. Every test in the regression passes — thousands of cycles, self-checking, green across the board. They sign off the RTL, run synthesis, and hand the resulting gate-level netlist to verification for a final gate-level simulation against the same tests.

The gate-level simulation fails. The very same vectors that passed at RTL now show the design coming out of reset with unknown (X) values, or sampling the wrong data on a clock edge, or producing a glitch that was never there before.

Nothing about the logic changed — synthesis is supposed to preserve function. So how can the identical test pass one simulation and fail the next?

The RTL simulation and the gate-level simulation disagree because they make different assumptions about time. The RTL sim assumed every signal arrives instantly. The gate-level sim does not — it models the time each signal takes to propagate, and that timing is where the bug lives.

This is the question this entire chapter — and the two that follow — exists to answer. To understand it, you have to leave the zero-delay world behind.

2. Why Zero-Delay Simulation Is Not Enough

Everything you have written so far behaves as if logic were instantaneous. Change an input, and the output updates in the same simulation instant. Time only moves when a delay (#), an event (@), or a wait tells it to. This is the zero-delay RTL world, and it is the right place to start — it isolates function from timing so you can get the logic correct first.

Visual A — the RTL (zero-delay) world

The problem is that this abstraction is a lie about time — a useful, intentional one, but a lie. Real signals do not arrive instantly. A flip-flop needs its data to be stable for a window around the clock edge. A glitch on a control line can corrupt a result. None of these effects can exist in a world where everything happens at once — so a zero-delay simulation is blind to an entire class of real bugs.

3. The Concept of Propagation Delay

Propagation delay is the time a signal takes to travel from a cause to its effect — from a gate's input change to its output change, or from one end of a wire to the other. Every physical element has it: transistors switch in finite time, wires have capacitance that must charge, and the result is that an output lags its input by some real amount.

When you make a simulation timing-aware, you give the model these lags. Now an input change does not instantly appear at the output — it ripples through, picking up delay at each stage.

Visual B — the timing-aware world

This single change — making time elapse along the path — is the entire foundation of the timing curriculum. Once signals arrive late, you can finally ask the questions that matter for real silicon: did the data arrive before the clock edge needed it? Did a short pulse survive the trip, or was it swallowed? Did two paths race?

4. Delay Modeling in Verilog

Verilog gives you mechanisms to attach propagation delay to a model so that a simulation reproduces how signals move through time. Conceptually there are a few places delay can live:

• on a gate or primitive (how long that gate takes to switch),
• on a net or continuous assignment (how long a wire takes to carry a change),
• and as an input-to-output path through a whole module (how long it takes a signal to travel from a specific input pin to a specific output pin).

You have already met the simplest form — the # delay — back in procedural code and gate-level modeling, where it was used to advance time in a testbench. Delay modeling is using that same idea deliberately, to make a model behave in time the way real hardware does. The detailed forms — where delays go, how narrow pulses behave, how min/typ/max corners work, and how path delays are described — are exactly what the four sub-pages of this chapter drill. This overview only needs you to hold one idea: delay modeling makes a simulation timing-aware, and it is the bridge from functional RTL to gate-level simulation.

Crucially, delay modeling is a simulation construct. It changes how the model behaves in the simulator — it does not, and cannot, change what hardware gets built. That distinction is important enough to state on its own.

5. What Delay Modeling Can and Cannot Do

The headline: delay modeling is how you make a simulation look like real hardware behaving in time. It is a modeling and verification tool, not a hardware-generation tool and not a timing sign-off tool. Keeping that boundary clear prevents the most common misconceptions in §9.

6. Delay Modeling vs Real Hardware

A delay value in a Verilog model is an approximation of a physical effect, supplied to the simulator so the model behaves realistically. Real hardware timing is not authored by hand in RTL — it comes from:

• the standard-cell library, which characterizes each cell's real delay across voltage, temperature, and process,
• the physical layout, whose wire lengths and parasitic capacitance add real interconnect delay,
• and static timing analysis (STA), which checks every path against the clock without simulating vectors at all.

In a realistic gate-level simulation, those real numbers are back-annotated onto the netlist (via an SDF file) so the simulation's delays match the characterized silicon. So when you write or read delay in Verilog, you are describing a model of hardware timing — never the timing itself. The map is not the territory; delay modeling is the map.

7. Chapter 17 Roadmap

This chapter has four sub-pages. Each adds one piece of the delay-modeling picture, and each feeds the timing chapters that follow.

Visual C — the Verilog timing curriculum

The four sub-pages of this chapter:

• 17.1 Distributed vs Lumped Delay — where you place a module's delay: spread across every internal element (distributed) or collected at the output (lumped). Teaches the accuracy-vs-simplicity trade-off and why a lumped model can hide an internal glitch. The foundation for reading any timing model.
• 17.2 Inertial vs Transport Delay — how a pulse behaves on its way through a delay. By default Verilog uses inertial delay, which swallows a pulse narrower than the delay — the cause of the baffling "my pulse generator output is flat" surprise. Transport delay passes every pulse. This is the highest-debugging-value idea in the chapter.
• 17.3 Min:Typ:Max & Rise/Fall/Turn-off Delays — which corner and which transition: how a single model carries minimum, typical, and maximum delay values for process corners, and how rise, fall, and turn-off transitions can each have their own delay. The basis of corner-aware gate-level simulation.
• 17.4 Module Path Delays & the specify Block — pin-to-pin timing: describing the delay from a specific input to a specific output of a module. This is how standard-cell timing is modelled, and the construct (specify) that hosts it is the same one that will host the timing checks of Chapter 18.

Read in order, these four take you from "delays exist" to "I can read and reason about a real cell's timing model" — and hand you directly to the timing checks of Chapter 18.

8. Industry Perspective

Delay modeling is the hinge between two halves of a real design flow.

Visual D — the simulation evolution

In production, the arc is RTL simulation → synthesis → gate-level simulation (GLS) → timing sign-off. RTL simulation proves the function. Synthesis turns RTL into a netlist of real cells. Gate-level simulation then runs the same tests on that netlist — but now with realistic delays back-annotated onto each cell — to catch exactly the timing-sensitive bugs the zero-delay RTL sim could not see (reset-release problems, glitch propagation, X-pessimism). Finally, static timing analysis signs off the clock without vectors. Delay modeling is the language feature that makes the GLS step meaningful — without it, the netlist would simulate in zero-delay too, and the whole point of GLS would vanish.

9. Common Misconceptions

"RTL timing equals silicon timing." False. RTL simulation is zero-delay — it has no notion of how long signals take. It tells you what the circuit computes, never when. Silicon timing comes from the cell library, the layout, and STA.

"Delays are synthesized into hardware." False. Delay modeling is a simulation construct. Synthesis ignores every # delay — you cannot build a chip that is "5 ns slow on purpose" by writing a delay. Real delay comes from the physics of the cells and wires, not from the model.

"Gate-level simulation is identical to RTL simulation." False. They run the same vectors but under different timing assumptions. RTL is zero-delay; GLS uses back-annotated cell delays. That difference is precisely why a test can pass at RTL and fail at gate level.

"Timing only matters at sign-off." False. Timing-sensitive bugs (reset recovery, glitches, races) show up in gate-level simulation long before STA sign-off — and some, like simulation races, can bite even in RTL. Timing is a concern across the whole flow, not just the last step.

10. DebugLab

11. Interview Q&A

12. Exercises

Conceptual exercises — reason about timing and simulation; no coding required.

Exercise 1 — Name the blindness

RTL simulation is zero-delay. List three categories of real hardware bug that this abstraction makes impossible to observe, and for each, explain in one sentence why a zero-delay model cannot show it.

Exercise 2 — Place it on the ladder

For each statement, say which layer of the timing ladder it belongs to (RTL simulation / delay modeling / timing checks / timing regions): (a) "the data violated the setup window"; (b) "the output computes the correct value but arrives 3 ns late"; (c) "two procedural blocks updated the same signal and the result was simulator-dependent"; (d) "the adder produces the right sum."

Exercise 3 — Can or cannot

Decide whether delay modeling can or cannot do each, and justify: (a) make a chip run at a guaranteed frequency; (b) reproduce a standard cell's characterized timing in simulation; (c) expose a glitch on a control signal; (d) replace static timing analysis at sign-off.

Exercise 4 — Explain the mystery

In your own words, explain to a teammate how an RTL simulation can pass while a gate-level simulation of the same design fails. Your explanation must use the words zero-delay, propagation, and visible.

13. Summary

You have left the zero-delay RTL world and stepped into timing-aware simulation.

• The mystery — an RTL sim can pass while a gate-level sim of the same design fails, because the two make different assumptions about time. RTL is zero-delay and timing-blind; gate-level simulation models propagation and is not.
• Propagation delay — every real gate and wire makes its output lag its input. Delay modeling gives a simulation those lags, so it behaves like hardware in time.
• Can and cannot — delay modeling can make a simulation realistic, reproduce cell timing, and expose glitches and races; it cannot become hardware (synthesis ignores it) or guarantee silicon timing (that is STA).
• The map is not the territory — a delay in Verilog is a model of a physical effect; real timing comes from the cell library, the layout, and back-annotated SDF.

The four-layer ladder is the spine of the next three chapters: RTL simulation → delay modeling → timing checks → timing regions.

The sub-pages of this chapter:

• 17.1 Distributed vs Lumped Delay — where delay lives in a model.
• 17.2 Inertial vs Transport Delay — how a pulse survives (or is swallowed) on its way through.
• 17.3 Min:Typ:Max & Rise/Fall/Turn-off Delays — corners and per-transition delay.
• 17.4 Module Path Delays & the specify Block — pin-to-pin timing, and the construct that will host Chapter 18's timing checks.

After Chapter 17, Chapter 18 Timing Checks teaches the simulator to detect when a signal arrives too late, and Chapter 19 Timing Regions explains the exact event ordering that makes simulation deterministic. Together, the three chapters complete the picture of how real hardware behaves in simulation.

Related Tutorials

• Gate Delays — Chapter 11.2; the first taste of # delay on a primitive, now generalised into a full delay-modeling chapter.
• Blocking and Non-Blocking Assignments — Chapter 14.3; the assignment rule whose mechanism the timing-regions chapter (19) will finally explain.
• $display vs $monitor vs $strobe vs $write — Chapter 8.1; the scheduling-region behaviour that Chapter 19 builds on.
• `timescale — Chapter 7.3; the simulation time-unit and precision contract that every delay value is measured in.