What gate-level simulation is, how it differs from RTL simulation, why static analysis tools alone are not sufficient, and where GLS fits in the full chip verification flow.
When an RTL design is synthesised, the synthesis tool translates abstract hardware description language (HDL) code into a structural description made of real library cells — AND gates, OR gates, flip-flops, multiplexers, buffers, and inverters from a standard cell library. The output of synthesis is called a gate-level netlist.
A gate-level netlist is still written in HDL (Verilog or VHDL), but instead of behavioural constructs like always blocks and arithmetic operators, it contains only module instantiations of physical cells and wire connections between their ports. Every cell in the netlist corresponds to a real transistor-level implementation in the target process technology.
After synthesis, the netlist goes through placement and routing (P&R), during which cells are physically placed on a floor plan and interconnect wires are routed between them. The routed netlist includes parasitic interconnect delays — the actual propagation time for signals to travel along the metal wires connecting cells.
The four design abstraction levels. GLS operates on the gate netlist — the same structural description of cells and wires that will eventually become physical silicon. Simulating this netlist, especially with real delay information back-annotated from P&R, gives the closest software prediction of how the chip will actually behave.
RTL simulation and gate-level simulation serve different purposes in the verification flow. Understanding the distinction is essential for knowing when each is needed:
| Aspect | RTL Simulation | Gate-Level Simulation |
|---|---|---|
| What is simulated | Behavioural HDL description — always blocks, arithmetic, assignments |
Structural netlist — actual library cell instances and wire connections |
| Timing information | None (zero-delay) or simple unit delays | Real cell delays from characterisation + wire delays from parasitic extraction |
| What it verifies | Functional correctness of the design intent | That synthesis preserved the intent AND that real timing does not break it |
| Speed | Fast — abstract model, no timing overhead | Slower — detailed cell models, timing check evaluation per transition |
| When it runs | Throughout RTL development — CI/CD regression, block-level, SoC integration | After synthesis and/or after P&R — when a netlist exists |
| X-state handling | X represents unknown — may be optimistic (collapses X) or pessimistic | X propagation follows actual gate behaviour — more realistic |
| Scan chains | Not present — DFT logic is inserted after synthesis | Scan chains present — DFT logic can be verified in context |
A common misconception is that passing RTL simulation is sufficient for signoff. It is not. RTL simulation proves the specification is correct. GLS proves that the implementation matches the specification and that the implementation is physically realisable at the target frequency.
Before examining why GLS is needed, it is important to understand the three main tools used to verify a synthesised design and what each can and cannot check:
The three post-synthesis verification methods have overlapping but distinct coverage. STA exhaustively analyses all timing paths without vectors. EC formally proves logical equivalence between RTL and netlist. GLS dynamically simulates the netlist under stimulus vectors — the only method that can verify asynchronous interfaces, reset sequences, scan chains, and X-state propagation in a system context.
| Tool | Method | Catches | Cannot catch |
|---|---|---|---|
| Static Timing Analysis | Graph traversal of all timing paths — no simulation vectors required | Setup and hold violations on all synchronous paths, clock skew, recovery/removal | Asynchronous CDC paths, false path misannotation, glitches on control signals, functional bugs introduced by synthesis |
| Equivalence Checking | Formal Boolean comparison of RTL and netlist functionality | Any logic transformation during synthesis that changed combinational function | Timing violations, initialisation sequences, scan-chain operation, power-domain behaviour, dynamic X propagation |
| Gate-Level Simulation | Dynamic simulation of the actual netlist under test vectors | All of the above gaps — asynchronous interfaces, reset, DFT, glitches, X behaviour, functional bugs in dynamic context | Paths not exercised by testbench vectors (coverage-limited); exhaustive timing without structural analysis |
Static Timing Analysis is highly effective at its intended task — checking that all synchronous paths meet setup and hold constraints. However, it has structural limitations that leave real categories of bugs unchecked:
STA operates on the assumption that all data transfers are synchronised to known clocks. When data crosses between two clock domains without a synchroniser, or when an asynchronous input (from an external pin or legacy IP) enters the design, STA has no framework to analyse it. The STA tool simply cannot see these paths because they are not constrained in the timing constraint file. GLS, operating under real-stimulus vectors, will exercise these crossings and reveal metastability windows and functional failures that STA would never report.
STA relies on timing exceptions annotated by engineers — false paths (paths that are declared to never carry timing-critical data) and multi-cycle paths (paths allowed more than one clock period). If a false-path annotation is incorrect, STA silently ignores a genuinely critical path. GLS with real stimulus exercises those paths and can catch setup violations even on false-path-excluded routes.
STA analyses the steady-state timing of a design. It has no concept of “what happens when reset is asserted and deasserted in a specific order.” The power-up sequence — which blocks come out of reset first, in what order, and whether any flip-flop captures an invalid value during the transition — is inherently dynamic. Only simulation can exercise this.
A glitch is a brief spurious pulse at the output of a combinational logic tree — caused by different propagation delays through different paths to the same gate. If a glitch occurs on the clock enable or asynchronous reset of a flip-flop, it can cause an unintended state change. STA characterises paths but does not simulate waveform events in the time domain. GLS with delay annotation can expose these glitches because the simulator propagates individual signal transitions with their actual delay values.
The following are the primary verification tasks that require gate-level simulation — tasks that cannot be reliably completed with RTL simulation, STA, or equivalence checking alone:
Nine verification tasks that mandate gate-level simulation. Blue cards identify STA gaps — tasks STA structurally cannot perform. Orange cards are combined STA and EC gaps. Green cards identify RTL simulation gaps — scenarios where scan logic or post-CTS structure must be present. Purple and red cards are power and final signoff requirements unique to the gate-level context.
Modern SoCs contain multiple power domains — regions of the chip that can be independently powered up, powered down, or operated at different voltages. At power-up, each domain must come out of isolation in the correct sequence; isolation cells must be active before power is applied; retention flip-flops must restore state in the correct order. None of this sequencing is present in RTL (which typically models a single always-on domain). Only GLS on the post-synthesis netlist — where power-management cells are physically instantiated — can verify this behaviour.
GLS is not a one-time event. It is a loop that repeats as the netlist and timing data are refined through the backend physical implementation process:
The GLS signoff loop. The backend team delivers a netlist and SDF timing file. The verification team runs the GLS regression. On failure, the team categorises each failure: testbench issues (the testbench accessed RTL hierarchy that no longer exists post-synthesis) are fixed by the verification team; genuine timing failures are escalated to the backend team who deliver a new netlist and SDF after fixing the physical implementation. The loop repeats until GLS passes cleanly.
| Failure category | Root cause | Fixed by |
|---|---|---|
| Testbench hierarchy error | Testbench references a hierarchical path that existed in RTL but was flattened during synthesis | Verification team — update testbench to use post-synthesis net names |
| Annotation warning | SDF path does not match a path in the netlist — delay not applied | Verification + backend team — investigate SDF/library mismatch |
| Genuine timing violation | A real setup or hold violation at the specified operating conditions | Backend team — fix placement, routing, or timing constraints |
| Functional failure | Synthesis introduced a logical difference (rare — EC should catch this first) | RTL + synthesis team — investigate synthesis constraints |
GLS does not replace RTL simulation — it complements it. The two operate at different times in the project schedule and cover different failure modes. A mature verification plan uses both, with well-defined handoff criteria between them:
| Phase | Simulation type | Netlist available? | Goal |
|---|---|---|---|
| RTL development | RTL simulation | No — RTL only | Verify functional intent. Build testbench. Achieve coverage targets. |
| Post-synthesis | Zero-delay GLS | Yes — synthesis netlist, no routing | Verify synthesis did not break functionality. Check reset/init. Verify scan chains. |
| Post-P&R (pre-signoff) | SDF GLS (typ/slow) | Yes — routed netlist + SDF | Verify timing with real delays. Check glitches. Verify clock tree. Final frequency check. |
| Signoff | SDF GLS (worst case) | Yes — final netlist + worst-case SDF | Final pass at slow/fast process-voltage-temperature corners. GLS signoff. |
In modern SoC projects, GLS is one of the last verification activities to complete before tape-out — but it is also one of the most schedule-critical. Every GLS failure that turns out to be a genuine timing violation requires a backend fix (ECO — Engineering Change Order), a new P&R run, a new SDF extraction, and another full GLS run. At advanced process nodes (7nm, 5nm, 3nm) a single ECO-to-rerun cycle can take days. Verification teams therefore invest heavily in zero-delay GLS as early as possible (immediately after first synthesis) to catch testbench issues, scan chain bugs, and reset sequence problems before the SDF-annotated runs begin. This is the shift-left principle applied to GLS: the earlier a failure is caught, the cheaper it is to fix.
In RTL simulation, the simulator applies its own rules for how X (unknown) propagates through logical operations. A common RTL behaviour is X-optimism: if (signal == 1'b1) evaluates false when signal is X, potentially collapsing X earlier than a real gate would. In gate-level simulation, each cell model propagates X according to its truth table — for example, an AND gate with one input tied to 0 produces 0 regardless of the other input being X, exactly as the silicon would. This means gate-level X propagation can expose uninitialised flip-flop states or asynchronous reset corner cases that RTL simulation masked. The difference between RTL-X and gate-X behaviour is one of the most common sources of RTL-GLS mismatches in practice.
STA gives high confidence that timing is met across all paths. Equivalence checking gives high confidence that the netlist is logically equivalent to the RTL. But neither tool runs a single instruction through the design, exercises the interrupt controller, checks that the AXI bus responds correctly, or verifies that the chip boots. GLS does. The final SDF-annotated GLS run — using worst-case timing at the slow process corner, lowest supply voltage, and highest temperature — is the closest engineering approximation of silicon behaviour that can be performed before a chip is manufactured. It is the final gate the design must pass before tape-out is authorised. Understanding why it exists and what it uniquely covers is the foundation of everything else in this series.