GLS · Chapter 0 · Foundation

What GLS Catches That Nothing Else Does

Gate-level simulation is not just a slower functional sim. It catches a specific set of failures that neither RTL simulation nor static timing analysis can see. Those include unknown values at power-up and reset-coverage bugs, unknowns that RTL simulation optimistically resolves but the faithful gate netlist propagates, real standard-cell timing behaviour like glitches and pulse rejection, mismatches introduced by the synthesis and place-and-route tools themselves, and the true behaviour of asynchronous, clock-domain-crossing, and scan logic under real conditions. The sharpest of these for a beginner is optimism: RTL simulation can quietly hide an unknown by resolving it to a definite branch, while the gate netlist propagates it faithfully, so a design can be green in RTL sim yet light up in gate-level simulation. This lesson catalogs what gate-level simulation uniquely catches, with a simple example of an unknown that RTL hides and gates expose.

Foundation12 min readGLSX-propagationX-optimismFoundationsTool-flow

Chapter 0 · Section 0.2 · GLS Foundations

Project thread — from 0.1's D flip-flop we add a select mux. The unknown 0.1 created (an un-reset flop), here RTL hides and the real gates expose — same X, seen more truthfully.

1. Why Should I Learn This?

"Run GLS" is useless advice unless you know what you are looking for. GLS is slow and produces a mountain of signals, so an engineer who does not know its unique catch list wastes it — treating an X as noise, or trusting a green RTL regression as if GLS could not possibly disagree. Knowing the five categories GLS uniquely catches turns it into a targeted check: you run it expecting X-at-init, X-optimism escapes, tool-flow mismatches, and real-cell timing, and you recognise them when they appear.

Learning the catch list is what makes the rest of the track make sense — every later chapter is a deep dive into one category: X-propagation (Ch6), reset (Ch7), timing violations (Ch8), CDC (Ch9), scan (Ch11). This lesson is the map.

2. Industry Story — the "impossible" X the netlist found

A verification lead is confident: the block has 100% passing RTL regression, thousands of tests, months of work. GLS is run late, almost as a formality — and it immediately fails, with X flooding out of a datapath the RTL tests exercised every day. The lead's first reaction is denial: "the RTL sim is green, this must be a GLS setup problem."

