Verilog · Chapter 11.2 · Gate-Level Modeling

Gate Delays in Verilog — Rise, Fall, Turn-Off & min:typ:max

A gate primitive can carry a delay specification that models how long its output takes to respond to an input change, which is the propagation delay of a real gate in simulation. Verilog lets you express this delay at several granularities. You can give a single value for all transitions, separate rise and fall delays, a third turn-off delay for tri-state gates going to high impedance, and a triple that captures minimum, typical, and maximum values across process and timing corners. This page drills those forms and their meaning. The key framing is that gate delays are a simulation-only timing model. Synthesis builds the gate but ignores the delay, because real timing comes from the standard-cell library and back-annotated data, not from numbers in the source. So gate delays matter for modelling code, not for synthesizable design.

Foundation14 min readVerilogGate DelaysTimingSimulationmin:typ:maxRTL Design

Chapter 11 · Section 11.2 · Gate-Level Modeling

1. The Engineering Problem

A gate-level model needs to behave like real hardware in simulation — its outputs should not change instantly when inputs change, but after a propagation delay, so a gate-level simulation reflects real timing. And a model may need to capture that a gate is slower in one process corner than another. The question:

How does Verilog attach a propagation delay to a gate primitive — and why does it not affect synthesized hardware?

The answer is the delay specification on a gate instance, with forms for rise/fall/turn-off transitions and for min:typ:max corners. But the framing matters as much as the syntax: these delays are a simulation-only model. Synthesis builds the gate's logic and discards the delay, because real timing comes from the technology library, not the RTL. This page drills the delay forms and reinforces that boundary.

2. Mental Model — Delay Is a Simulation Timing Model, Not Hardware

Mental Model — a gate delay times the output's response in simulation; synthesis ignores it

A delay on a gate primitive specifies how long the output lags an input change:

#delay after the gate type — `and #2 (y, a, b);` means y responds 2 time units after a or b changes. It models propagation delay in simulation.
It is inertial — like the continuous-assignment delay (13.1), input pulses narrower than the delay are filtered out (a real gate rejects glitches shorter than its propagation time).
It is simulation-only. Synthesis builds the gate's logic and ignores the delay number — real gate timing comes from the standard-cell library and SDF back-annotation, not from # values in the source.

The boundary to hold:

Gate delays model timing in simulation; they do not create hardware timing. Put delays in timing-model and testbench code, never in synthesizable design logic — synthesizable RTL has no # delays.

So a gate delay is a simulator's stopwatch on the gate's response, useful for modelling, irrelevant to the synthesized circuit.

3. The Delay Forms

A gate can carry one, two, or three delay values, plus the min:typ:max form:

delay-forms.v

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

   and #2          (y, a, b);     // single delay: rise = fall = 2
   and #(3, 4)     (y, a, b);     // (rise, fall): 0→1 takes 3, 1→0 takes 4
   bufif1 #(3,4,5) (y, a, en);    // (rise, fall, turn-off): →z takes 5
   and #(1:2:3)    (y, a, b);     // min:typ:max: 1 (min), 2 (typ), 3 (max)

Single delay — `#2` — applies to all transitions (rise and fall the same).
Two delays — `#(rise, fall)` — separate delays for 0→1 (rise) and 1→0 (fall) output transitions.
Three delays — `#(rise, fall, turnoff)` — adds the turn-off delay (transition to high-impedance z), meaningful for the tri-state gates (bufif/notif).
min:typ:max — each delay value can be a `min:typ:max` triple capturing corner variation; the simulator selects which (typ by default, or min/max via a command-line option) to model best/typical/worst-case timing.

Visual A — the delay forms

Gate-delay granularity

data flow

A gate delay can be a single value (all transitions), a rise/fall pair, a rise/fall/turn-off triple (turn-off for tri-state going to z), and each value can be a min:typ:max triple for process/timing corners. More granularity models real propagation timing more precisely — all in simulation only.

4. Rise, Fall, and Turn-Off

The separate delays capture that real gates switch at different speeds in different directions:

Rise delay — applies when the output transitions to 1 (a 0→1, or to 1 from x/z).
Fall delay — applies when the output transitions to 0.
Turn-off delay — applies when the output transitions to high-impedance z; meaningful only for gates that can drive z (the tri-state bufif/notif primitives).

A transition to x uses the smallest of the applicable delays (the simulator is pessimistic about when the value becomes unknown). For ordinary logic gates, only rise and fall apply; the turn-off delay is for tri-state outputs.

5. min:typ:max — Modelling Corners

Each delay value can be a `min:typ:max` triple to capture timing variation across process, voltage, and temperature corners:

min-typ-max.v

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

   and #(1:2:3) (y, a, b);        // min=1, typ=2, max=3 for all transitions
   and #(1:2:3, 2:3:4) (y, a, b); // separate min:typ:max for rise and fall

min — fastest (best-case) corner; typ — typical; max — slowest (worst-case).
The simulator picks one for the run — typ by default, or min/max via a command-line option (so a single model simulates at any corner).
This lets one gate-level model be simulated best-, typical-, and worst-case without changing the source — important in gate-level timing verification.

