Scenario-Based DFT Questions

Chapter 15 · Section 15.2 · Interview & Signoff Review Preparation

Project thread — the mini-SoC's real situations (Ch1–14) recast as scenario questions. 15.1 gave the facts; 15.3 drills debug; 15.4 the checklist; 15.5 self-assessment.

1. Why Should I Learn This?

Scenario questions test judgment, not recall — how you scope, prioritize, and decide. An approach pattern turns any open-ended 'what would you do' into a structured, senior answer.

• Scenarios have no single fact answer — they test your reasoning process (scope → prioritize → tradeoff → decide).
• Answer with: clarify → hypothesize → plan (structure-first) → tradeoff → decide — and state assumptions.
• The canonical scenarios resolve with the track's principles — stuck coverage, long test time, at-speed fail, no-DFT block, memory+gated-clocks, intermittent silicon.
• The judgment interviewers want: structure-first, triage real vs false, balance not maximize, know when to stop.

2. Real Silicon Story — the answer that jumped to a solution

In an interview, a candidate got the scenario: 'Your ATPG coverage is stuck at 90% against a 99% target. What do you do?' They immediately answered: 'Add more patterns and re-run ATPG.' The interviewer waited; the candidate had nothing more.

The scenario was designed to test judgment, and 'add more patterns' revealed junior instinct — because if coverage is stuck, more patterns won't move it. A senior answer clarifies first ('What are the undetected faults? Which mode? Is compression on?'), then hypothesizes ('A stall usually means redundant faults — an FSM default/illegal-state branch that can't be sensitized — or X-sources, or unobservable points'), then plans ('I'd analyze the undetected-fault list, classify redundant faults so fault coverage reflects reality, mask X, and add observe/test points only for testable-but-unobservable logic'), states the tradeoff ('test points cost area; I wouldn't add them for redundant faults'), and decides ('report test and fault coverage — the test coverage is likely already near target'). The candidate who jumped to 'add patterns' missed the whole point; the one who clarified and hypothesized showed the reasoning. Lesson: a scenario answer is a thought process — clarify and hypothesize before you recommend. The track's principles (6.x/14.3 here) are the content; the approach pattern is the form.

3. Factory Perspective — scenarios through each lens

• What the interviewer sees: your reasoning process — do you clarify/hypothesize/plan or jump to a solution? do you show senior instincts (structure-first, triage, balance, stop)?
• What a senior DFT engineer sees: the real job — open-ended problems (a stall, a fail, a new block) that need judgment across teams, not a memorized reply.
• What the cross-team partners see (RTL/DV, STA, test): whether you can reason into their domain — a scenario often spans RTL (redundant logic), STA (timing modes), and test (environment).
• What the hiring manager sees: whether you can drive an ambiguous problem to a sound, defensible decision — the essence of a senior DFT role.

4. Concept — the approach pattern and the scenario bank

The approach pattern (any scenario):

1. CLARIFY — ask the scoping questions: which mode? what data? what's the constraint/target? (State assumptions if you can't ask.)
2. HYPOTHESIZE — the likely causes, ranked (most-probable first).
3. PLAN — what you'd check, in order, structure-first (flush/modes before logic).
4. TRADEOFF — what you'd balance (coverage vs test time, compression vs diagnosability, area vs observability).
5. DECISION — what you'd recommend, and why — a defensible call.

• Junior: jumps to step 5 (a solution) with no 1–4. Senior: shows the whole reasoning.

The scenario bank (resolves with track principles):

• 'Coverage stuck at 90%, target 99%?' → analyze the gap (redundant / X / unobservable), classify redundant, add test points, mask X; don't chase blindly (6.x/14.3).
• 'Test time / test data too high?' → compression (decompressor/compactor), balance chains, reduce pattern count; tradeoff vs diagnosability (7.x/14.6).
• 'At-speed fails, stuck-at passes — real or false?' → triage: false path/multicycle/OCC mistiming (false) vs a real transition-delay defect; STA the capture-at-speed mode (12.4/13.3).
• 'New block, no DFT — make it testable.' → scan-ready RTL → insert+stitch → DRC → ATPG → coverage → timing (14.x).
• 'Memory + gated clocks + multiple domains?' → MBIST (collared), test-controlled ICGs, lock-ups across domains, multi-mode timing (14.4/14.5/12.5).
• 'Silicon intermittently fails scan at some sites — defect or environment?' → moves with re-seat/site/rate? → environment; else real (13.5).

