GLS · Chapter 12 · GLS Debug Methodology

A Repeatable GLS Debug Mindset

Gate-level failures look intimidating, whether a wall of unknowns, a mismatch, or a violation, but they have a small, recurring set of causes, which means the winning approach is a repeatable funnel rather than random poking. The first and most important question is always whether the failure is a real bug or a simulation or setup artifact, such as missing timing annotation, a mis-scoped timing check, an expected corruption, a testbench-induced violation, or the wrong corner. After that you reproduce it deterministically, find the first point of divergence, classify the cause against the known categories of unknown source, timing, reset, clock-domain crossing, power, DFT, and testbench, trace it backward to its root cause, and fix it at the source. This lesson lays out that mindset as the frame for the whole debug-methodology chapter.

Foundation11 min readGLSDebugMethodologyTriageRoot-Cause

Chapter 12 · Section 12.1 · GLS Debug Methodology

Project thread — every debug in this book (counter reset 7.5, FSM X 6.6, clock-gate 8.6, scan X 11.5) followed the same funnel. This chapter makes it explicit; 12.2–12.6 detail each step.

1. Why Should I Learn This?

The difference between hours and minutes on a gate-level bug is method, not luck.

Gate-level failures have a small set of causes — a funnel narrows fast.
"Real bug or artifact?" asked first avoids chasing phantoms.
First divergence + classify + trace to source is the same every time.

This frames the whole chapter (12.2 first-divergence, 12.3 waveform, 12.4 force/deposit, 12.5 RTL-vs-GLS, 12.6 catalog).

2. Real Silicon Story — a week lost to random poking

An engineer hit a gate-level X and spent a week poking — trying SDF variants, tweaking the testbench, re-running with different options — without a plan. The bug moved around but never resolved.

A systematic pass took an afternoon: ask real-bug-or-artifact (it was real), reproduce deterministically, find the first divergence (one flop), classify (X-source), trace backward (an unreset flop, Ch7), fix at source (reset). The week of poking had never found the first divergence — it kept chasing downstream symptoms.

Lesson: random poking chases symptoms; a funnel finds the source. Ask real-vs-artifact, reproduce, first-divergence, classify, trace, fix — every time.

3. Concept — the debug funnel

The six steps:

Real bug or artifact? (ask first) — genuine design/logic issue, or a setup/simulation artifact:
- Missing SDF annotation → silent zero-delay (4.3/4.5).
- Mis-scoped timing check (async crossing, reset window) (8.4).
- Expected X — corruption (10.2), notifier (8.5), metastability-risk (9.2).
- Testbench-induced — edge-aligned stimulus/sampling (5.3/5.4).
- Wrong corner (3.4).
Reproduce deterministically (same seed/stimulus/setup).
First divergence (12.2) — the earliest wrong signal/time; later = downstream propagation.
Classify the cause: X-source (Ch6) · timing (Ch8) · reset (Ch7) · CDC (Ch9) · power (Ch10) · DFT (Ch11) · testbench (Ch5).
Trace to root cause — backward through the logic to the source.
Fix at the source (design or setup), re-verify.

Why it works:

Gate-level failures come from a bounded set of causes — the funnel classifies fast.
Starting with real-vs-artifact avoids the most common time-sink (debugging an expected X or a setup issue as a design bug).

Scope (accuracy):

The funnel finds functional/simulation causes; timing signoff is STA, CDC is static CDC/MTBF, coverage is ATPG — GLS debug is dynamic (0.3/9.1/11.1).

Figure 1 — the GLS debug funnel (representative). Step 1 (ask FIRST): real bug or ARTIFACT? (missing SDF 4.3/4.5, mis-scoped check 8.4, expected X 8.5/9.2/10.2, TB-induced 5.3, wrong corner 3.4). Step 2: REPRODUCE deterministically. Step 3: find the FIRST point of divergence (12.2). Step 4: CLASSIFY (X-source Ch6, timing Ch8, reset Ch7, CDC Ch9, power Ch10, DFT Ch11, TB Ch5). Step 5: TRACE to root cause. Step 6: FIX at source, re-verify. A systematic funnel beats random poking.

4. Mental Model — a detective, not a vandal

Debug gate-level failures like a detective, not a vandal with a hammer.