6. Why Synthesis Ignores Gate Delays

The central point of this reference page. Synthesis reads a gate (or the RTL that infers it) and builds the logic function, discarding any # delay:

Real timing comes from the technology library. Each standard cell has characterized rise/fall/load-dependent delays; the actual circuit's timing is determined by these and by routing, not by numbers in the RTL.
Back-annotation (SDF) supplies real delays to gate-level simulation. After place-and-route, real per-instance delays are written to an SDF file and back-annotated onto the netlist for accurate gate-level timing simulation — replacing any source # delays.
So # delays in design logic are meaningless (ignored) at best and misleading at worst. Synthesizable RTL contains no delays; gate delays live in modelling and testbench code.

This is the same simulation-only nature as the continuous-assignment delay (13.1): a timing model for simulation, not a hardware specification.

Visual B — gate delays are simulation-only

A gate with a #delay: in simulation, the delay times the output's response (and filters narrow glitches, inertially). In synthesis, the gate's logic is built but the delay is ignored — real timing comes from the standard-cell library and back-annotated SDF after place-and-route. Gate delays are a simulation timing model, never a hardware specification.

7. Industry Perspective

Design RTL has no delays. Synthesizable logic never carries # delays — they would be ignored by synthesis and signal a misunderstanding to reviewers. Lint flags delays in design code.
Gate-level timing comes from SDF. Accurate post-layout timing simulation back-annotates per-instance delays from an SDF file onto the netlist; the source gate delays (if any) are replaced.
min:typ:max enables corner simulation. Where gate-level models do carry delays (library behavioural views, simple timing models), the min:typ:max form lets one model run at best/typical/worst corners.
Delays belong to modelling and testbenches. Clock generators, stimulus timing, and simple timing models use delays; the design logic does not.

8. Common Mistakes

Putting # delays in synthesizable RTL — synthesis ignores them; they belong in modelling/testbench code (§6).
Expecting a delay to create hardware timing — real timing comes from the library/SDF, not RTL delays (§6).
Mis-ordering rise/fall/turn-off — the order is (rise, fall, turnoff) (§3/§4).
Using turn-off delay on a non-tri-state gate — turn-off (→z) applies only to bufif/notif (§4).
Forgetting min:typ:max selection — the simulator uses typ by default; min/max need a command-line option (§5).

9. Debugging Lab

Two gate-delay debug post-mortems

10. Interview Q&A

11. Exercises

Exercise 1 — Interpret the delays

For each, state the rise, fall, and (if any) turn-off delays: (a) and #4 (y, a, b); (b) or #(2, 3) (y, a, b); (c) bufif1 #(1, 2, 3) (y, a, en); (d) nand #(1:2:4) (y, a, b).

Exercise 2 — Choose the form

Which delay form fits each need: (a) the same delay for all transitions; (b) different rise and fall times; (c) a tri-state buffer's drive-to-z time; (d) simulating at the worst-case process corner.

Exercise 3 — Fix the delay bugs

Identify and fix each: (a) and #5 (y, a, b) in a synthesizable design module; (b) or #(2,3,4) (y, a, b) expecting the third value to do something.

Exercise 4 — Reason about timing

(a) Why does synthesis ignore a gate delay? Where does the real timing come from? (b) What does an inertial delay do to a glitch narrower than the delay? (c) When would you use the min:typ:max form?

12. Summary

A gate delay specifies a gate primitive's propagation delay in simulation, in several granularities:

Single / rise-fall / rise-fall-turnoff — #d, #(rise, fall), #(rise, fall, turnoff) (turn-off for tri-state → z).
min:typ:max — #(min:typ:max) per value, for corner simulation (typ by default).
Inertial — input pulses narrower than the delay are filtered (a gate rejects glitches).

The central point:

Gate delays are simulation-only — synthesis ignores them; real timing comes from the standard-cell library and back-annotated SDF.
Synthesizable RTL has no # delays — delays live in modelling and testbench code.

Chapter 11 complete

This closes Chapter 11 — Gate-Level Modeling, the reference chapter on structural description: the gate primitives (11.1) and their delays (11.2). You can now read the netlist level — the form synthesis outputs and libraries use — without it being how you author RTL.

The next reference chapter goes one level lower still — to transistors: Chapter 12 Switch-Level Modeling covers MOS switch primitives (nmos, pmos, cmos, transmission gates) and drive-strength resolution, the transistor-level view used for specialized cells and analog-adjacent circuits. After that, the RTL core resumes at the level you actually design in: Chapter 14 Behavioural Modeling — always blocks, blocking vs non-blocking, and sequential logic.

Pre-defined Gate Primitives — Chapter 11.1; the gates these delays apply to.
Continuous Assignments — Chapter 13.1; the continuous-assignment delay with the same simulation-only nature.
`timescale — Chapter 7.3; the time unit and precision that gate delays are measured in.
Gate-Level Modeling — Chapter 11 overview; the structural context.