Unit Delay Simulation: The Intermediate Step in GLS Explained

Unit delay simulation is a gate-level simulation in which every cell is given the same small delay, typically one time unit, instead of real delays from an SDF file. It is used as an intermediate step on the netlist before timing-accurate SDF is available, mainly to remove the delta-cycle races that make zero-delay gate simulations disagree with RTL. It is not a timing check, and its results should never be used as timing evidence.

Key takeaways

• All cells get identical delays, so event order becomes deterministic along data paths.
• It can be run as soon as a netlist exists, before the design is timing clean and before SDF is written.
• It helps iron out simulation and synthesis mismatches caused by delta-delay races.
• It must not be used to generate test stimuli or to judge timing, because real delays differ.
• Clock tree buffers in the netlist can create false hold failures under unit delay, so run it with ideal clocks or know how your flow handles them.

What unit delay simulation is

This is an intermediate step during gate level simulation.

Unit delay simulation operates on the assumption that all the elements in a circuit possess identical delays. This has an advantage that it can be set up early in the flow when the post layout netlist is ready but before the SDFs are available, which could be due to the fact that the design is not timing clean and is in the process of being timing closed.

What it is used for, and what it should not be used for

Primarily unit delay sims help in ironing out any possible simulation synthesis mismatches due to delta delay issues and so are widely used in the industry. But this kind of simulation should not be used to generate test stimuli. If done, this will give a false sense of security as the timing for the actual circuit will not resemble the results shown by the unit delay simulation. Another major disadvantage of unit delay simulation is that since the elements have non-zero delay, the design cannot be rank-ordered for simulation and hence unnecessary evaluation of elements several times in the same period can happen.

Unit delay simulation will work for	Unit delay simulation will not work for
Finding delta-cycle races in a zero-delay netlist run	Proving setup or hold timing
Early functional checks on the netlist before SDF	Generating or qualifying test (ATE) stimuli
Checking reset and initialization sequences at gate level	Finding real glitches or hazards on silicon
Making waveforms easier to read, since cause and effect are separated in time	Netlists with clock tree buffers, unless clocks are ideal

Why zero delay gate simulation has races

In a zero-delay netlist, a flip-flop output changes in the same simulation time step as the clock edge that caused it. If a second flip-flop is clocked by the same edge and its D input is driven by the first flop, whether it captures the old or the new value depends on the order in which the simulator processes events in that time step. Verilog does not define that order, so two simulators, or two runs of the same simulator after a small change, can give different answers. The background is covered in transport, inertial and delta delay in VHDL and Verilog.

With a unit delay on every cell, the first flop's output moves one time unit after the edge, so the second flop has already sampled the old value. The result is deterministic and matches the RTL intent.

Event	Zero delay	Unit delay (1 unit per cell)
Clock rises	t = 10	t = 10
FF2 samples its D input	t = 10	t = 10
FF1 output Q1 changes	t = 10, same step, order undefined	t = 11
Value captured by FF2	Old or new, depends on event order	Old value, as in RTL

Worked example: a pulse generator under unit delay

The small netlist below ANDs a signal with a delayed, inverted copy of itself. In zero-delay simulation the output never shows a pulse. With one time unit per gate, the waveform shows a pulse whose width equals the delay of the inverter chain. This shows both the strength and the weakness of unit delay: you see the structure of the logic, but the pulse width is three units only because every gate was given one unit, not because the silicon behaves that way.

`timescale 1ns/1ns
module pulse_gen (input a, output y);
  wire n1, n2, n3;
  not #1 u1 (n1, a);
  not #1 u2 (n2, n1);
  not #1 u3 (n3, n2);
  and #1 u4 (y, a, n3);
endmodule

module tb;
  reg a = 1'b0;
  wire y;
  pulse_gen dut (.a(a), .y(y));
  initial begin
    $monitor("%0t a=%b n3=%b y=%b", $time, a, dut.n3, y);
    #10 a = 1'b1;
    #10 $finish;
  end
endmodule

Time (ns)	a	n1	n2	n3	y
10	1	1	0	1	0
11	1	0	0	1	1
12	1	0	1	1	1
13	1	0	1	0	1
14	1	0	1	0	0

The output y is high from 11 ns to 14 ns. In a real library the inverters and the AND gate have different delays, and the pulse width would come from the SDF, not from counting gates.

How unit delay is applied in practice

Library cell models usually carry their own delays in specify blocks. Rather than edit the library, engineers use the simulator's delay-mode controls, which can replace the delays on gates and cells with a single unit value or ignore path delays altogether. The exact option names differ between simulators, so check your simulator's documentation for its delay-mode settings. Timing checks are usually disabled in unit delay runs, since the limits they test against are meaningless with artificial delays.

Unit delay and FPGAs or CPLDs

Unit delay simulation is very useful for FPGAs and CPLDs, since these are fixed array circuits of rows and columns with identical elements that may be a NAND or NOR gate or a collection of resistors and transistors. Switching elements connected in this way usually have the same switching speed, in which case unit delay sims become very meaningful. If the switching speeds are integral multiples of one another, unit delay sims can still be effectively implemented.

Note (2026): in current FPGAs, routing delay often dominates and varies widely with placement, so FPGA vendors' flows rely on static timing analysis and timing simulation with vendor-generated SDF for timing confidence. Unit delay remains useful for the same race-removal purpose described above.

Mistakes to avoid

• Running unit delay on a post-CTS netlist with ideal-clock assumptions. A chain of four clock buffers adds four units of skew, which can exceed a one-unit data path and produce hold failures that do not exist on silicon.
• Signing off timing with unit delay results.
• Reusing waveforms from a unit delay run as ATE test patterns.
• Leaving timing checks enabled and chasing violations that come only from the artificial delays.

Frequently asked questions

What is the difference between zero delay and unit delay simulation?

Zero delay makes every cell switch in the same time step as its input, which can create order-dependent races. Unit delay gives every cell the same small delay so cause and effect are separated in time. See zero delay simulation, why and when.

When should unit delay simulation be run?

After a netlist exists and before SDF is available, typically on the synthesis netlist with ideal clocks. A newer overview is in unit delay simulation, why and when.

Does unit delay simulation need an SDF file?

No. That is its main advantage early in the flow.

Can unit delay simulation find timing violations?

No. Real cell and wire delays differ, so only SDF-annotated simulation and static timing analysis can do that.

Related reading

• Gate-level simulation interview questions with worked answers
• GLS (gate-level simulation) in The Semiconductor Hub glossary