The judgment interviewers want (senior instincts, Ch13/14):

• Structure before function — flush/modes before logic.
• Triage real vs false — before scrapping (or shipping).
• Balance, don't maximize — every tradeoff is balanced.
• Know when to stop — redundant faults, un-repairable memory, good-enough coverage.

5. Mental Model — a doctor's differential diagnosis, not a snap prescription

A scenario answer is a doctor's differential diagnosis, not a snap prescription at the door.

• A bad doctor hears one symptom and immediately prescribes ('coverage low? add patterns' = 'headache? take aspirin') — no history, no differential, no idea if it's a tension headache or a tumor.
• A good doctor takes the history (clarify: when? which mode? what else is true?), lists a differential (hypothesize: the ranked possible causes), orders tests in a sensible order (plan: cheap/structural first — flush before logic, rule out the environment before the device), weighs treatment tradeoffs (tradeoff: side effects vs benefit), and then recommends with reasons (decide).
• Crucially, the good doctor knows when to stop treating — a benign finding (a redundant fault) doesn't need surgery (a respin); an un-fixable condition (an un-repairable memory) is managed (scrapped), not chased.
• The interviewer is the medical board watching whether you reason like a clinician — the prescription matters less than the differential that got you there.

Take the history, list the differential, test in order, weigh the treatment, then recommend — and know when to stop treating; the reasoning, not the snap prescription, is what's being graded.

6. Working Example — scenarios answered in the approach shape

Two scenarios worked through the clarify → hypothesize → plan → tradeoff → decide pattern:

# Scenario answers in the CLARIFY -> HYPOTHESIZE -> PLAN -> TRADEOFF -> DECIDE shape - REPRESENTATIVE:
 
