The three GLS simulation modes — zero delay, unit delay, and SDF-annotated — and the two physical delay models — transport and inertial. How each mode is used, what it catches, and how pulse rejection works.
Every gate-level simulation run operates in one of three delay modes. The mode determines what timing information the simulator uses — and therefore what categories of bugs it can detect. Choosing the wrong mode wastes time or misses failures entirely.
The three GLS delay modes on a fidelity spectrum. Zero delay is the fastest and least accurate — it ignores all timing and simply verifies structural behaviour. Unit delay adds a nominal 1-unit delay to every element, enabling race condition detection. SDF-annotated simulation uses real back-annotated delays and is the slowest but most accurate — the only mode that can catch genuine timing violations.
Zero delay simulation runs the gate-level netlist without any timing information. All propagation delays through logic gates, wires, and flip-flops are treated as instantaneous. The simulator evaluates logic state transitions immediately, as if the circuit had no propagation delay at all.
Standard cell models in HDL contain a specify block — a dedicated section that lists timing arcs (input-to-output path delays) and timing checks (setup, hold, recovery, removal constraints). In zero delay mode, these specify blocks are completely suppressed. Similarly, if an SDF file is present and referenced in the testbench, the simulator ignores it and does not annotate any delays. Every cell output transitions in zero simulation time after its inputs change.
#5 in an RTL model) — those remain active. Purely structural, cell-based netlists produced by synthesis typically contain no such expressions, so in practice a synthesised netlist under zero-delay mode really does behave as instantaneous logic.
A critical limitation of zero-delay simulation is that it can create spurious race conditions that do not exist in silicon. When two signal transitions arrive at a gate at exactly the same simulation time (because all delays are zero), the simulator must choose an arbitrary order to evaluate them. This can produce X values or incorrect results that would never occur in real hardware, where propagation delays naturally order events. These are false races — simulation artefacts, not real bugs.
Unit delay simulation assigns a uniform delay of exactly 1 simulation time unit to every non-zero delay element in the design. All module path delays, gate delays, and continuous assignment delays are replaced with this single value, regardless of their actual timing.
In unit delay mode, the simulator replaces all non-zero structural and continuous assignment delay expressions with 1 time unit. Timing checks described in specify blocks are still suppressed — the mode provides ordering between events without accurate timing constraint checking.
This small but uniform delay has one critical effect: it separates simultaneous events in simulation time, eliminating the zero-delay ordering ambiguity that causes false races. If signal A and signal B both change at time 10, a gate driven by both will evaluate its new output at time 11 (not time 10), giving simulation time to see the intermediate states and evaluate correctly.
SDF-annotated simulation (Standard Delay Format simulation) is the most realistic and most important GLS mode. Real propagation delays — extracted from the physical implementation — are annotated into the gate-level netlist before simulation begins. This process is called back-annotation.
An SDF file is generated by the backend implementation tool — synthesis, place-and-route, or static timing analysis — and contains two categories of data:
The simulator reads the SDF file and annotates each delay value to the matching instance and timing arc in the netlist. Once annotated, the simulation proceeds with real delays in place — exactly as if the actual silicon were being simulated.
SDF back-annotation flow. The synthesis, P&R, or STA tool generates an SDF file containing IOPATH delays and timing check values. The annotator reads this file and writes actual delay values into the matching gate-level netlist instances. The simulator then propagates signal transitions using these real delays and evaluates timing check violations against the annotated thresholds.
A single SDF file typically contains three delay values for each timing arc — minimum, typical, and maximum. These correspond to different Process-Voltage-Temperature (PVT) corners:
| Corner | Delay value | When used for GLS | What it checks |
|---|---|---|---|
| Maximum (Slow) | Worst-case slow process, lowest voltage, highest temperature | Setup timing verification (signoff) | Paths that take the longest — setup violations occur here |
| Minimum (Fast) | Best-case fast process, highest voltage, lowest temperature | Hold timing verification | Paths that take the shortest — hold violations occur here |
| Typical | Nominal process, nominal voltage, nominal temperature | Development and debug runs | Representative of silicon centre-of-distribution — fastest simulation |
| Mode | When to use | What it verifies | What it misses |
|---|---|---|---|
| Zero delay | Immediately after first synthesis. Before SDF is available. DFT sign-off. Reset/init verification. | Functional correctness of netlist. Reset sequences. Scan chain structure. Power domain initialisation. | Any timing-related failure. Cannot detect setup/hold, glitches, or race conditions. |
| Unit delay | When zero-delay runs produce suspicious false-race failures. Intermediate step between zero-delay and SDF. Loop detection. | Genuine race conditions that zero delay confused with false races. Timing-sensitive feedback loops. | All actual timing constraints. Not suitable for timing signoff. |
| SDF annotated | After P&R when SDF is available. Slow-corner signoff. Hold-corner verification. Final frequency check. | Setup and hold violations. Combinational glitches. Clock tree behaviour. Correct operation at target frequency. | Only as good as vector coverage. Cannot check paths not exercised by testbench. |
Scenario A: Synthesis just completed. SDF not yet available. The RTL testbench has 95% code coverage. Goal: confirm synthesis did not break anything.
Answer: Zero-delay GLS. Run the existing testbench against the gate-level netlist with specify blocks suppressed. Any failure relative to RTL simulation is a synthesis functional error.
Scenario B: Zero-delay GLS is producing sporadic X values on a data bus that only appear when two signals change at the exact same simulation time. The design team believes the logic is correct.
Answer: Switch to unit delay. If the X values disappear, they were false races caused by zero-delay simultaneous evaluation. If they persist, investigate the logic — it is a genuine ordering issue in the design.
Scenario C: Post-P&R. Slow-corner SDF delivered. Design target is 1 GHz. Goal: confirm all flip-flops meet their setup requirements at 1 ns clock period.
Answer: SDF-annotated simulation at the slow corner, maximum delay values. The simulator will report any $setuphold timing check violations. Failures must be categorised: annotation problems (fix the SDF/netlist mismatch) vs genuine timing violations (report to backend).
Beyond the three simulation modes, there is a second independent axis of delay behaviour: how the simulator models the physical propagation of signals through gates and wires. Two models exist — transport delay and inertial delay — and they differ in how they handle pulses that are shorter than the propagation delay of the element.
Transport vs inertial delay with a gate delay of 2 time units. The input has two pulses: a narrow pulse of width 1 (less than the gate delay) and a wide pulse of width 3 (greater). Transport delay (blue): all pulses are delayed by 2 and propagated — the narrow pulse appears at the output shifted by 2. Inertial delay (orange): the narrow pulse is rejected because it did not persist for the full gate delay duration. Only the wide pulse propagates.
Transport delay propagates every signal transition to the output, shifted in time by the propagation delay, regardless of how narrow the input pulse is. The output waveform is a time-shifted copy of the input waveform. This model is appropriate for:
Inertial delay rejects pulses that are narrower than the propagation delay of the element. Physically, a real CMOS gate has a characteristic response time — a pulse that is shorter than this response time does not carry enough energy (charge/discharge on the output node capacitance) to drive the output to a new logic level. The gate acts as a low-pass filter, smoothing out glitches shorter than its own delay.
Inertial delay is the physically correct model for CMOS gate delays. Most simulators use inertial delay as the default for cell path delays and transport delay as the default for interconnect (wire) delays — which matches the physical reality.
| Delay type | Propagates narrow pulses? | Physically models | Typical use |
|---|---|---|---|
| Transport | Yes — all pulses delayed and passed | Ideal wire / conductor with propagation delay | Interconnect delays (wire parasitics) |
| Inertial | No — pulses narrower than delay are rejected | Real CMOS gate (capacitive load, charge threshold) | Cell path delays (gate propagation) |
In SDF-annotated simulation, the distinction between transport and inertial behaviour at cell outputs determines whether combinational glitches propagate to downstream flip-flop inputs. This has direct consequences for functional correctness and timing violation reporting.
A glitch is a spurious, unintended logic transition on a signal — a brief pulse caused by combinational logic hazards. When multiple paths of different lengths converge at the same gate, the input signals change at slightly different times. The gate may briefly see an invalid input combination and produce a transient output that settles to the correct final value. If this transient pulse is narrower than the gate’s inertial delay, the glitch is absorbed and does not propagate further. If it is wider, it propagates downstream and may corrupt flip-flop state.
Combinational glitch generation. Input A (fast path) arrives at the AND gate before input B (slow path). In the interval t1–t2, A is high but B is still low — the correct AND output is 0. However, the circuit hazard creates a brief spurious 1 at the output. Under transport delay, this glitch propagates to the next stage. Under inertial delay, it is absorbed if its duration (t2−t1) is less than the downstream gate’s propagation delay.
When running SDF-annotated simulation with inertial delay, the simulator allows the engineer to configure exactly how aggressively pulses are rejected and how violations are reported. Two thresholds control this:
A pulse narrower than the reject limit is absorbed. A pulse between the reject and error limits produces an X on the output and a warning. A pulse wider than the error limit propagates normally.
Standard cell library models include a specify block — a special HDL construct that declares the timing arcs and checks for a cell. The specify block is the bridge between the SDF file and the simulation engine. Understanding what it contains explains why SDF annotation works the way it does.
| Specify construct | What it declares | SDF keyword |
|---|---|---|
| Module path delay | Propagation delay from an input port to an output port. e.g. A→Y takes 200ps rising, 180ps falling. | IOPATH |
| Setup check | Minimum time data must be stable before the clock edge at a flip-flop input. | SETUP / SETUPHOLD |
| Hold check | Minimum time data must remain stable after the clock edge. | HOLD / SETUPHOLD |
| Recovery check | Minimum time an asynchronous reset must be deasserted before the next clock edge. | RECOVERY / RECREM |
| Removal check | Minimum time an asynchronous reset must remain asserted after the clock edge. | REMOVAL / RECREM |
| Width check | Minimum pulse width on a clock or asynchronous control pin. | WIDTH |
When the simulator reads an SDF file, it matches each entry to the corresponding construct in the specify block of the target cell instance. If the SDF specifies a delay for an IOPATH A→Y arc and the specify block contains that arc, the annotation succeeds. If either the SDF references an arc that does not exist in the specify block, or the specify block has an arc the SDF does not reference, an annotation warning is generated.
Scan chains in a design contain hundreds to thousands of flip-flops connected in a serial shift register. At scan-shift frequency (typically a fraction of the functional clock to relax timing), data is shifted through all flip-flops sequentially. At at-speed scan, the design captures functional data at the full operating frequency. During at-speed capture, combinational logic paths between flip-flops are exercised at full speed — and the same inertial delay behaviour that filters short glitches in functional mode also affects whether scan-captured data is correct or corrupted by a glitch. This is why at-speed scan GLS must use SDF-annotated simulation with appropriate inertial delay settings, not zero-delay or unit-delay mode. A zero-delay scan test can pass while a genuine at-speed scan capture failure exists.
Running a complete GLS regression at three corners (slow setup, fast hold, typical) multiplies the simulation time by three. For large SoCs with millions of gates and thousands of test vectors, a single SDF GLS run can take days. Teams typically run zero-delay GLS continuously in regression from the first netlist forward (fast, catches functional bugs), run typical-corner SDF GLS for development debug (moderate time, catches most timing issues), and reserve slow/fast corner signoff runs for scheduled milestones. This staged approach keeps the feedback loop tight during development while still providing full signoff coverage at the appropriate points in the schedule.
From a VLSI design perspective, the specify block in a cell model is the formal contract between the standard cell library characterisation team and the simulation tool. The library team extracts timing arcs (IOPATH) and timing check values ($setuphold, $recrem, $width) by SPICE simulation of the transistor-level cell at each PVT corner. These values are then packaged into both the .lib file (for STA) and the specify block of the Verilog simulation model (for GLS). When the SDF contains a path that the specify block does not — typically because synthesis used a liberty attribute or timing arc that was not modelled in the simulation model — the simulator cannot annotate it and issues an SDFNEP warning. Resolving these mismatches requires either updating the simulation model to add the missing arc, or waiving the warning with a documented justification. In verification roles at tapeout, managing the list of waived SDF annotation warnings is a day-to-day task.