It was not. The datapath had a case statement whose selector could, under a specific corner of the reset sequence, be unknown for a cycle. In RTL simulation, that case on an X quietly took a definite branch (RTL's X-optimism), so the output looked defined and every RTL test passed — the X was invisible. In the gate netlist, the same logic is a real multiplexer with no optimism: an unknown select produces an unknown output, faithfully. GLS did not invent the X — it stopped hiding one that had been there all along, masked by the RTL simulator's optimism. Once traced, it was a genuine bug: that selector should have been defined out of reset, and was not. The post-mortem lesson: a green RTL regression does not mean there are no unknowns — RTL simulation is X-optimistic and hides some X by resolving them to a definite branch, while the gate netlist faithfully propagates them; GLS catches exactly these, so a design can be perfect in RTL sim and light up with X in GLS, and that X is usually a real bug the optimism was masking.

3. Concept — the five things GLS uniquely catches

GLS catches a specific set of failures that fall outside RTL sim (ideal function) and STA (timing, no function):

1. X at power-up and reset coverage. Real flip-flop cells start unknown; a flop reset does not reach keeps its X and poisons downstream logic (0.1, Ch7).
2. X that RTL sim optimistically hides. RTL simulation resolves some unknowns to a definite branch (an if/case on an X takes a path); the gate netlist — real muxes/gates — has no optimism and propagates the X. So green RTL sim ≠ no X (Ch6).
3. Real standard-cell timing behaviour. Glitches, pulse rejection, and setup/hold as dynamic simulated events — behaviour STA (which reports static bounds, not simulated waveforms) never produces (Ch3, Ch8).
4. Tool-flow mismatches. A synthesis or P&R transformation, or a construct that vanished in synthesis (an initial block, a force), changing behaviour — invisible to the pre-synthesis RTL sim by definition (Ch1).
5. Async / CDC / scan behaviour under real conditions. Clock-domain crossings, asynchronous logic, and scan/DFT structures behaving as the real netlist does, not as the idealised RTL implied (Ch9, Ch11).

The way to use this list: when a bug survives RTL sim and STA, ask which category — and expect GLS to be the check that exposes it:

Figure 1 — routing a failure to the check that catches it. If a bug is caught by RTL FUNCTIONAL SIM (a plain logic error on ideal RTL), it is fixed pre-synthesis. If it is a pure timing-margin issue, STA catches it. But a whole class survives BOTH — because it needs the REAL netlist run from a real startup: (1) X at power-up / reset coverage, (2) X that RTL sim OPTIMISTICALLY hid but gates propagate, (3) real-cell timing (glitches/pulse rejection), (4) tool-flow (synthesis/P&R) mismatches, (5) async/CDC/scan behaviour. That class is GLS TERRITORY — the failures only gate-level simulation exposes.

4. Mental Model — the netlist is a faithful (pessimistic) narrator; RTL is a polite one

Mental Model — RTL sim is a polite narrator that smooths over unknowns; the gate netlist is a faithful one that reports them

RTL simulation is a polite narrator: when it hits something it does not fully know, it often smooths it over and tells a clean story (X-optimism resolves an unknown to a definite branch). The gate netlist is a faithful narrator: it reports exactly what it knows and does not know — so unknowns it cannot resolve are told as unknown (X).

When RTL simulation meets an if or case on an unknown selector, it frequently does something helpful but misleading: it picks a branch anyway, so the output looks defined and the test passes. That politeness is X-optimism — the simulator resolving an unknown more favourably than the real hardware would. The gate netlist has no such politeness. It is built from real multiplexers and gates that, given an unknown control, produce an unknown result — faithfully, sometimes pessimistically. So the same design tells two different stories: the polite RTL narrator smooths the unknown away and says 'fine,' while the faithful gate narrator says 'I genuinely do not know this value.' The crucial insight is that the faithful narrator is closer to silicon: the real chip has no politeness either, so an X the gate netlist reports is usually a real indeterminacy the RTL sim was hiding. This reframes what a green RTL regression means: it means the polite narrator found no story-level bugs — not that there are no unknowns. And it reframes an X in GLS: it is usually the faithful narrator surfacing something real, not a simulator defect. (Later you will learn the gate narrator can also be over-pessimistic — Chapter 6 — but the default posture is: trust the faithful narrator, investigate the X.)

Two anchors:

RTL sim smooths unknowns (X-optimism); the gate netlist reports them (faithful/pessimistic). A green RTL regression does not mean no X — it means the polite narrator found no story bug.
An X in GLS is a real indeterminacy until proven otherwise. The faithful narrator is closer to silicon, so investigate the X — do not assume it is a simulation artifact.

5. Working Example — an unknown RTL hides and gates expose

A tiny selector-driven mux. If sel is ever unknown, watch how RTL sim and the gate netlist disagree.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// RTL: a 2-to-1 select. If sel is X, the netlist mux will produce X — but RTL sim may HIDE it.
module sel_mux (input logic sel, input logic a, input logic b, output logic y);
  always_comb begin
    case (sel)                 // an X on sel: RTL sim may take a DEFINITE branch (X-optimism)
      1'b0: y = a;
      1'b1: y = b;
      default: y = 1'bx;       // (even with a default, some coding styles let RTL resolve X quietly)
    endcase
  end
endmodule

The representative gate-level view is a real multiplexer cell — and a real mux with an unknown select produces an unknown output, no optimism:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Representative GATE-LEVEL view (conceptual): a library 2:1 mux. sel=X -> y=X, faithfully.
module sel_mux_netlist (input sel, input a, input b, output y);
  MUX2X1 U0 (.A(a), .B(b), .S(sel), .Y(y));   // S=X propagates to Y=X in the cell model
endmodule

A GLS-adapted testbench idea: deliberately drive sel to X for one cycle (e.g. modelling a reset-corner where it is not yet defined) and compare.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Testbench IDEA (conceptual): make sel unknown for a moment, and observe y in RTL sim vs GLS.
initial begin
  a = 1; b = 0; sel = 1'bx;   // sel UNKNOWN — the interesting case
  #10 sel = 1'b0;             // later it becomes defined
  #10 $finish;
end
initial $monitor("t=%0t sel=%b a=%b b=%b y=%b", $time, sel, a, b, y);

The logs disagree exactly where the X lives:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# RTL SIM (X-OPTIMISTIC): the case on sel=X may resolve to a branch -> y looks DEFINED (bug hidden)
t=0  sel=x a=1 b=0 y=1      <- RTL politely picked a branch; the X vanished
t=10 sel=0 a=1 b=0 y=1
 
# GLS (FAITHFUL): the real mux carries the unknown select through -> y=X (bug EXPOSED)
t=0  sel=x a=1 b=0 y=x      <- the gate mux reports the indeterminacy
t=10 sel=0 a=1 b=0 y=1

Same design, same stimulus: RTL sim shows a clean y=1, GLS shows y=x. GLS did not create the X — it stopped hiding the one that RTL's optimism smoothed away. The real question 'why is sel unknown at t=0?' (a reset/init bug) is one only GLS made you ask.

6. Debugging Session — green RTL regression, X flooding out in GLS

A design with a 100% passing RTL regression floods X in GLS because RTL simulation's X-optimism hid an unknown that the faithful gate netlist propagates

RTL SIM HID THE X; GLS EXPOSED IT

Symptom

The block has a fully green RTL regression — thousands of passing functional tests. The first GLS run immediately shows X propagating out of a datapath those same tests exercise constantly. The instinct is 'the RTL sim passes, so this is a GLS setup problem' — but the GLS environment is correct; the X is coming from the design's own logic, out of a path RTL sim always reported as clean.

Root Cause

RTL simulation is X-optimistic: when a selector (an if/case control) is unknown, RTL sim frequently resolves it to a definite branch, so the output looks defined and every RTL test passes — the X is masked. The gate netlist is built from real multiplexers and gates that have no optimism: an unknown control yields an unknown result, propagated faithfully. So the X was always present in the design (a selector that could be unknown for a cycle — typically because it is not defined coming out of reset), but RTL sim hid it and GLS exposed it. GLS did not introduce the X; it removed the optimism that was concealing it. It is therefore not a GLS setup problem and not a false alarm — it is a real indeterminacy (an initialisation/reset-coverage bug on that selector) that the RTL simulator's politeness had been covering up. The 'impossible' X is the faithful narrator surfacing something the polite one smoothed away.

Fix

Trace the X to its source (the unknown selector) and fix the real bug — usually by ensuring that control is defined out of reset (bring its flop into the reset, or initialise the state it derives from) so it is never unknown when used. Re-run GLS and confirm the datapath resolves. The lesson the failure teaches: a green RTL regression does not prove the absence of unknowns — RTL simulation's X-optimism hides X that the faithful gate netlist propagates, so GLS routinely exposes real indeterminacies (reset/init bugs) that RTL sim masked; treat an X in GLS as a real bug to root-cause, not a simulation artifact to suppress. This is category 2 of what GLS uniquely catches, and it is why 'we passed 100% RTL' is never a reason to skip — or distrust — gate-level simulation.

7. Common Mistakes

Reading a green RTL regression as "no unknowns." RTL sim's X-optimism hides some X — a clean RTL run does not mean the netlist is X-free (Ch6).
Dismissing an X in GLS as a setup/simulation problem. The faithful gate netlist usually surfaces a real indeterminacy (an init/reset bug) — investigate it, do not suppress it.
Suppressing X instead of root-causing it. Forcing the X away hides the real bug that would misbehave in silicon; find its source.
Assuming STA would have caught it. STA checks timing, not values — it never sees an X, a wrong reset, or a tool-flow mismatch.
Not knowing the catch categories. Running GLS without expecting X-init, X-optimism, cell timing, tool-flow, and CDC/scan issues wastes the check — you will not recognise what you find.

8. Industry Best Practices

Run GLS expecting the five catch categories. X-init/reset, X-optimism escapes, cell timing/glitches, tool-flow mismatch, async/CDC/scan — knowing the list makes GLS targeted.
Treat every GLS X as a real bug until proven otherwise. The gate netlist is closer to silicon than the X-optimistic RTL sim.
Root-cause X to its source. Trace an unknown back to the uninitialised state or undefined control that produces it — do not mask it.
Never trust a green RTL regression to imply a clean GLS. They measure different things; a passing RTL suite and an X-free netlist are independent facts.
Map each GLS finding to its category and chapter. X-init -> reset debug, X-optimism -> X-prop, glitches -> timing — the catch list is your triage index.

9. Interview / Review Questions

10. Key Takeaways

GLS catches a specific, nameable set of failures RTL sim and STA both miss — knowing the list makes GLS a targeted check, not a mysterious ritual.
The five categories: (1) X at power-up / reset coverage, (2) X that RTL sim optimistically hides but gates propagate, (3) real-cell timing (glitches, pulse rejection), (4) tool-flow (synthesis/P&R) mismatches, and (5) async / CDC / scan behaviour — each is a later chapter.
The beginner's trap is X-optimism: RTL simulation resolves some unknowns to a definite branch and hides them, while the faithful gate netlist propagates them — so a green RTL regression does not mean the netlist is X-free.
An X in GLS is a real indeterminacy until proven otherwise — the gate netlist is closer to silicon than the X-optimistic RTL sim, so root-cause the X to its source (usually an init/reset bug), do not suppress it.
Use the catch list as a triage index: map each GLS finding to its category and chapter (X-init → reset, X-optimism → X-prop, glitches → timing, mismatch → tool-flow, crossing → CDC/scan).

Senior Engineer Thinking

Beginner: "100% RTL regression passed, so there are no unknowns."
Senior: "RTL simulation is X-optimistic — it resolves some unknowns to a definite branch. A green regression means the polite narrator found no story-level bug, not that the netlist is X-free. Where could a control be undefined for a cycle, and does the real mux carry that X through?"

The senior move is to distrust the optimism, not the design: a passing regression and an X-free netlist are independent facts, so you prove the second separately.

Silicon Impact

If this escapes, the X-optimism was masking a real indeterminacy — a control undefined out of reset. Silicon has no optimism, so that path resolves unpredictably: intermittent, data-pattern-dependent failures that pass every RTL test and slip through production test (which never exercises the exact startup corner). The result is a field escape whose root cause — one undefined selector — is expensive to find after tape-out and cheap to find in GLS.

Engineering Checklist

Did not read a green RTL regression as "no unknowns".
Treated every GLS X as a real indeterminacy first, not a sim artifact.
Traced each X to its source (undefined control / uninitialised state) — did not suppress it.
Confirmed every if / case selector is defined out of reset.
Mapped each X to its catch category and its later chapter.

Quick Revision

RTL smooths unknowns; gates report them. RTL sim is X-optimistic and hides some X; the faithful netlist propagates it. So green RTL regression ≠ X-free netlist, and an X in GLS is a real bug until proven otherwise — root-cause it to its source. Next: 0.3 follows this netlist through the RTL-to-signoff flow.