GLS · Chapter 13 · Simulation Performance & Regression Strategy

Why GLS Is Slow — and What to Do About It

Gate-level simulation typically runs ten to a hundred times slower than RTL, and knowing why is the first step to making it affordable. There are five compounding reasons. The netlist has vastly more events because every cell and net toggles instead of a handful of abstract statements. Timing annotation adds delay scheduling and firing timing checks that inflate the event queue. X-propagation fans out through the logic and multiplies activity. The design is far larger in gate count than in RTL lines. And there are no behavioral shortcuts, so an RTL plus becomes a whole adder of cells. This lesson dissects each cause so you can attack the right one and explains why GLS must be run strategically, by speeding up each run and choosing the right subset, rather than brute-forced.

Foundation11 min readGLSPerformanceSimulation SpeedEventsStrategy

Chapter 13 · Section 13.1 · Simulation Performance & Regression Strategy

Project thread — the mini-SoC's GLS is far more expensive than its RTL regression. This chapter makes it affordable; this lesson explains the cost so 13.2 (speed) and 13.3 (what to run) can address it.

1. Why Should I Learn This?

You can't make GLS affordable without knowing where the time goes.

Five causes: events, timing, X-fanout, design size, no shortcuts.
Each maps to a lever (13.2 speed, 13.3 what-to-run).
Brute force fails; strategy (attack the cause) works.

This frames the whole chapter (13.2 speed, 13.3 selection, 13.4 pipeline, 13.5 automation).

2. Real Silicon Story — the regression that never finished

A team pointed their full RTL functional regression at the gate-level netlist with SDF and hit run. Days later, it had barely progressed — the runs were 10–100× slower and the machine pool couldn't keep up.

The mistake was brute force: running everything at full timing. Understanding why GLS is slow — event explosion, timing scheduling, X-fanout, size — pointed at the fixes: run zero-delay functional GLS for most of it, timed GLS only on a targeted subset (13.3), and speed up each run (13.2). The regression became affordable — the same coverage, a fraction of the cost.

Lesson: GLS is inherently 10–100× slower than RTL. You can't brute-force it — understand why it's slow, then be strategic (speed + selection).

3. Concept — the five causes of GLS slowness

