GLS · Chapter 0 · Foundation
Where GLS Sits in the RTL-to-Signoff Flow
Gate-level simulation is not a single step. It runs at two distinct points in the RTL-to-signoff flow, and each point does a different job. The first runs after synthesis as a functional check with little or no timing, confirming the netlist behaves like the RTL and is clean of X and reset problems before the expensive place-and-route stage. The second runs after place-and-route with back-annotated SDF delays, confirming the design still works under real cell and interconnect timing. Static timing analysis checks timing statically alongside both, so the two GLS runs are complementary to it, not a replacement. This lesson maps GLS onto the flow, explains what each insertion point uniquely proves, and shows the timing-dependent bug that escapes when a team runs only the cheap post-synthesis one and skips the post-layout run.
Foundation11 min readGLSDesign FlowSignoffSDFPost-Layout
Chapter 0 · Section 0.3 · GLS Foundations
Project thread — the same D flip-flop from 0.1, now walked through synthesis into a netlist and simulated at two points in the flow. The X-thinking from 0.2 belongs to the first (post-synthesis) point.
1. Why Should I Learn This?
"When do we run GLS?" is not a scheduling detail — it changes what you find. Run it only after synthesis and you prove the netlist functions like the RTL but learn nothing about real timing; run it only after layout and you pay a huge simulation cost late and may miss the cheap netlist/reset bugs you could have caught early. Knowing the two insertion points and the distinct job of each is what lets you catch each class of bug at the cheapest stage and avoid the trap of thinking one GLS run covers everything.
Placing GLS in the flow also makes the rest of the track concrete: netlists and X (Chapters 1–2, 6–7) belong to the post-synthesis point; SDF and timing-violation debug (Chapters 3–4, 8) belong to the post-layout point. This lesson is the schedule that organises them.
2. Industry Story — the block that passed post-synth GLS and failed in silicon
A team is under schedule pressure. They run the post-synthesis GLS — functional, zero-delay — and it is clean: the netlist matches the RTL, no X, reset behaves. STA closes cleanly after P&R. To save weeks of slow simulation, they skip the post-layout, full-timing GLS ('STA already checked timing'). The block tapes out. It fails intermittently in silicon on a specific data pattern.
The escaped bug was timing-dependent function: a path where the real interconnect and cell delays (only present after P&R, and only simulated with an SDF-annotated GLS) caused a control signal to arrive a hair late relative to the data it gated, producing a wrong capture on certain patterns. STA did not flag it because it was within the timing margins STA models — a functional interaction of delays, not a raw setup/hold miss, exactly the kind of dynamic behaviour a static analysis does not simulate. The post-synthesis GLS could not have caught it either — it ran with no real delays, so the timing interaction did not exist in that simulation. Only the post-layout, full-timing GLS — the one they skipped — would have shown it, because only it simulates function under real timing. The post-mortem lesson: GLS has two insertion points doing different jobs — post-synthesis (functional, little/no timing: netlist matches RTL, X/reset clean) and post-layout (full-timing with SDF: real-timing behaviour) — and one does not substitute for the other; skipping the post-layout, full-timing GLS because 'STA passed' lets timing-dependent functional bugs escape, because STA checks timing statically and never simulates function under real delays.
3. Concept — two insertion points, two jobs
GLS appears at two boundaries in the flow, each proving something the other cannot:
- RTL → RTL simulation. Fast functional verification of the pre-synthesis design. (Not GLS — the baseline.)
- Synthesis → GLS #1 (post-synthesis, functional). Run with zero- or unit-delay (little/no timing, no SDF). Job: confirm the synthesized netlist behaves like the RTL and is clean of X and reset problems. Cheap, early, before P&R — catches netlist-equivalence and initialisation bugs where they are inexpensive to fix.
- P&R → GLS #2 (post-layout, full-timing). Run with back-annotated SDF (real cell + interconnect delays, Ch4). Job: confirm the design functions correctly under real timing — glitches, pulse rejection, timing-dependent function, and hold behaviour that only appears when delays are real. Expensive, late, closest to silicon.
- STA signoff. Runs alongside GLS #2, checking timing exhaustively and statically across all corners — no functional stimulus. Complementary to full-timing GLS (which is dynamic and function-aware but only exercises the paths the stimulus hits).
- Tape-out. Committed once RTL sim, both GLS points, and STA are all clean.
The two GLS points are not interchangeable: #1 proves function on the netlist (no timing), #2 proves function under real timing. Here is the flow with both:
4. Mental Model — two rehearsals: on the bare stage, then under stage lights
5. Working Example — the same design, two GLS runs, two jobs
Take the D flip-flop from 0.1. The same netlist is simulated twice, and the two runs ask different questions.
// GLS #1 — POST-SYNTHESIS, functional (zero/unit-delay, NO SDF).
// Question: does the netlist FUNCTION like the RTL, and is it X/reset clean?
// Command IDEA (conceptual): compile netlist + cell library, run with no delays.
// simulate dff_netlist.v stdcells.v tb.sv // no SDF -> zero-delay
// Expected: matches the RTL sim's function; reset washes out X. Cheap, run BEFORE P&R.// GLS #2 — POST-LAYOUT, full-timing (back-annotated SDF).
// Question: does it FUNCTION UNDER REAL TIMING (clk-to-q delay, setup/hold as real events)?
// Command IDEA (conceptual): same netlist, now ANNOTATE the post-layout delays.
// simulate dff_netlist.v stdcells.v tb.sv -sdf dff.sdf // SDF -> real timing
// Expected: q now updates a real clk-to-q delay AFTER each edge; timing-dependent
// behaviour (and any real setup/hold interaction) is now visible.The behaviour differs in a way that shows the two jobs:
# GLS #1 (no timing): q changes at the SAME instant as the clock edge — function only.
t=10 (posedge clk) q -> 1 <- zero-delay: captures instantly; proves FUNCTION + no X
# GLS #2 (SDF timing): q changes a real clk-to-q delay AFTER the edge — real timing.
t=10 (posedge clk)
t=10.3 q -> 1 <- real ~0.3 ns clk-to-q; now timing interactions are visibleSame netlist, two questions. GLS #1 (cheap, early) proved the function; GLS #2 (with SDF, late) proved the timing behaviour. Skipping either leaves a class of bug unchecked — the subject of the next section.
6. Debugging Session — only ran post-synth GLS, timing bug escaped
A block passes post-synthesis (functional) GLS and clean STA but fails in silicon, because the post-layout full-timing GLS — the only check that simulates function under real delays — was skipped
TWO GLS POINTS; ONE DOES NOT REPLACE THE OTHERThe post-synthesis GLS is green (netlist functions like the RTL, no X, reset clean). STA closes cleanly after P&R. To save simulation time, the post-layout, full-timing GLS is skipped. The chip tapes out and then fails intermittently in silicon on a specific data pattern — a failure no run in the (truncated) verification flow reproduced.
The escaped bug was timing-dependent function: with the real post-layout cell and interconnect delays, a control/enable signal arrives slightly late relative to the data it gates, so on certain patterns the wrong value is captured. Consider why each run in the flow missed it. The post-synthesis GLS ran with no real delays (zero/unit-delay), so the timing interaction did not exist in that simulation — it proves function on the netlist, not function under timing. STA checked timing statically and exhaustively but simulates no function — the interaction was within the timing bounds STA models (not a raw setup/hold miss but a functional consequence of realistic delays), so STA had nothing to flag. The only check that simulates function under real timing — the post-layout, full-timing GLS with SDF — was skipped. So the bug fell exactly into the job that skipped GLS point owned. It is not a synthesis bug, an X bug, or a raw timing-margin violation; it is a timing-dependent functional bug, and by construction only a dynamic, function-aware, real-timing simulation exposes it — which is precisely GLS #2's purpose.
Run the post-layout, full-timing GLS (SDF back-annotated) on the real workload patterns to reproduce and localise the timing-dependent capture, then fix the underlying path (rebalance the timing, adjust the constraint, or correct the logic so the control is not marginally late) and re-run. The lesson the failure teaches: GLS has two insertion points doing different jobs — post-synthesis (function on the netlist, no timing) and post-layout (function under real timing, with SDF) — and neither substitutes for the other, nor does STA (static timing, no function) substitute for the post-layout GLS; skipping the full-timing GLS because 'STA passed' lets timing-dependent functional bugs escape to silicon. Sign off requires both GLS points and STA — each proves something the others cannot.
7. Common Mistakes
- Treating GLS as a single step. It runs at two points — post-synthesis (functional) and post-layout (full-timing) — with different jobs; running one is not running both.
- Skipping post-layout GLS because "STA passed." STA checks timing statically and simulates no function — it cannot catch timing-dependent functional bugs; only full-timing GLS does.
- Running only post-layout GLS (skipping post-synthesis). You pay the huge cost late and miss the cheap early netlist/X/reset catches — do the cheap functional GLS first.
- Confusing "STA is timing signoff" with "GLS #2 is redundant." STA and full-timing GLS are complementary: static-exhaustive vs dynamic-function-aware.
- Not matching each bug class to its insertion point. X/reset/netlist bugs -> post-synthesis GLS; timing-dependent function -> post-layout GLS. Running the wrong point misses the bug.
8. Industry Best Practices
- Run GLS at both points. Post-synthesis functional GLS (cheap, early, no SDF) and post-layout full-timing GLS (with SDF) — each proves a different thing.
- Catch cheap bugs early. Do the post-synthesis functional GLS before P&R so netlist/X/reset bugs are fixed before the expensive stages.
- Never let STA justify skipping full-timing GLS. STA is static and function-free; full-timing GLS is dynamic and function-aware — sign off on both.
- Back-annotate SDF for the post-layout run. Real cell + interconnect delays are what make GLS #2 able to show timing-dependent behaviour (Ch4).
- Sign off on RTL sim + both GLS points + STA. Each covers a distinct failure class; tape-out requires all of them clean.
9. Interview / Review Questions
10. Key Takeaways
- GLS is not a single step — it runs at two insertion points in the RTL-to-signoff flow, each with a different job, and neither substitutes for the other.
- GLS #1 — post-synthesis, functional (zero/unit-delay, no SDF): proves the netlist functions like the RTL and is X/reset clean. Cheap, early, before P&R — catches netlist-equivalence and initialisation bugs inexpensively.
- GLS #2 — post-layout, full-timing (back-annotated SDF): proves the design functions under real timing — glitches, pulse rejection, timing-dependent behaviour. Expensive, late, closest to silicon.
- STA runs alongside GLS #2, checking timing statically and exhaustively with no functional stimulus — it complements full-timing GLS (static-exhaustive vs dynamic-function-aware) and cannot replace it.
- The classic mistake is skipping post-layout GLS because "STA passed" — that lets timing-dependent functional bugs escape to silicon; sign off requires RTL sim + both GLS points + STA, each covering a distinct failure class.
Senior Engineer Thinking
- Beginner: "STA passed, so we can skip the post-layout GLS."
- Senior: "STA proves timing is legal; it never proves the design still functions under that timing, because it runs no stimulus. Those are two different claims. Which check simulates function under real delays? Only the post-layout GLS I'm about to skip."
The senior separates "timing is legal" (STA) from "function is correct under that timing" (full-timing GLS) — and refuses to let the first stand in for the second.
Silicon Impact
If this escapes, a timing-dependent functional bug — a control arriving marginally late with real delays — captures wrong data on specific patterns. STA saw legal timing; the post-synthesis GLS had no delays; the skipped post-layout GLS was the only check that would have shown it. In silicon it is intermittent and pattern-dependent — the classic "works in the lab, fails on one customer's workload" field return, among the most expensive to reproduce after tape-out.
Engineering Checklist
- Ran the post-synthesis functional GLS (cheap, before P&R) for netlist / X / reset.
- Ran the post-layout full-timing GLS (with SDF) for real-timing behaviour.
- Did not let "STA passed" justify skipping the full-timing GLS.
- Back-annotated SDF for the post-layout run.
- Signed off on RTL sim + both GLS points + STA.
Quick Revision
Two GLS points, two jobs. Post-synthesis = function on the netlist (no timing). Post-layout = function under real timing (SDF). STA runs alongside — static, exhaustive, no function. Neither GLS point, nor STA, substitutes for the others. Next: 0.4 runs this netlist in three timing modes.