GLS · Chapter 0 · Foundation

Zero-Delay vs Unit-Delay vs Full-Timing GLS

Gate-level simulation can be run in three timing modes, and choosing the right one is a skill in itself. Zero-delay runs every gate with no delay, so all logic settles in the same simulation instant. It is fastest and ideal for checking function, unknowns, and reset, but it is prone to ordering artifacts called zero-delay races and is blind to real timing. Unit-delay gives every gate one arbitrary time unit, which adds causal ordering so combinational settling and simple races become visible and deterministic, though it is still not real timing. Full-timing back-annotates real SDF delays and reproduces real cell and interconnect behavior, making it the slowest and signoff-quality run. This lesson explains the three modes, maps them onto the two flow insertion points, and shows a zero-delay race that looks like a design bug but is really a mode artifact.

Foundation12 min readGLSZero-DelayUnit-DelayFull-TimingSDFRaces

Chapter 0 · Section 0.4 · GLS Foundations

Project thread — the same netlist from 0.3 (still the 0.1 D flip-flop), now run in three timing modes so you see how the mode shapes what you observe, before reading real waveforms in 0.5.

1. Why Should I Learn This?

Choosing the GLS timing mode is a decision you make every time you run, and getting it wrong costs you twice: run full-timing when you only needed to check function and you burn days of simulation for no reason; run zero-delay and hit a race and you waste hours chasing a "bug" that is really a mode artifact. Knowing what each mode shows, what each hides, and what each costs is what lets you match the mode to the question — the difference between an efficient GLS effort and a frustrating one.

The three modes also organise the flow: post-synthesis GLS (function, cheap) uses zero/unit-delay; post-layout GLS (real timing) uses full-timing (0.3). Understanding the modes is understanding why each insertion point runs the way it does.

2. Industry Story — the "bug" that was a zero-delay race

An engineer runs a zero-delay GLS on a freshly synthesized block to check function quickly. On one signal, the output is wrong on some runs and right on others — non-deterministically, changing when unrelated code is edited or the tool version bumps. It looks like a serious, intermittent design bug, and hours go into staring at the logic, which is correct.

The signal in question was captured by a flop at the same simulation instant its data was changing — a clock edge and a data change landing in the same zero-delay moment. With no delays, the simulator had no basis to order 'did the data settle before or after the capture?', so the result depended on evaluation order — a zero-delay race — which shifted with unrelated changes. Re-running the same netlist in unit-delay mode (one time unit per gate) gave the data a definite, earlier arrival relative to the capture, so the race disappeared and the result became deterministic and correct. The 'bug' was never in the design — it was an artifact of running a timing-sensitive question in a mode that has no timing to resolve it. The post-mortem lesson: zero-delay GLS settles all logic in the same instant, so a clock edge and its data can race with order-dependent, non-deterministic results — that is a mode artifact, not a design bug; a timing-ordering question needs at least unit-delay (or full-timing), while zero-delay is for function/X/reset questions that do not depend on ordering. Choose the mode for the question.

3. Concept — three modes, three trade-offs

The three GLS timing modes differ in how much timing they model, trading realism for speed:

Zero-delay. Every gate has no delay; all logic settles in the same simulation instant (delta cycles, no time advance). Fastest. Good for: function (netlist matches RTL) and X/reset cleanliness. Hazards: zero-delay races (a clock edge and its data in the same instant -> order-dependent result) and blind to real timing (no glitches, no clk-to-q, no setup/hold events).
Unit-delay. Every gate has one arbitrary time unit of delay. Adds causal ordering: combinational logic settles over a few units, so signal sequence is well-defined and simple races become deterministic and visible. Cheap. Still not real timing — a unit is not a nanosecond, so it does not model real margins.
Full-timing. Real SDF delays (cell + interconnect, Ch4). Reproduces real timing: real clk-to-q, glitches, pulse rejection, setup/hold as simulated events. Slowest. The signoff-quality run.

Map to the flow (0.3): post-synthesis GLS is usually zero/unit-delay (function, cheap); post-layout GLS is full-timing (real delays). Here are the three side by side:

Figure 1 — the three GLS timing modes trade realism for speed. ZERO-DELAY: no delays, all logic settles in one instant — FASTEST, great for function + X/reset, but prone to zero-delay RACES (clk vs data in the same instant) and blind to real timing. UNIT-DELAY: 1 arbitrary unit per gate — adds causal ORDERING so sequence is deterministic and simple races resolve; cheap, but a unit is not a nanosecond (not real timing). FULL-TIMING: real SDF delays — reproduces real clk-to-q, glitches, setup/hold as events; SLOWEST, signoff-quality. Post-synthesis GLS uses zero/unit-delay; post-layout GLS uses full-timing. Choose the mode for the question.

4. Mental Model — resolution knobs: sketch, storyboard, and film

Mental Model — zero-delay is a sketch (fast, no time), unit-delay is a storyboard (ordered frames), full-timing is the film (real timing)

