Skip to content
VLSIMentor

Verilog · Chapter 17.4 · Delay Modeling

Module Path Delays & the specify Block in Verilog — Pin-to-Pin Timing

Earlier delay lessons placed delay inside a module, on its gates, shaping its pulses, and across its process corners. This lesson times a module from the outside. A module path delay specifies the propagation delay directly from an input pin to an output pin, treating the internal logic as a timing black box. This is how real standard cells are modelled, since a library characterizes each cell as a set of input-to-output path delays rather than delayed gates. Path delays live in a specify block, a dedicated region inside the module, and they carry the same corner and rise-fall forms you have already met, which is exactly the shape that post-layout SDF timing back-annotates onto. The specify block also hosts timing checks, making this page the gateway to the timing checks chapter that follows.

Intermediate13 min readVerilogDelay Modelingspecify BlockPath DelaySDF

Chapter 17 · Section 17.4 · Delay Modeling

1. The Engineering Problem

You need to model a standard cell — say a 2:1 mux — with the timing a real library uses. The previous pages gave you two ways to place delay inside the cell, and neither matches how cells are actually characterized:

how-are-cells-really-timed.v
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
   // Distributed (17.1): a delay on every internal gate — but a cell's
   // datasheet doesn't list internal-gate delays; it lists PIN-TO-PIN times.
   // Lumped (17.1): one number at the output — too coarse; the delay from
   // d0→y differs from the delay from sel→y, and lumping erases that.
   //
   // What a real library actually specifies:
   //   "the delay from input pin d0 to output pin y is 3 ns"
   //   "the delay from input pin sel to output pin y is 2 ns"
   // ... a separate, characterized delay for EACH input-to-output PATH.

A cell library does not describe a cell by its internal gates — it describes it by the delay along each path from an input pin to an output pin. Verilog models exactly this with a module path delay, declared in a specify block. The internal logic computes the function; the specify block supplies the timing, per path, from the outside.

A module path delay specifies the propagation delay directly from an input pin to an output pin, declared in a specify block — the way real standard cells are timed, and the form post-layout SDF back-annotates onto.

2. Mental Model — Time the Cell from Its Pins, Not Its Guts

3. The Hardware View

A 2:1 mux, timed by its pins. Each input has its own characterized path to the output.

Visual A — pin-to-pin module path delays

Module path delays — one characterized path per input pin

data flow
Module path delays — one characterized path per input pind0 → ydata path: 3 nsd1 → ydata path: 3 nssel → yselect path: 2 nsoutput ytimed per path, not per gate
A module path delay times each input-to-output path independently: d0→y and d1→y at 3 ns, sel→y at 2 ns. The internal logic is a zero-delay function; the specify block supplies the timing from the pins. This is how a standard cell is characterized — and SDF back-annotates these exact paths.

4. The specify Block

Module path delays live in a specify ... endspecify region inside the module. specparam declares timing constants local to that block.

specify-basics.v
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
   module mux2 (output y, input d0, d1, sel);
       // Internal function — zero delay; it computes WHAT y is.
       assign y = sel ? d1 : d0;
 
       // specify block — supplies the TIMING, per pin-to-pin path.
       specify
           specparam tData = 3;        // local timing parameter
           specparam tSel  = 2;
           (d0  => y) = tData;         // path: d0 to y
           (d1  => y) = tData;         // path: d1 to y
           (sel => y) = tSel;          // path: sel to y
       endspecify
   endmodule
  • The specify/endspecify block sits inside the module, alongside the logic.
  • specparam is like parameter, but scoped to the specify block and meant for timing values — and overridable by SDF back-annotation.
  • Each line (in => out) = delay; is one module path delay: the propagation time along that input-to-output path.

5. Path Declarations — Parallel vs Full Connection

There are two path-connection operators, and choosing the wrong one is a classic bug.

parallel-vs-full.v
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
   // PARALLEL connection ( => ): bit-to-bit, source and dest same width.
   (a => y) = 5;                 // a[i] drives y[i], each its own path
 
   // FULL connection ( *> ): every source bit to every dest bit (all-to-all).
   (a, b *> y) = 5;              // a→y AND b→y; any input bit affects any out bit
  • => (parallel) connects the source to the destination bit-for-bit — use it when an input bit maps to the corresponding output bit (same width).
  • *> (full) connects every source bit to every destination bit — use it when any input can affect any output bit, or to declare several inputs to one output in a single line.

The rule of thumb: when in doubt about whether an input affects an output, *> is the safe, complete choice. An input-to-output path you forget to declare gets no path delay — it simulates at zero delay (the §10 DebugLab).

6. Edge-Sensitive and Conditional Paths

Two refinements cover sequential cells and mode-dependent timing.

edge-and-conditional.v
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
   // EDGE-SENSITIVE path — a clock-to-q delay (the flip-flop case):
   (posedge clk => (q +: d)) = 3;     // on posedge clk, q follows d, 3 ns later
 
   // STATE-DEPENDENT path delay (SDPD) — delay depends on a condition:
   if (sel)  (d1 => y) = 4;           // when sel=1, the d1→y path is 4 ns
   if (!sel) (d0 => y) = 4;           // when sel=0, the d0→y path is 4 ns
  • An edge-sensitive path ties the output transition to a clock edge — (posedge clk => (q +: d)) is the clock-to-q delay of a flip-flop. (The +: marks a non-inverting data path; -: would be inverting.)
  • A state-dependent path delay (SDPD) makes a path's delay depend on the design's state via if (...) — used when a cell's timing genuinely differs by mode. These are the constructs that let a specify block reproduce a real sequential cell's characterized timing.

