Gate Level Simulation: Introduction and Why GLS Is Still Needed

Gate level simulation (GLS) is the simulation of a synthesised or post-layout netlist, built from standard cells and flip-flops, instead of the RTL it came from. Teams still run it, even with mature static timing analysis (STA) and formal equivalence checking (LEC), because GLS catches the things those static tools assume away: reset and boot problems, X behaviour that RTL hides, inserted test logic, wrong timing constraints and real switching activity for power.

This introduction explains what GLS is, why it is still needed, the two main ways it is run, and the problems that make it hard to bring up.

Key takeaways

• GLS simulates the netlist that will actually be built, so it sees what synthesis, scan insertion and clock tree synthesis added.
• It does not replace STA or LEC. It checks the assumptions and constraints those tools depend on.
• Zero-delay GLS is mainly a functional check (reset, boot, X handling, DFT). Timing GLS with back-annotated SDF checks constraints, asynchronous paths and real delays.
• GLS is slow and only as good as its test vectors, so teams run a small, carefully chosen set of tests.
• X behaviour differs: RTL is often optimistic about unknowns, gate level is often pessimistic. Both can mislead.

What gate level simulation is

After synthesis, the design is no longer a set of always blocks and assignments. It is a netlist of library cells such as AND, OR, NAND, multiplexers, flip-flops and latches, each described by a Verilog simulation model from the library vendor. GLS runs the same kind of testbench against this netlist.

The gate level is the lowest level of abstraction normally used for digital logic simulation. Below it sit transistor-level (SPICE) simulation and layout, which are used for cells and analogue blocks rather than whole digital chips.

A GLS can be run on:

• the post-synthesis netlist, with estimated or no delays, or
• the post-layout netlist, after placement, clock tree synthesis and routing, with delays back-annotated from an SDF (Standard Delay Format, IEEE 1497) file produced by the timing tool.

Why we still need GLS

With wide acceptance of STA and formal verification tools by the industry, one question still comes up: why do we need gate level simulation at all? The common reasons quoted by engineers fall into a few groups.

1. Reset, initialisation and boot-up

GLS checks that reset release, the initialisation sequence and boot-up work on the real netlist. Flip-flops without reset, reset synchronisers, power-on sequencing and memory initialisation often behave differently once the RTL shortcuts are gone. Any unintended dependency on initial conditions shows up here as X values that do not clear.

2. Logic added after RTL

Scan chains, test compression, clock gating cells and some power management logic are inserted during or after synthesis. They never appear in RTL simulation, so RTL tests cannot check them. GLS is also required to simulate ATPG patterns and to generate or validate ATE test vectors.

3. Validating timing constraints

Static tools are constraint-based and only as good as the constraints they are given. STA does not analyse asynchronous interfaces, and it trusts every false path and multicycle path it is told about. Timing GLS helps catch:

• unchecked use of wildcards that sets false paths or multicycle paths where they do not belong;
• late design changes that never propagated into the constraints;
• a wrong understanding of the design, or a simple typo, leading to incorrect exceptions;
• use of create_clock where create_generated_clock was needed, which breaks the relationship between clock domains.

4. X behaviour

X values in RTL simulation can be pessimistic or optimistic. An if statement with an unknown condition takes the else branch, which can hide a real problem. A gate netlist is usually more pessimistic, and can produce X where silicon would settle to a known value. GLS shows how unknowns really propagate through the cells that will be built. The example below makes this concrete.

5. Power

GLS gives switching activity (SAIF or VCD/FSDB) on the real netlist, including clock tree and glitch activity. This is used to estimate power and to correlate RTL power estimates with the implemented design.

6. Other uses

• Verifying the integration of digital and analogue netlists.
• Validating a tool flow change, for example when moving from one vendor's sign-off tool to another.
• Checking that RTL simulations were not relying on force statements from the testbench that masked bugs.
• An honest confidence check, a feel-good factor, that the design has been implemented correctly.

Where GLS complements STA and formal

Area	What GLS adds	What it does not replace
Functionality	Simulates the gates and flip-flops that will be built, including inserted logic	LEC, which proves RTL and netlist equivalent for all inputs
Timing	Shows real delays and timing check violations for the vectors run, and exercises asynchronous paths	STA, which covers every path exhaustively; GLS only covers the paths the test happens to activate
Debug	Exposes glitches, races, reset and X problems in the netlist	RTL debug, which is far faster for logic bugs
Power	Realistic switching activity for power analysis	Power sign-off tools, which use that activity as input

A point worth being precise about: GLS does not prove that a design meets timing. It can show a violation on the paths a test exercises, and it can reveal a bad constraint, but sign-off timing comes from STA.

Zero-delay GLS and timing GLS

Some design teams use GLS only in a zero-delay, ideal clock mode, to check that the design comes out of reset cleanly and that the test structures were inserted properly. Other teams run fully back-annotated simulation as a way to check that the static timing constraints were set up correctly.

	Zero-delay (or unit-delay) GLS	Timing GLS with SDF