A vandal pokes at everything (random SDF tweaks, TB changes) hoping something moves — and the case never closes.
A detective asks the right first question (was a crime even committed? — real bug or artifact?), secures the scene (reproduce), finds where it started (first divergence), identifies the type (classify), follows the trail back (trace), and arrests the culprit (fix at source).
Most gate-level 'crimes' are one of a handful of known types — the detective recognizes the pattern fast.

Ask the first question, work the funnel — don't smash around hoping.

5. Working Example — the funnel applied

The funnel on a representative X (tool-neutral):

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# GLS debug funnel — REPRESENTATIVE (tool-neutral)
1. real or artifact?  -> is SDF annotated (4.5)? checks scoped (8.4)? expected X (8.5/9.2/10.2)?
                         TB-induced (5.3)? right corner (3.4)?   [rule out artifacts FIRST]
2. reproduce         -> same seed/stimulus/setup -> deterministic failure
3. first divergence  -> earliest wrong signal/time (12.2)  [not the downstream wall of X]
4. classify          -> X-source (Ch6)? timing (Ch8)? reset (Ch7)? CDC (Ch9)? power (Ch10)?
                         DFT (Ch11)? TB (Ch5)?
5. trace             -> backward through the logic to the SOURCE
6. fix at source     -> design or setup; RE-VERIFY (failure clears)

Practical context (representative, tool-neutral):

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

# Apply the funnel to ANY gate-level failure (tool-neutral):
#   ALWAYS step 1 first: real bug or artifact? (don't debug an expected X / setup issue as a bug)
#   then: reproduce -> first divergence (12.2) -> classify -> trace -> fix at source -> re-verify
#   the categories: X-source(6) timing(8) reset(7) CDC(9) power(10) DFT(11) TB(5)
#   remember boundaries: STA=timing signoff, static CDC/MTBF=CDC, ATPG=coverage (not GLS)

Random poking vs the funnel (time to root cause), as a real waveform:

Random poking chases downstream symptoms; the funnel finds the first divergence and the source

8 cycles

Representative. A failure shows a wall of downstream X (sym_a, sym_b) that random poking chases. The funnel instead finds the FIRST divergence (root, the earliest wrong signal) and traces it to source — one fix clears the whole wall. The discipline: rule out artifacts, reproduce, find first divergence, classify, trace, fix.

6. Debugging Session — random poking vs the funnel

A gate-level failure is debugged by random poking (SDF variants, testbench tweaks) chasing downstream symptoms, when a systematic funnel — ask real-vs-artifact, reproduce, find first divergence, classify, trace to source, fix — resolves it directly

FUNNEL BEATS POKING: REAL-OR-ARTIFACT → FIRST DIVERGENCE → SOURCE

Symptom