SCENARIO A: "ATPG coverage is stuck at 90%, target 99%. What do you do?"
  CLARIFY   : which faults are undetected? which mode? compression on? is the target FAULT or TEST coverage?
  HYPOTHESIZE: (ranked) redundant/AU faults (FSM default/illegal-state) > X-sources (uninit) > unobservable points
  PLAN      : pull the undetected-fault list -> classify redundant -> mask X -> add observe points only for TESTABLE logic
  TRADEOFF  : test points cost area/timing; don't add them for redundant faults; test vs fault coverage
  DECIDE    : classify redundant so FAULT coverage reflects reality; report BOTH; test coverage is likely already ~target
  (principles: 6.x/14.3 - don't chase 100% blindly)
 
SCENARIO B: "At-speed test fails on a die that PASSES stuck-at. Real defect or false?"
  CLARIFY   : which patterns/paths? are they known false/multicycle paths? is the OCC pulse program correct? deterministic?
  HYPOTHESIZE: (ranked) false path/multicycle tested as real > OCC mistiming > a REAL transition-delay defect
  PLAN      : STA the capture-at-speed mode; honor false-path/multicycle exceptions; check the OCC program; re-run
  TRADEOFF  : masking a real defect (escape) vs scrapping on a false fail (yield) - triage carefully
  DECIDE    : if it clusters on false/multicycle paths + wrong OCC -> FALSE (fix setup) ; if it localizes + repeats -> REAL (diagnose)
  (principles: 12.4/13.3 - false at-speed fail vs real transition-delay defect)
 
# THE JUDGMENT: structure-first, triage real-vs-false, balance not maximize, know when to stop (redundant/un-repairable).

Each scenario reduces to a decision tree rooted in the track's principles:

7. Industry Flow — the judgment ladder

Scenario answers climb a judgment ladder: scope the problem, go structure-first, triage, balance tradeoffs, and know when to stop:

8. Debugging Session — the candidate who jumped to 'add more patterns'

9. Common Mistakes

• Jumping to a solution. Clarify and hypothesize first — a scenario is a reasoning process, not a snap answer.
• Answering the reflex. 'Add patterns' / 'scrap it' / 'compress more' — usually the symptom, not the root cause.
• Not going structure-first. Flush/modes before logic; rule out the environment before the device (13.1/13.5).
• Maximizing one axis. Balance tradeoffs — over-compressing kills diagnosability; chasing coverage explodes test time.
• Not knowing when to stop. Redundant faults, un-repairable memory, good-enough coverage — stop, don't chase.

10. Industry Best Practices

• Answer scenarios with clarify → hypothesize → plan → tradeoff → decide — show the reasoning, state assumptions.
• Diagnose the root cause before recommending — don't target the symptom.
• Demonstrate the senior instincts — structure-first, triage real vs false, balance, know when to stop.
• Reason across teams — a scenario spans RTL (redundant logic), STA (timing modes), test (environment).
• Recommend a defensible decision — with the why, not just the what.

11. Senior Engineer Thinking

• Beginner: "Coverage is stuck — add more patterns."
• Senior: "First I clarify: which faults are undetected? which mode? compression on? Then I hypothesize — a stall usually means redundant faults (an FSM default branch), then X, then unobservable points. I plan: analyze the fault list, classify redundant, mask X, add test points only for testable logic. Tradeoff: test points cost area — not for redundant faults. Decide: report test and fault coverage — the test coverage is probably already near target. I don't chase 100% blindly. The reasoning is the answer, not the fix."

The senior answers scenarios as a reasoning process, diagnoses before recommending, and shows the senior instincts (structure-first, triage, balance, stop).

12. Silicon Impact

Scenario questions are where an interview stops testing recall and starts testing the actual job — because real DFT work is open-ended: a coverage stall, an at-speed fail, a new block with no DFT, an intermittent silicon problem. There is no single fact answer; there is only judgment — how you scope, prioritize, weigh tradeoffs, and drive to a decision — and the interviewer is grading your reasoning process, not a memorized reply. The approach pattern externalizes that process: CLARIFY (scope: which mode, what data, what constraint — state assumptions), HYPOTHESIZE (the likely causes, ranked), PLAN (what you'd check, in order, structure-first), TRADEOFF (what you'd balance), DECIDE (a defensible recommendation with the why). The failure mode it prevents is the reflex jump to a solution — 'add more patterns,' 'scrap the die,' 'compress more' — which skips the graded steps and usually targets a symptom rather than the root cause. The canonical scenarios all resolve with the track's principles, so the content is already learned: a stuck coverage number is redundant logic, not missing patterns (6.x/14.3); an at-speed fail on a stuck-at-clean die is often a false path/multicycle/OCC-mistiming, not a defect (12.4/13.3); a new block follows the 14.x flow (scan-ready → insert → DRC → ATPG → coverage → timing); a memory + gated clocks + domains needs MBIST + test-controlled ICGs + lock-ups + multi-mode timing (14.4/14.5/12.5); and intermittent, site-dependent silicon is the environment, not the device (13.5). What the interviewer is really listening for is the senior instinct set from Ch13/14: structure before function (flush/modes before logic), triage real vs false (before scrapping or shipping), balance not maximize (every tradeoff is balanced), and know when to stop (redundant faults, un-repairable memory, good-enough coverage). For the candidate, this lesson is the judgment layer — the form that lets your track knowledge demonstrate how you'd actually work; for the interviewer, it's the most predictive signal of on-the-job performance; and for the team, it mirrors the daily reality of DFT as open-ended, cross-functional problem-solving. It builds on 15.1 (facts) and feeds 15.3 (hands-on debug drills) and 15.4 (the signoff-review checklist, where this judgment is applied for real). The throughline: a scenario answer is a thought process, not a fact — clarify and hypothesize before you recommend, reason structure-first, triage before scrapping, balance not maximize, and know when to stop — and the same knowledge that sounds junior as a reflex becomes senior as a reasoned approach.

13. Engineering Checklist

• Answered scenarios with clarify → hypothesize → plan → tradeoff → decide — reasoning shown, assumptions stated.
• Diagnosed the root cause before recommending — didn't target the symptom or jump to a fix.
• Demonstrated the senior instincts — structure-first, triage real vs false, balance, know when to stop.
• Reasoned across teams — RTL (redundant logic), STA (timing modes), test (environment).
• Made a defensible decision — with the why, not just the what.

14. Try Yourself

1. Answer 'Coverage is stuck at 90%, target 99%' in the clarify → hypothesize → plan → tradeoff → decide shape.
2. Answer 'At-speed fails, stuck-at passes — real or false?' — triage with the capture-at-speed mode (12.4/13.3).
3. Answer 'A new block has no DFT — make it testable' — walk the 14.x flow.
4. Answer 'A block has a memory + gated clocks + multiple domains' — MBIST, test-controlled ICGs, lock-ups, multi-mode timing.
5. Answer 'Silicon intermittently fails scan at some sites' — environment vs defect (does it move? 13.5).

The scenario bank and approach pattern are tool-neutral; the content is the whole track. No paid tool required to prepare.

15. Interview Perspective

• Weak: "For a coverage problem I'd add more patterns."
• Good: "I'd analyze why coverage is stuck before adding patterns — it might be redundant logic."
• Senior: "Scenario questions test judgment, so I answer as a reasoning process: clarify (which faults? which mode? compression on?), hypothesize (a stall usually means redundant faults, then X, then unobservable), plan (analyze the fault list, classify redundant, mask X, add test points only for testable logic), tradeoff (test points cost area — not for redundant faults; test vs fault coverage), and decide (report both; the test coverage is likely already near target — don't chase 100% blindly). Across scenarios I show the senior instincts: structure-first, triage real vs false before scrapping, balance not maximize, and know when to stop — because a scenario is a thought process, not a fact, and jumping to a solution reveals junior instinct."

16. Interview / Review Questions

17. Key Takeaways

• Scenario questions test judgment, not facts — they have no single fact answer; the interviewer grades your reasoning process (scope → prioritize → tradeoff → decide).
• Answer any scenario with: CLARIFY → HYPOTHESIZE (ranked) → PLAN (structure-first) → TRADEOFF → DECIDE — show the reasoning, state assumptions; never jump straight to a solution (the reflex usually targets a symptom).
• The canonical scenarios resolve with the track's principles: stuck coverage → redundant/X/unobservable (classify/mask/test-points, 6.x/14.3); test time → compression (7.x/14.6); at-speed fail → triage false vs real (12.4/13.3); no-DFT block → the 14.x flow; memory+gated-clocks+domains → MBIST/ICG/lock-ups/multi-mode (14.4/14.5/12.5); intermittent silicon → environment vs defect (13.5).
• The judgment interviewers want (senior instincts, Ch13/14): structure before function, triage real vs false before scrapping, balance not maximize, and know when to stop.
• A scenario answer is a thought process, not a fact — clarify and hypothesize before you recommend, and the same knowledge that sounds junior as a reflex becomes senior as a reasoned approach. Next: 15.3 — DFT debug drills.

18. Quick Revision

Scenario-based DFT questions. Open-ended 'what would you do' = tests JUDGMENT, not facts → no single answer; the interviewer grades your REASONING PROCESS. APPROACH: CLARIFY (scope: mode? data? target?) → HYPOTHESIZE (likely causes, ranked) → PLAN (check in order, STRUCTURE-FIRST) → TRADEOFF (what you'd balance) → DECIDE (defensible + why). Never jump to a solution (reflex = targets the symptom). CANONICAL scenarios (track principles): stuck coverage → redundant/X/unobservable → classify/mask/test-points (6.x/14.3) ; test time → compression vs diagnosability (7.x/14.6) ; at-speed fail on stuck-at-clean die → triage false (false-path/multicycle/OCC) vs real transition-delay (12.4/13.3) ; no-DFT block → 14.x flow ; memory+gated-clocks+domains → MBIST/ICG/lock-ups/multi-mode (14.4/14.5/12.5) ; intermittent site-dependent silicon → ENVIRONMENT vs defect (13.5). JUDGMENT interviewers want: structure-first · triage real vs false · balance not maximize · know when to stop. A scenario answer = a THOUGHT PROCESS. Next: 15.3 — DFT debug drills.