Netlist	Post-synthesis, often before layout	Post-layout, with clock tree
Delays	None or a nominal unit delay	Cell and wire delays from SDF, per corner
Timing checks	Usually switched off	On ($setup, $hold, $width and similar in the cell models)
Finds	Reset, boot, X, DFT and connectivity problems	Constraint errors, asynchronous path issues, real hold or setup violations on exercised paths
Typical problems	Races between flip-flops when every delay is zero	Slow runs, X from timing checks on synchroniser flops, SDF annotation warnings
Speed	Several times slower than RTL	Much slower again

Speed figures vary widely with design size, simulator and delay mode; treat the relative ordering above as a guide, not a measurement.

Example: RTL optimism and gate-level pessimism

The small example below compares an RTL 2:1 multiplexer with a gate-level version of the same function. The select line is driven to X, as it might be if it came from a flip-flop that was never reset.

`timescale 1ns/1ps
// RTL view of a 2:1 mux
module mux_rtl (input a, b, sel, output reg y);
  always @* begin
    if (sel) y = a;
    else     y = b;
  end
endmodule

// Gate-level view of the same mux, as synthesis might produce it
module mux_gl (input a, b, sel, output y);
  wire sel_n, t0, t1;
  not  #0.05 u0 (sel_n, sel);
  and  #0.08 u1 (t0, a, sel);
  and  #0.08 u2 (t1, b, sel_n);
  or   #0.09 u3 (y, t0, t1);
endmodule

module tb;
  reg a, b, sel;
  wire y_rtl, y_gl;
  mux_rtl r (.a(a), .b(b), .sel(sel), .y(y_rtl));
  mux_gl  g (.a(a), .b(b), .sel(sel), .y(y_gl));
  initial begin
    a = 1'b1; b = 1'b0; sel = 1'bx;  #1;
    $display("a=1 b=0 sel=x : rtl y=%b  gate y=%b", y_rtl, y_gl);
    a = 1'b1; b = 1'b1; sel = 1'bx;  #1;
    $display("a=1 b=1 sel=x : rtl y=%b  gate y=%b", y_rtl, y_gl);
    sel = 1'b1; #1;
    $display("a=1 b=1 sel=1 : rtl y=%b  gate y=%b", y_rtl, y_gl);
    $finish;
  end
endmodule

Output:

a=1 b=0 sel=x : rtl y=0  gate y=x
a=1 b=1 sel=x : rtl y=1  gate y=x
a=1 b=1 sel=1 : rtl y=1  gate y=1

In the first case the RTL quietly takes the else branch and outputs 0. Silicon could output 0 or 1, so the RTL has hidden a real uninitialised-select bug: that is X optimism. In the second case both data inputs are 1, so real hardware would output 1 whatever the select is, but the gate model outputs X: that is X pessimism. Real libraries often model multiplexers with user-defined primitives that handle this case better, but the same effect appears across chains of simple gates. GLS exposes the first kind of problem, and the second kind is one of the reasons GLS is painful to bring up.

Why GLS is hard to bring up

Getting a GLS up and running is usually accompanied by a series of frustrating problems. They come from a few places:

• The library vendor: cell models with incomplete X handling, missing or inconsistent timing checks, specify blocks that do not match the SDF, and differences between simulators.
• The design: flip-flops without reset that start at X and never clear, synchroniser flops that legitimately violate setup and hold and so produce X from timing checks, memories and analogue models that need their own behavioural views.
• Synthesis and implementation: renamed or flattened hierarchy that breaks testbench probes and force paths, constant propagation and register merging that change what the testbench expects, and scan or clock gating logic that needs correct test mode settings.
• Back-annotated SDF: annotation warnings, interconnect delays on the wrong pins, choosing the right corner, and the long run times of full timing simulation.

Later posts in this series look at examples of each of these problems: from the library, from the design, from synthesis, and the extra challenges of gate level simulation with back-annotated SDF.

Common mistakes

• Treating a clean timing GLS as timing sign-off. Only STA covers all paths.
• Running the whole RTL regression at gate level. Pick tests that cover reset, boot, each clock domain crossing, each test mode and the power modes.
• Switching off all timing checks to get rid of X, which also hides real violations. Disable them only on the specific synchroniser cells that are meant to see asynchronous data.
• Initialising every flip-flop to 0 or 1 with a simulator option and then believing the reset check passed. Random initialisation, run with several seeds, is a more honest test.
• Leaving testbench force statements that point at RTL signal names, which silently do nothing once hierarchy has changed.

FAQ

Is gate level simulation still needed if STA and LEC are clean?

Usually yes, but in a reduced form. STA and LEC are exhaustive for what they check, but they trust their constraints and setup. GLS checks reset and boot, inserted test logic, asynchronous paths and the constraints themselves.

What is SDF back-annotation?

The timing tool writes cell and interconnect delays for a chosen corner into an SDF file. The simulator reads it, typically through the $sdf_annotate system task, and replaces the default delays in the cell models with those values.

Why does GLS show X when RTL simulation was clean?

Common causes are flip-flops without reset, gate models that are more pessimistic than RTL, timing check violations on synchroniser flops, and memories or analogue blocks without proper models. Each X needs to be traced to its source rather than masked.

How many tests should run at gate level?

There is no fixed number. Teams typically choose a small set that covers reset and boot, every major mode, each test mode, every clock domain and the power states, plus ATPG pattern simulation.