(1) Event explosion. RTL evaluates a few abstract statements per clock; the netlist toggles every cell and net — orders of magnitude more events per cycle.
(2) Timing (SDF). Annotated delays spread events across many distinct times (not all at the edge) and add firing timing checks — a larger, busier event queue.
(3) X-propagation. Xs fan out (Chapter 6), multiplying toggles — unbounded X (uninit/reset gap) makes it worse.
(4) Design size. The gate count (tech-mapped cells, buffers, clock/reset/scan/power cells) dwarfs the RTL line count.
(5) No behavioral shortcuts. RTL +/*/case are single operations; gates are the full cell network — every cell an event.

The takeaway:

GLS is inherently expensive — the causes compound.
The response is strategic: speed up the run (13.2) and run the right subset (13.3), not brute force.
Each cause maps to a lever: events/timing → zero-delay where possible (13.2); X-fanout → proper reset/bound-X (13.2); size/shortcuts → run less, smarter (13.3).

Scope (accuracy):

GLS slowness is inherent to gate-level fidelity — not a bug to 'fix', a cost to manage. GLS stays dynamic (0.3).

Figure 1 — why GLS is 10-100x slower than RTL (representative). Five compounding causes: (1) EVENT EXPLOSION -- every cell/net toggles vs a few abstract RTL statements; (2) TIMING (SDF) -- delay scheduling + firing timing checks inflate the event queue; (3) X-PROPAGATION -- X's fan out, multiplying activity; (4) DESIGN SIZE -- gate count >> RTL lines; (5) NO SHORTCUTS -- an RTL '+' is one op, gates are a whole adder of cells. Each maps to a lever: zero-delay where possible (13.2), bound X (13.2), run the right subset (13.3). GLS is inherently expensive -> be strategic, not brute-force.

4. Mental Model — a satellite photo vs a hand-drawn map

RTL is a hand-drawn map (a few labeled roads); the gate-level netlist is a high-resolution satellite photo (every building, tree, and car).

The satellite photo shows far more detail — and takes far longer to render and search (event explosion, size).
Add time-lapse (real delays, SDF) and you're now rendering every frame at many timestamps (timing scheduling).
If a fog (X) rolls in, it spreads across the whole photo, obscuring more with each frame (X-fanout).
And where the map said "highway" (an RTL +), the photo shows every lane, sign, and vehicle (no shortcuts).

You keep the satellite photo for what it uniquely shows (gate-level truth) — but you don't render the whole planet in time-lapse when a map suffices (strategy: 13.2/13.3).

5. Working Example — where the time goes

A representative simulation profile (tool-neutral):

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# GLS simulation profile — REPRESENTATIVE (tool-neutral) — where the time goes:
#   event scheduling / propagation .... ~55%   (event explosion: every cell/net, cause 1)
#   timing (delay calc + checks) ...... ~25%   (SDF scheduling + $setup/$hold, cause 2)
#   X-handling / propagation .......... ~10%   (X fan-out, cause 3; worse if unbounded)
#   waveform dumping .................. ~7%    (see 13.2 -- reduce dumping)
#   other ............................. ~3%
# vs RTL: RTL evaluates a handful of statements/clock; GLS toggles ~10^5 cells -> 10-100x.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# The five causes -> the levers (tool-neutral):
#   events (1) + timing (2)  -> run ZERO-DELAY where timing isn't needed (13.2); timed on a SUBSET (13.3)
#   X-fanout (3)             -> proper reset / bound X (13.2) -- unbounded X multiplies activity
#   size (4) + shortcuts (5) -> run LESS, smarter -- the RIGHT subset, not everything (13.3)

Practical context (representative, tool-neutral):

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# Diagnose GLS cost before optimizing (tool-neutral):
#   1) PROFILE the run (where does time go? events/timing/X/dumping)
#   2) map the dominant cause to a lever:
#        timing dominates + timing not needed -> zero-delay (13.2)
#        X-handling high -> bound X (reset/init, 13.2)
#        dumping high -> reduce/window the dump (13.2)
#        overall too much -> run the RIGHT subset (13.3)
#   3) GLS is inherently 10-100x RTL -> manage the cost, don't brute-force

RTL event density vs gate-level event density, as a real waveform:

Event density: RTL toggles a few signals per clock; the gate-level netlist toggles many cells/nets

8 cycles

Representative. In RTL, a clock edge evaluates a few abstract signals (rtl_sig). At the gate level, the same operation toggles many cells/nets at (with SDF) many distinct times (gate_a, gate_b, gate_c) — the event explosion that makes GLS 10-100x slower. More events, spread across more times, with X fan-out on top.

6. Debugging Session — a GLS run too slow to finish

A gate-level regression is too slow to finish because it brute-forces the full functional suite at full timing; profiling shows the dominant cost (events/timing/X), and mapping it to the right lever (zero-delay, bound X, run a subset) makes it affordable

GLS IS INHERENTLY SLOW — ATTACK THE CAUSE, DON'T BRUTE-FORCE

Symptom

A gate-level regression is too slow to finish — the full functional suite at full timing overwhelms the machine pool.

Root Cause

Brute force against an inherently expensive run. GLS is 10–100× slower than RTL for five compounding reasons: event explosion (every cell/net toggles, not a few RTL statements); timing (SDF adds delay scheduling and firing checks); X-propagation (Xs fan out, worse if unbounded); design size (gate count ≫ RTL lines); and no behavioral shortcuts (an RTL + is a whole adder of cells). Running the entire functional suite (RTL's job) at full timing multiplies all five costs — it was never going to fit. It's not a broken run; it's the wrong strategy for a run whose cost is inherent. A profile shows where the time goes (usually events + timing dominate), pointing at the fix.

Fix

Profile the run to find the dominant cost, then map it to a lever: if timing dominates and isn't needed for most tests, run zero-delay functional GLS (skip SDF) and do timed GLS only on a targeted subset (13.2/13.3); if X-handling is high, bound X with proper reset/init (13.2 — unbounded X multiplies activity); if dumping is high, window the waveform dump (13.2); and overall, run the right subset — the gate-level-specific checks (X/reset/timing/low-power/DFT), not RTL's full functional coverage (13.3). The lesson: GLS is inherently 10–100× slower than RTL — because of event explosion, timing scheduling, X-fanout, design size, and no behavioral shortcuts — so you manage the cost strategically (profile → zero-delay where possible, bound X, run the right subset), never brute-force the full suite at full timing. (GLS slowness is inherent to gate-level fidelity; it stays dynamic, 0.3.)

7. Common Mistakes

Brute-forcing the full functional suite at full timing. GLS can't afford it (13.3).
Optimizing without profiling. Attack the dominant cause, not a guess.
Running timed (SDF) when zero-delay would do. Timing scheduling is a big cost (13.2).
Leaving X unbounded. X-fanout multiplies activity — reset/init (13.2).
Treating GLS slowness as a bug. It's inherent — manage it.

8. Industry Best Practices

Profile the run to find where the time goes.
Map the dominant cause to a lever (zero-delay, bound X, reduce dumping, run a subset).
Run zero-delay where timing isn't needed; timed on a subset (13.2/13.3).
Bound X with proper reset/init.
Accept GLS slowness as inherent — be strategic, not brute-force.

Senior Engineer Thinking

Beginner: "GLS is slow — let me throw more machines at it."
Senior: "GLS is inherently 10–100× RTL — more machines won't fix the strategy. Where does the time go? If timing dominates and isn't needed, I run zero-delay; I bound X; and I run the right subset, not RTL's whole suite."

The senior profiles, maps cost to a lever, and runs strategically rather than brute-forcing.

Silicon Impact

GLS's cost is real and inherent — 10–100× RTL — so a team that brute-forces it (full suite, full timing) either can't finish (blocking tape-out) or burns a machine pool for coverage that RTL already provides. Understanding the five causes — event explosion, timing scheduling, X-fanout, size, no shortcuts — is what turns GLS from an unaffordable step into a managed one: run zero-delay where timing isn't needed, bound X so it doesn't multiply, and run the gate-level-specific subset (13.3). This matters because GLS is not optional — it catches the X/reset/timing/low-power/DFT bugs nothing else does (Ch0) — so making it affordable is what lets it actually run before every tape-out. The cost is inherent; the strategy is what makes it fit.

Engineering Checklist

Profiled the run (events / timing / X / dumping).
Mapped the dominant cause to a lever (13.2/13.3).
Ran zero-delay where timing isn't needed; timed on a subset.
Bounded X (proper reset/init) to limit fan-out.
Treated GLS slowness as inherent — strategic, not brute-force.

Try Yourself

Run a small design in RTL and in zero-delay GLS, then timed (SDF) GLS — compare wall-clock time.
Observe: GLS is much slower (event explosion), and timed GLS is slower still (timing scheduling).
Change: leave a flop unreset so X fans out, and re-run.
Expect: the run gets slower (X-fanout adds events) — and the profile shows X-handling rising. Bound the X (reset) and watch it recover. Map each cause to its lever.

Any simulator with profiling shows where GLS time goes. No paid tool required for the concept.

Interview Perspective

Weak: "GLS is slow because the netlist is bigger."
Good: "GLS is 10–100× RTL: far more events (every cell/net), timing scheduling and checks, X fan-out, and no behavioral shortcuts."
Senior: "Five compounding causes — event explosion, SDF timing scheduling and firing checks, X-fanout, gate count, and no behavioral shortcuts (an RTL + is a whole adder). It's inherent, so I profile to find the dominant cost and map it to a lever: zero-delay where timing isn't needed, bound X, run the right subset. You manage GLS cost strategically; you don't brute-force it."

9. Interview / Review Questions

10. Key Takeaways

GLS is 10–100× slower than RTL for five compounding reasons: (1) event explosion (every cell/net toggles vs a few RTL statements); (2) timing (SDF delay scheduling + firing timing checks); (3) X-propagation (Xs fan out, Ch6); (4) design size (gate count ≫ RTL lines); (5) no behavioral shortcuts (an RTL + is a whole adder of cells).
The slowness is inherent to gate-level fidelity — not a bug to fix, a cost to manage.
Profile the run to find the dominant cause, then map it to a lever: zero-delay where timing isn't needed (13.2), bound X (13.2), reduce dumping (13.2), run the right subset (13.3).
The response is strategic — speed (13.2) + selection (13.3) — never brute-forcing the full functional suite at full timing.
GLS is not optional (it catches what nothing else does, Ch0), so making it affordable is what lets it run before every tape-out; it stays dynamic (0.3). Next: 13.2 — speeding up gate-level runs.

Quick Revision

GLS is 10-100x slower than RTL — five compounding causes: event explosion (every cell/net), timing (SDF scheduling + checks), X-fanout (Ch6), design size (gates >> RTL lines), no shortcuts (RTL + = a whole adder). Inherent — manage, don't brute-force. Profile → map to a lever: zero-delay where timing not needed (13.2), bound X (13.2), reduce dumping (13.2), run the right subset (13.3). Next: 13.2 — speeding up gate-level runs.