The three modes are three resolutions of the same scene. Zero-delay is a sketch — instant, captures what happens but nothing about when. Unit-delay is a storyboard — ordered frames, so you see the sequence, but the frames are evenly spaced, not real-time. Full-timing is the film — real durations, so you see exactly when everything happens.

A sketch (zero-delay) is the fastest way to check the content of a scene — who is in it, does the story make sense (does the netlist function, is it X/reset clean) — but it has no time axis at all, so if two events happen 'at once' you cannot tell which came first; ask a when-question of a sketch and you get an ambiguous answer (a zero-delay race). A storyboard (unit-delay) adds ordered frames — now events have a definite sequence, so 'the data settled, then the clock captured it' is unambiguous — but the frames are evenly spaced, not real durations, so it tells you order, not real timing margins. The film (full-timing) has real durations on every action — the actual clk-to-q, the real glitch width, the true setup/hold window — so it is the only resolution that answers real-timing questions, and it is correspondingly the most expensive to produce. The skill is to match the resolution to the question: sketch to check content fast, storyboard when you need ordering, film when you need real timing. Reaching for the film every time is wasteful (days of render for a content check); using the sketch for a timing question is worse than wasteful — it gives a confidently wrong-looking answer (the race) that is really the medium's inability to represent time. So: zero-delay for what, unit-delay for what-then-what, full-timing for what-and-when-exactly.

Two anchors:

Zero-delay = content, no time (function/X/reset). Unit-delay = order, no real time (sequence/races). Full-timing = real time (margins/glitches/signoff). Match the mode to the question.
A race in zero-delay is the medium's inability to represent time, not a design bug. If a result is order-dependent in zero-delay, add ordering (unit-delay) or real timing (full) before concluding anything about the design.

5. Working Example — one design, three modes, three answers

Take the D flip-flop again. Watch how the capture event looks in each mode.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// A flop capturing d on a clock edge. We run the SAME netlist in three modes.
module dff_netlist (input clk, input rst_n, input d, output q);
  DFFRX1 U0 (.D(d), .CK(clk), .RN(rst_n), .Q(q));
endmodule

A GLS-adapted testbench idea that stresses ordering: let d change at the same nominal time as the clock edge, so the mode's timing model decides the outcome.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Testbench IDEA (conceptual): change d at ~the same instant as the clock edge -> ordering matters.
initial begin
  rst_n = 0; d = 0; clk = 0;
  #7 rst_n = 1;
  #3 d = 1;                 // d rises at t=10 ...
  #100 $finish;
end
always #5 clk = ~clk;      // ... and a posedge also occurs at t=10 -> a race in zero-delay