This page introduces them; the everyday case is the simple (in => out) = delay; path. The point is that the specify block is expressive enough to time any cell — combinational, sequential, or mode-dependent.

7. Path Delays Carry Corners and Directions — and SDF Overrides Them

Module path delays are not a new delay value format — they reuse everything from 17.3:

paths-with-corners-and-directions.v
Azvya Education Pvt. Ltd.VLSI Mentor
Snippet
   (a => y) = (1:2:3);                 // min:typ:max on a path
   (a => y) = (2:3:4, 5:6:7);          // rise triplet, fall triplet on a path

A path delay can be a single value, a min:typ:max triplet, and/or rise/fall (and turn-off) values — the corner and direction axes apply to paths exactly as they do to gates. This matters because it is the same shape a post-layout SDF file carries:

In production, the specify block's specparam and path delays are placeholders. After layout, a Standard Delay Format (SDF) file — with real, extracted, per-path, per-corner, per-direction delays — is back-annotated onto the netlist, overriding the specify values. The specify block is the interface; SDF supplies the data.

This is why pin-to-pin path delays, not distributed or lumped, are the production model: they are precisely the granularity at which cells are characterized and at which SDF delivers timing.

8. The Bridge — the specify Block Hosts Timing Checks

The specify block has a second tenant, and it is the reason this page is the gateway to the rest of the timing curriculum:

The specify block — two tenants

data flow
The specify block — two tenantsspecify ...endspecifythe timing region of a cellmodule pathdelayspin-to-pin timing (this page, 17.4)timing checks$setup / $hold / $width … (Chapter 18)
The specify block holds two things: the module path delays that time a cell (this page), and the timing checks that VERIFY a cell's inputs arrive within their required windows (Chapter 18). Having built the path-delay half, you are ready for the timing-check half.

A real cell model has both: path delays that say how long signals take, and timing checks that say when signals must arrive (setup, hold, minimum pulse width). You have now built the first half. Chapter 18 Timing Checks fills the same specify block with the second half — turning a timed cell into a cell that flags violations when data arrives too late or too early.

9. Common Mistakes

  1. Forgetting a path. An input-to-output path you don't declare gets no path delay and simulates at zero delay, making the cell partially timed (§5, DebugLab).
  2. => where *> was needed. Parallel (=>) is bit-to-bit; if any input bit can affect any output bit, you need full (*>) — otherwise paths are missing (§5).
  3. Putting logic in the specify block. A specify block holds path delays, specparams, and timing checks — not assignments or behavioural code. The function lives in the module body; the timing lives in specify.
  4. Confusing specparam with parameter. specparam is for timing, scoped to the specify block, and SDF-overridable; parameter is a general elaboration constant. They are not interchangeable.
  5. Expecting path delays to synthesise. Like all delay modelling, the specify block is simulation-only — synthesis ignores it (Chapter 17 overview).

10. Debugging Lab

The mux whose select arrived instantly

11. Interview Q&A

12. Exercises

Exercise 1 — Time the cell

Write a specify block for a 2-input XOR y = a ^ b with both input-to-output paths at 4 ns. Then rewrite it using full connection (*>) in one statement.

Exercise 2 — Parallel or full?

For each, choose => or *>: (a) an 8-bit buffer where bit i drives bit i; (b) an AND gate where both inputs affect the single output; (c) an adder where any input bit can affect any sum bit.

Exercise 3 — Find the missing path

A 2:1 mux specify block declares (d0 => y) and (d1 => y) but not (sel => y). Describe the resulting timing behaviour when sel toggles, and give two ways to fix it.

Exercise 4 — Where does it live?

Classify each as belonging in the module body or the specify block: (a) assign y = a & b;; (b) (a => y) = 3;; (c) specparam tPD = 2;; (d) $setup(d, posedge clk, 2);.

13. Summary

A module path delay times a cell from its pins, not its internals:

  • (in => out) = delay; in a specify block declares the propagation delay along one input-to-output path — the way real standard cells are characterized.
  • => (parallel) is bit-to-bit; *> (full) is every input bit to every output bit. A path you don't declare simulates at zero delay — declare them all, or use *>.
  • Edge-sensitive paths (posedge clk => (q +: d)) time sequential cells; state-dependent paths (if (...)) time mode-dependent cells.
  • Path delays carry min:typ:max and rise/fall forms (17.3) — the same shape SDF back-annotation overrides them with after layout.
  • The specify block also hosts timing checks — making it the bridge from delay modelling to Chapter 18.

This closes Chapter 17 Delay Modeling — where delay lives (17.1), how a pulse survives it (17.2), which value it takes across corners and directions (17.3), and per-pin path delays in a specify block (17.4). Together they make a simulation timing-aware.

Chapter 18 Timing Checks picks up inside the very same specify block: instead of saying how long signals take, it teaches the simulator to detect when a signal arrives too late or too early — setup, hold, and the rest. Chapter 19 Timing Regions then explains the event ordering that makes all of it deterministic.