A gate-level failure (a wall of X, a mismatch) is attacked by random poking — trying SDF variants, tweaking the testbench, changing options — and it never resolves (the symptom moves but doesn't clear).

Root Cause

No method. Random poking chases downstream symptoms (the wall of X) instead of the source, and it skips the crucial first question — real bug or artifact? — so it may even be debugging an expected X (corruption 10.2, notifier 8.5, metastability-risk 9.2) or a setup issue (missing SDF 4.5, mis-scoped check 8.4, wrong corner 3.4) as if it were a design bug. Without reproducing deterministically, results are inconsistent; without first divergence (12.2), the debug fixates on propagation, not cause; without classifying, it can't map to the known categories. Gate-level failures have a bounded set of causes, so the failure isn't hard — the approach is missing.

Fix

Apply the funnel: (1) ask real-vs-artifact (rule out missing SDF, mis-scoped checks, expected X, TB-induced, wrong corner — first); (2) reproduce deterministically; (3) find the first point of divergence (12.2); (4) classify (X-source, timing, reset, CDC, power, DFT, TB); (5) trace to the root cause; (6) fix at the source and re-verify. This turns a wall of X into a single sourced fix. The lesson: gate-level failures have a small, recurring set of causes — debug them with a repeatable funnel (real-vs-artifact → reproduce → first divergence → classify → trace → fix), always asking real-bug-or-artifact first; random poking chases downstream symptoms, the funnel finds the source. (The funnel finds functional/simulation causes; timing signoff is STA, CDC is static CDC/MTBF, coverage is ATPG — GLS debug is dynamic, 0.3/9.1/11.1.)

7. Common Mistakes

Skipping "real bug or artifact?" — debugging an expected X/setup issue as a design bug.
Not reproducing deterministically — inconsistent results, no ground truth.
Chasing downstream symptoms — fix the first divergence, not the wall of X (12.2).
Not classifying — the known categories (X/timing/reset/CDC/power/DFT/TB) map fast.
Random poking — a funnel beats trial-and-error.

8. Industry Best Practices

Ask real-vs-artifact first — rule out setup/expected-X before debugging design.
Reproduce deterministically before investigating.
Find the first divergence and trace to source (12.2).
Classify against the known categories (X/timing/reset/CDC/power/DFT/TB).
Fix at the source and re-verify — not the symptom.

Senior Engineer Thinking

Beginner: "There's X everywhere — let me try a different SDF and tweak the TB."
Senior: "First: is this a real bug or an artifact? Then reproduce, find the first divergence, classify, trace to source. Gate-level failures are a small set of causes — I funnel, I don't poke."

The senior applies the funnel — real-vs-artifact first — instead of random trial-and-error.

Silicon Impact

Debug method is a schedule and quality multiplier. Random poking on gate-level failures burns days or weeks (the opening story), and worse, it can "resolve" the wrong thing — silencing an artifact while a real bug remains, or waiving a real X as an artifact — either of which lets a bug reach silicon (0.3). A repeatable funnel — always starting with real-vs-artifact, then first-divergence, classify, trace, fix — makes gate-level debug fast, consistent, and reviewable, and it keeps the real/artifact distinction (the theme of this whole book) front and center. Because gate-level failures come from a bounded set of causes, the funnel is what turns an intimidating wall of X into a routine, sourced fix — reliably, before tape-out.

Engineering Checklist

Asked real bug or artifact? first (SDF/checks/expected-X/TB/corner).
Reproduced the failure deterministically.
Found the first point of divergence (12.2).
Classified the cause (X/timing/reset/CDC/power/DFT/TB).
Traced to the source and fixed there — then re-verified.

Try Yourself

Take any gate-level failure and resist poking — instead, write down the six funnel steps.
Observe: ask real-vs-artifact — is SDF annotated (4.5)? checks scoped (8.4)? expected X (8.5/9.2/10.2)? TB-induced (5.3)? right corner (3.4)?
Change: find the first divergence (12.2), classify, and trace to source.
Expect: the failure resolves to a single source — far faster than poking. Internalize the funnel as your default.

The funnel is a discipline, not a tool — it applies in any simulator. No paid tool required.

Interview Perspective

Weak: "I try different things until the X goes away."
Good: "I reproduce it, find the first divergence, and trace it to the source."
Senior: "I use a funnel: first ask real-bug-or-artifact (rule out missing SDF, mis-scoped checks, expected X, TB-induced, wrong corner), then reproduce deterministically, find the first point of divergence, classify against the known categories (X/timing/reset/CDC/power/DFT/TB), trace to the root cause, and fix at the source. Gate-level failures are a small set of causes — a funnel beats poking, and it keeps the real-vs-artifact distinction central."

9. Interview / Review Questions

10. Key Takeaways

Gate-level failures look intimidating but have a small, recurring set of causes — debug them with a repeatable funnel, not random poking.
The funnel: (1) real bug or artifact? (ask first) → (2) reproduce deterministically → (3) first point of divergence (12.2) → (4) classify (X-source Ch6, timing Ch8, reset Ch7, CDC Ch9, power Ch10, DFT Ch11, testbench Ch5) → (5) trace to root cause → (6) fix at source and re-verify.
Always ask "real bug or artifact?" first — it avoids debugging an expected X (10.2/8.5/9.2) or a setup issue (missing SDF 4.5, mis-scoped check 8.4, wrong corner 3.4) as a design bug.
Fix the first divergence, not downstream symptoms — one sourced fix clears the wall of X.
The funnel finds functional/simulation causes; STA signs off timing, static CDC/MTBF verify CDC, ATPG measures coverage — GLS debug is dynamic (0.3/9.1/11.1). Next: 12.2 — triaging the first point of divergence.

Quick Revision

GLS debug = a repeatable FUNNEL, not poking. (1) real bug or ARTIFACT? (SDF 4.5, checks 8.4, expected X 8.5/9.2/10.2, TB 5.3, corner 3.4) — ask first. (2) reproduce deterministically. (3) first divergence (12.2). (4) classify (X/timing/reset/CDC/power/DFT/TB). (5) trace to source. (6) fix at source, re-verify. Gate-level failures = a small set of causes. Next: 12.2 — first point of divergence.