The three modes give three answers to 'what did the flop capture at t=10?':

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# ZERO-DELAY: clk edge and d-change are the SAME instant -> ORDER-DEPENDENT (a race). Non-deterministic.
t=10 clk^ d=? q=?          <- 'q' may be 0 OR 1 depending on evaluation order -> looks like a bug (it isn't)
 
# UNIT-DELAY: d-change gets a definite (unit) ordering vs the edge -> DETERMINISTIC (here d settles, q=1)
t=10 clk^  d->1(+1u)  q->1 <- sequence is defined; the race is gone
 
# FULL-TIMING (SDF): real clk-to-q AND a real setup window -> if d changes INSIDE setup, a REAL check fires
t=10 clk^
t=10.3 q->1                <- real clk-to-q; and if d violated the real setup window, a setup-violation msg

Same netlist, same stimulus, three different (correct-for-their-mode) answers. Zero-delay cannot resolve the ordering (race); unit-delay orders it deterministically; full-timing shows real clk-to-q and would flag a real setup violation if d truly landed inside the window. The lesson is not that one mode is 'right' — it is that each answers a different question, and you must pick accordingly. The next section is the trap of asking a timing question in zero-delay.

6. Debugging Session — a non-deterministic "bug" that was a zero-delay race

A signal is wrong on some zero-delay GLS runs and right on others, non-deterministically — a zero-delay race from a clock edge and its data landing in the same instant, not a design bug

A ZERO-DELAY RACE IS A MODE ARTIFACT

Symptom

Running zero-delay GLS, a captured signal is wrong on some runs and right on others — non-deterministically. The result changes when unrelated code is edited, when the file order changes, or when the simulator version is bumped — none of which should affect a correct design. It looks like a serious intermittent design bug, and the logic under it, examined closely, is correct.

Root Cause

A zero-delay race. In zero-delay mode, all logic settles within the same simulation instant with no time advance, so when a clock edge and the data it captures occur at the same nominal time, the simulator has no timing basis to decide whether the data settled before or after the capture. The outcome therefore depends on evaluation order — an implementation detail that shifts with unrelated edits, file order, or tool version — producing the non-deterministic result. The design is not buggy; the question ('what did this flop capture when its data changed at the clock edge?') is a timing-ordering question, and it was asked in a mode that has no timing to resolve ordering. Confirmation: re-running the same netlist in unit-delay mode gives the data a definite ordering relative to the edge, so the result becomes deterministic and consistent. The 'bug' is an artifact of the mode, not of the logic — the zero-delay medium simply cannot represent the time ordering the question depends on.

Fix

Ask the question in a mode that can resolve ordering: re-run in unit-delay (which gives deterministic sequence) or, if the real margin matters, full-timing with SDF (which shows real clk-to-q and would flag a genuine setup violation if the data really lands inside the window). If the result is stable and correct once ordering exists, the design is fine and the zero-delay non-determinism was a race artifact — do not 'fix' correct logic to chase it. The lesson the failure teaches: choose the GLS timing mode for the question — zero-delay answers function/X/reset (no ordering, no real timing) and can produce order-dependent races on timing-sensitive events; unit-delay adds deterministic ordering; full-timing adds real timing; a non-deterministic result in zero-delay is usually a mode artifact (a race), not a design bug, and the fix is to add ordering (unit-delay) or real timing (full-timing), not to edit correct logic. Matching mode to question is the core GLS skill this chapter builds toward.

7. Common Mistakes

Asking a timing-ordering question in zero-delay. A clock edge and its data in the same instant race; the result is order-dependent (a mode artifact) — use unit-delay or full-timing for ordering/timing questions.
"Fixing" correct logic to chase a zero-delay race. A non-deterministic zero-delay result is usually a race, not a bug — add ordering first, then re-judge.
Running full-timing for a pure function check. You burn days of runtime for a question zero/unit-delay answers in minutes — match the mode to the question.
Treating unit-delay as "real timing." A unit is arbitrary, not a nanosecond — unit-delay gives ordering, not real margins; only full-timing (SDF) models real timing.
Not matching mode to insertion point. Post-synthesis GLS -> zero/unit-delay (function); post-layout GLS -> full-timing (real delays). Running the wrong mode at a point wastes it.

8. Industry Best Practices

Choose the mode for the question. Function/X/reset -> zero/unit-delay; real timing/glitches/margins -> full-timing (SDF).
Prefer unit-delay over zero-delay when ordering matters. It removes zero-delay races cheaply while staying far faster than full-timing.
Reserve full-timing for the post-layout signoff run. It is the slowest mode; run it where real delays are the point (Ch4/Ch8), not for early function checks.
Read a non-deterministic zero-delay result as a race first. Re-run with ordering (unit-delay) before suspecting the design.
Match mode to flow point. Post-synthesis GLS is zero/unit-delay; post-layout GLS is full-timing — the mode and the insertion point go together (0.3).

9. Interview / Review Questions

10. Key Takeaways

GLS runs in three timing modes that trade realism for speed — and choosing the right one for the question is a core GLS skill.
Zero-delay: no delays, all logic in one instant — fastest, great for function + X/reset, but prone to zero-delay races (a clock edge and its data in the same instant → order-dependent result) and blind to real timing.
Unit-delay: one arbitrary unit per gate — adds causal ordering so sequence is deterministic and simple races resolve; cheap, but not real timing (a unit is not a nanosecond).
Full-timing: real SDF delays (Ch4) — reproduces real clk-to-q, glitches, setup/hold as events; slowest, the signoff-quality run.
Match mode to question and to flow point: function/X/reset → zero/unit-delay (post-synthesis GLS); real timing → full-timing (post-layout GLS). A non-deterministic zero-delay result is usually a race (mode artifact) — add ordering or real timing, don't edit correct logic.

Senior Engineer Thinking

Beginner: "This signal is wrong in GLS — it's a bug."
Senior: "First: what mode am I in? A non-deterministic result in zero-delay is usually a race — the medium cannot order two coincident events — not a defect. I'll re-run with ordering (unit-delay) before I touch correct logic."

The senior interprets a signal in the light of the mode and rules out mode artifacts before editing the design — the opposite of chasing the symptom.

Silicon Impact

The mistake cuts both ways. Chase a zero-delay race as a "bug" and you burn days editing correct logic — schedule cost, plus the risk of introducing a real bug. Skip full-timing because a function run looked clean and a real setup/hold interaction reaches silicon as an intermittent, voltage/temperature-sensitive failure — a field return whose margin only shows under real delays. Pick the wrong mode and you either waste effort or let a real timing bug through.

Engineering Checklist

Chose the mode for the question (function/X → zero/unit; real timing → full).
Used unit-delay (not zero-delay) when ordering matters.
Reserved full-timing (SDF) for the post-layout signoff run.
Read a non-deterministic zero-delay result as a race first, not a bug.
Did not "fix" correct logic to chase a mode artifact.

Quick Revision

Match the mode to the question. Zero-delay = content, no time (function / X, race-prone). Unit-delay = order, no real time (deterministic sequence). Full-timing = real time (SDF: margins, glitches, signoff). Next: 0.5 reads these runs as waveforms and logs with one procedure.