Scenario-Based GLS Questions

Chapter 15 · Section 15.2 · Interview & Signoff Review Preparation

Project thread — this applies the whole book's method (Ch12) to interview scenarios. 15.1 was concepts; 15.3 is hands-on drills; 15.4 the signoff checklist.

1. Why Should I Learn This?

Scenario questions test whether you can reason, not recite — and the reasoning is the book's method.

• Walk the method: recognize the class → real-vs-artifact → first divergence → trace → boundary.
• A structured walk beats a guess every time.
• It's the same method you use on the job — scenarios are the job in miniature.

This is the applied half of interview prep (15.1 concepts, 15.3 drills).

2. Real Silicon Story — the whiteboard that revealed the method (or its absence)

Asked "a GLS run is clean but STA fails — why?", one candidate guessed ("maybe the SDF is wrong?") and stalled. Another walked the method: "Clean GLS and failing STA aren't a contradiction — GLS is dynamic (this stimulus, exercised paths), STA is static and exhaustive. STA found a violation on a path the stimulus never exercised — GLS can't catch that. The boundary: STA is the timing signoff; GLS is a dynamic spot-check."

The second answer was structured and boundary-aware — the method, not a guess. It's the same reasoning that, on the job, keeps you from mistaking a clean GLS run for timing closure.

Lesson: scenario answers are method walks. Recognize the class, ask real-vs-artifact, find first divergence, and state the boundary — don't guess.

3. Concept — the scenario walk

The universal scenario approach (apply to any prompt):

1. Recognize the class — which of X-source (Ch6), timing (Ch8), reset (Ch7), CDC (Ch9), power (Ch10), DFT (Ch11), testbench (Ch5)? (the funnel's classify step, 12.1).
2. Real-vs-artifact first — is it an expected X (corruption/notifier/crossing) or a setup issue (missing SDF, wrong corner, edge-aligned stimulus), or a real bug? (8.4/12.6).
3. First divergence + trace — find the earliest wrong signal (12.2), trace to source (12.3).
4. State the boundary — what owns the real answer: STA (timing), static CDC/MTBF (metastability), ATPG (coverage), LEC (equivalence).

Applied to the flagship scenarios:

• "X on a flop after reset" → class: X-source/reset; real-vs-artifact: is it expected or a reset gap? first divergence → trace to an unreset flop (6.6/7.5); boundary: functional/X signoff.
• "Clean GLS but STA fails" → boundary answer: GLS dynamic vs STA static/exhaustive — STA found an unexercised-path violation (0.3). No contradiction.
• "GLS for a low-power SoC" → method: UPF (power intent), power-aware GLS (corruption/isolation/retention/sequencing, Ch10), tiered regression (13.4); boundary: functional power-intent, not power integrity.
• "Every scan pattern mismatches" → class: DFT/X; recognize chain-level X (all patterns) → test-mode reset not applied / X sources unbounded (11.5); boundary: pattern GLS ≠ coverage.
• "RTL passes, GLS shows X" → judge by source — RTL X-optimism can make the GLS X correct (6.4/12.5). Don't assume GLS is wrong.

The trait (accuracy):

• A scenario answer is a structured walk (recognize → method → boundary) — demonstrating reasoning + boundary awareness, not recall. GLS is dynamic (0.3).

4. Mental Model — a pilot running the checklist, not improvising

A scenario is an in-flight problem — and you run the checklist, you don't improvise.

• A panicked pilot guesses ("maybe it's the fuel?") and grabs at controls — a guess answer.
• A trained pilot runs the procedure: identify the problem (recognize the class), rule out the obvious (real-vs-artifact), trace the fault (first divergence), and know which system owns it (the boundary — is this the engine, the avionics, or ATC?).
• The interviewer isn't testing whether you know the answer — they're testing whether you have the procedure.
• The procedure is the same one that flies the plane safely on the job.

Run the checklist (recognize → method → boundary) — calm, structured, boundary-aware.

5. Working Example — flagship scenarios, walked

The scenario walks (tool-neutral):

# SCENARIO WALKS - REPRESENTATIVE (recognize -> method -> boundary):
# 'X on a flop after reset -- debug it':
#   recognize: X-source / reset  ->  real-vs-artifact: expected, or a RESET GAP?
#   first divergence -> trace -> an UNRESET flop (6.6/7.5)  ->  boundary: functional/X signoff
# 'Clean GLS but STA fails -- why?':
#   NO contradiction: GLS=dynamic (this stimulus), STA=static/exhaustive
#   STA found an UNEXERCISED-path violation GLS can't catch  ->  boundary: STA=timing signoff (0.3)
# 'Set up GLS for a low-power SoC':
#   UPF (power intent) -> power-aware GLS (corruption/isolation/retention/sequencing, Ch10) -> tiered (13.4)
#   boundary: FUNCTIONAL power intent, NOT power integrity (10.1)
# 'Every scan pattern mismatches':
#   ALL patterns fail = CHAIN-LEVEL X  ->  test-mode reset not applied / X sources unbounded (11.5)
#   boundary: pattern GLS confirms SIMULATION, not fault COVERAGE (11.1)
# 'RTL passes but GLS shows X -- is GLS wrong?':
#   JUDGE BY SOURCE: RTL X-optimism can make the GLS X CORRECT (6.4/12.5)  ->  not necessarily wrong

Practical context (representative, tool-neutral):

# Turn ANY GLS scenario into a walk (tool-neutral):
#   1) RECOGNIZE the class (X/timing/reset/CDC/power/DFT/TB, 12.1)
#   2) REAL-vs-ARTIFACT first (expected X / setup issue vs real bug, 8.4/12.6)
#   3) FIRST DIVERGENCE -> trace to source (12.2/12.3)
#   4) STATE THE BOUNDARY (STA=timing, static-CDC+MTBF=metastability, ATPG=coverage, LEC=equivalence)
#   -> structured walk = reasoning + boundary awareness (not a guess)

A scenario symptom (clean GLS, failing STA — no contradiction), as a real waveform:

6. Debugging Session — guessing a scenario vs walking the method

7. Common Mistakes

• Guessing a cause instead of walking the method.
• Skipping real-vs-artifact — the funnel's first step (12.1).
• Not finding the first divergence before proposing a fix (12.2).
• Omitting the boundary — what owns the real answer (STA/CDC/ATPG/LEC).
• Assuming a contradiction (clean GLS vs failing STA) that isn't one (0.3).

8. Industry Best Practices

• Walk the method on every scenario (recognize → real-vs-artifact → first divergence → boundary).
• State assumptions and ask clarifying questions (what corner? was SDF verified?).
• Name the boundary — the tool that owns the real answer.
• Recognize expected X vs real bugs (12.6) in the walk.
• Practice the flagship scenarios until the walk is reflexive.

Senior Engineer Thinking

• Beginner: "Clean GLS but STA fails? Maybe the SDF is broken."
• Senior: "No contradiction — GLS is dynamic (this stimulus), STA is static/exhaustive. STA found an unexercised-path violation GLS can't see. Boundary: STA is the timing signoff. Let me walk it: recognize → real-vs-artifact → first divergence → boundary."

The senior walks the method calmly and names the boundary, rather than guessing.

Silicon Impact

Scenario questions matter because they test the exact reasoning the job requires: when a real gate-level failure appears at 2 a.m. before tape-out, the engineer who walks the method (recognize → real-vs-artifact → first divergence → boundary) finds the root cause fast and correctly, while the one who guesses chases symptoms, mis-attributes causes, or — worst — "fixes" the wrong thing (waiving a real X, treating GLS as timing signoff), letting a bug reach silicon (0.3). The scenario walk is the debug methodology (Chapter 12), and boundary awareness (Chapter 15.1) is what keeps the walk honest. Preparing for scenario interviews and preparing to handle real gate-level failures are the same preparation — which is why interviewers use them, and why practicing the walk pays off on the job, not just in the room.

Engineering Checklist

• Walk recognize → real-vs-artifact → first divergence → boundary on any scenario.
• Ask clarifying questions / state assumptions (corner, SDF verified, mode).
• Name the boundary (STA/static-CDC+MTBF/ATPG/LEC).
• Recognize expected X vs real bugs in the walk (12.6).
• Practiced the flagship scenarios until the walk is reflexive.

Try Yourself

1. Take each flagship scenario (X after reset; clean GLS/failing STA; low-power SoC setup; every scan pattern mismatches; RTL-passes/GLS-X) and walk the method out loud.
2. Observe: every walk is the same four steps — recognize → real-vs-artifact → first divergence → boundary.
3. Change: for one you'd have guessed, force yourself to state the boundary (what owns the real answer).
4. Expect: the answer becomes a structured walk — reasoning, not recall. Practice until it's automatic.

Scenario practice is a discipline, tool-independent. No paid tool required.

Interview Perspective

• Weak: "I'd try a few things to see what fixes it."
• Good: "I'd find the first divergence and trace it to the source."
• Senior: "I walk the method on any scenario: recognize the class (X/timing/reset/CDC/power/DFT/TB), ask real-vs-artifact first, find the first divergence and trace to source, and state the boundary — which tool owns the real answer (STA for timing, static CDC/MTBF for metastability, ATPG for coverage). It's a structured walk, not a guess — the same procedure I use on the real chip."

9. Interview / Review Questions

10. Key Takeaways

• Scenario questions test applied reasoning, and the winning approach is to walk the method — not guess.
• The universal scenario walk: (1) recognize the class (X/timing/reset/CDC/power/DFT/TB, 12.1) → (2) ask real-vs-artifact first (expected X / setup issue vs real bug, 8.4/12.6) → (3) find the first divergence and trace to source (12.2/12.3) → (4) state the boundary (STA/static-CDC+MTBF/ATPG/LEC).
• Flagship scenarios all reduce to the walk: X-after-reset (→ reset gap), clean-GLS/failing-STA (→ dynamic vs static, no contradiction), low-power-SoC setup (→ UPF + power-aware + tiered), every-scan-pattern-mismatches (→ chain-level X), RTL-passes/GLS-X (→ judge by source, GLS X can be right).
• A scenario answer is a structured walk demonstrating reasoning + boundary awareness — the same procedure you use to debug the real chip.
• Preparing for scenarios and preparing to handle real gate-level failures are the same preparation; GLS is the dynamic gate-level input (0.3). Next: 15.3 — GLS debug drills.

Quick Revision

Scenario Qs = walk the METHOD, don't guess. (1) Recognize the class (X/timing/reset/CDC/power/DFT/TB, 12.1) → (2) real-vs-artifact FIRST (8.4/12.6) → (3) first divergence + trace (12.2/12.3) → (4) state the BOUNDARY (STA=timing, static-CDC+MTBF=metastability, ATPG=coverage, LEC=equivalence). Flagships: X-after-reset→reset gap; clean-GLS/failing-STA→dynamic-vs-static (no contradiction); RTL-passes/GLS-X→judge by source. Same procedure as the real job. Next: 15.3 — GLS debug drills.