Diagnosis & Failure Localisation

Chapter 13 · Section 13.4 · DFT Debug Methodology

Project thread — the mini-SoC's real defect localized: cone-intersection to a ranked candidate, a diagnostic mode to beat compression, PFA to confirm, and volume diagnosis for yield.

1. Why Should I Learn This?

Diagnosis turns a confirmed defect into a place to look — a ranked candidate list precise enough to point PFA and, in volume, to drive yield learning.

• An inverse problem: from failing patterns/cells back to the likely fault site by intersecting back-cones (consistent with passing cells).
• Output: a ranked candidate list, a suspected fault type (stuck-at/bridge/open/transition), an xy/layer hint — diagnosis localizes, PFA proves.
• Resolution ~ observability: many observers → tight; compression hides the failing cell → looser → use a diagnostic mode (7.x tradeoff).
• Volume diagnosis → a Pareto of sites → systematic vs random → yield engineering.

2. Real Silicon Story — the diagnosis compression blurred

A part had a confirmed real defect (it survived the 13.3 triage), but diagnosis returned a loose candidate list — dozens of suspects spread across the die. PFA can't be pointed at dozens of sites; deprocessing is slow and destructive. The debug stalled.

The cause was compression. The design used an on-chip compactor (7.x): many scan cells fed a compactor that produced a compressed signature, so the datalog recorded which signature bit miscompared, not which exact cell — hiding the observability diagnosis needs to intersect cones tightly. The fix was a DIAGNOSTIC mode: re-run the failing patterns with the compactor bypassed (a high-resolution / bypass mode) so each individual cell's pass/fail was visible again. With full observability restored, diagnosis intersected the failing cones to a few candidates, and PFA confirmed a bridge at the top suspect. Lesson: diagnosis resolution depends on observability, and compression trades diagnosability for test cost (7.x) — when diagnosis is loose, un-compact with a diagnostic mode. And remember the boundary: diagnosis localized the bridge to a candidate; PFA proved it — the two are different jobs.

3. Factory Perspective — diagnosis through each lens

• What the test/DFT engineer sees: the diagnosis run — feed failing patterns/cells in, get a ranked candidate list + fault type; switch to a diagnostic mode if compression blurs it.
• What the failure-analysis engineer sees: the candidate + xy/layer hint as a PFA target — where to deprocess/image to confirm the physical defect.
• What the yield/process engineer sees: the volume Pareto — is the same site failing across many dies (systematic → process/design) or scattered (random)?
• What management cares about: that diagnosis shortens PFA (cost/time) and drives yield learning — turning test failures into process improvements, not just scrapped dies.

4. Concept — the inverse problem, cones, resolution, volume

What diagnosis is:

• An inverse problem: given failing patterns + their failing cells (datalog) + the netlist + the ATPG fault model, compute the fault candidates (nets/pins) that best explain the observed failures.
• Direction: from observed failures → back to the likely fault site.

How it works — cone intersection:

• Each failing compare cell has a logic cone feeding it; the defect must lie in the intersection of the cones of the failing cells.
• It must be consistent with the passing cells — a candidate that would make a passing cell fail is rejected.
• More failing patterns that observe a site → a tighter candidate set.

Output:

• A ranked candidate list (top suspects + confidence), a suspected fault type (stuck-at / bridge / open / transition), often a physical (x,y) / layer hint.
• Boundary: diagnosis localizes; it does not prove. PFA (deprocess/image) confirms the physical defect.

Resolution ~ observability:

• Many patterns/cells observe the site → tight (few candidates). Poor observability → loose (many candidates).
• Compression (7.x) reduces resolution — the compactor hides which exact cell failed → may need a DIAGNOSTIC (bypass / hi-res) mode to un-compact. A real coverage-vs-diagnosability tradeoff.

Fault-model match & signature:

• Chain diagnosis (13.2) for chain defects; logic (scan) diagnosis for logic defects.
• The failure signature (which patterns fail, stuck-at vs transition, systematic vs random) suggests the defect class (bridge / open / stuck).

Volume diagnosis → yield learning:

• Aggregate diagnosis across many failing dies → a Pareto of failing sites/layers.
• Systematic (same site, many dies) = a design/process marginality (fix the mechanism); random = particle defects. This is how DFT drives yield learning.

Tool boundary (garbage in, garbage out):

• Diagnosis gives candidates + confidence, not certainty; PFA confirms.
• A wrong fault model or unmasked X degrades diagnosis → clean the pattern debug (13.3) first.

5. Mental Model — triangulating a signal from multiple towers

Diagnosis is like triangulating a hidden transmitter from multiple receiving towers — the more towers that hear it, the tighter you pin its location.

• Each failing cell is a tower that heard the signal (the defect's effect); its cone is the direction it heard from. The transmitter (the defect) must be where the directions cross — the intersection of the failing cones.
• The towers that didn't hear it (the passing cells) are just as useful: they rule out whole regions (if the defect were there, they'd have heard it) — so they constrain the fix.
• More towers hearing it → a tighter fix (fewer candidates). Few towers (poor observability) → a fuzzy fix (many candidates). If a relay tower (a compactor) merges several towers' reports into one summary, you lose bearing — so you switch to direct reception (a diagnostic/bypass mode) to get each tower's report individually.
• Triangulation gives you a likely spot (candidates + confidence) — but you still send a crew to dig (PFA) to prove the transmitter is there. And if every failing chip triangulates to the same spot, that's not bad luck — it's a broken tower on the network (a systematic process/design issue) to fix at the source (volume diagnosis → yield).

Triangulate the defect from the towers that heard it (failing cells' cones), ruled in by crossings and out by the silent towers (passing cells) — more towers = tighter; a relay (compactor) blurs bearing; a crew (PFA) proves it; same-spot-everywhere = a systematic fix.

6. Working Example — from failing datalog to a ranked candidate

Trace a diagnosis from failing cells to a candidate for PFA:

# Diagnosis (logic/scan) - REPRESENTATIVE, tool-neutral:
  INPUT : failing patterns + failing cells (datalog, from a CLEAN pattern debug 13.3) + netlist + fault model
  STEP 1 - CONE INTERSECTION:
     failing cell A <- cone {n1,n2,n5,n8}
     failing cell B <- cone {n5,n8,n9}
     intersection (explains BOTH fails) = {n5, n8}
  STEP 2 - CONSISTENCY WITH PASSES:
     passing cell C <- cone {n8, n12}  ; if the defect were on n8, C would ALSO fail -> C PASSED -> REJECT n8
     -> surviving candidate = {n5}
  STEP 3 - RANK + FAULT TYPE:
     candidate n5, confidence high ; signature (fails only transition patterns, not stuck-at) -> suspect a slow/OPEN or bridge
     physical hint: n5 at (x,y), metal-2
  OUTPUT: ranked candidate list [n5 (0.9), ...], fault type = transition/open, xy/layer for PFA
  --- RESOLUTION caveat ---
     if COMPRESSION (7.x) is on, the datalog shows a compacted SIGNATURE bit, not cells A/B/C individually
     -> LOOSE candidate list -> re-run failing patterns in a DIAGNOSTIC (bypass/hi-res) mode -> restore observability -> tighten
  --- BOUNDARY ---   diagnosis LOCALIZES (n5, candidate) ; PFA (deprocess/image at x,y) PROVES the physical defect
  --- VOLUME ---     aggregate n5-type hits across many dies -> if SYSTEMATIC (same site) -> design/process fix (yield), not just this die

Resolution is a ladder set by observability — compression lowers a rung, a diagnostic mode restores it:

6b. From a Failing Pattern to a Candidate Cell — the Arithmetic

Section 6 shows the tool's reasoning. This section shows the part you do by hand before the tool runs, and the part you must be able to check afterwards. It is a short chain, and every link in it can be got wrong in a way that sends you to the other end of the die.

The chain

failing pattern        the ATE says pattern 18432 failed
   |
failing cycle          which tester cycle inside that pattern miscompared
   |
failing output/chain   which scan-out pin -- therefore which chain
   |
unload position        the Nth bit shifted out of that chain
   |
candidate scan cell    unload position -> cell index (arithmetic below)
   |
capture cone           the logic that fed that cell's D input
   |
candidate nets/gates   intersected across all failing cells
   |
ranked candidates      scored by how well each explains fails AND passes
   |
physical correlation   (x,y) and layer -> PFA

The step people get wrong is the fourth, and getting it wrong is not a small error — it puts the candidate at the opposite end of the chain.

The direction convention, stated

A scan chain is an ordered shift register. This curriculum numbers cells 1..N from the scan-in end, so cell 1 is adjacent to scan-in and cell N is adjacent to scan-out — the same convention used in Scan Chain Failure Debug, where a chain break is localized as k = N + 1 − C.

During unload the cell nearest the scan-out pin emerges first. So for an unload position p, counted 1-based with p = 1 as the first bit out:

   cell_index = N + 1 - p          (cells numbered 1..N from SCAN-IN)
 
   sanity check both ends:
     p = 1  ->  cell N      the cell closest to scan-out, first bit out    OK
     p = N  ->  cell 1      the cell closest to scan-in,  last bit out     OK

State the convention before you use it, every time, because it is not universal. Some tools number from the scan-out end, and some report the unload position 0-based. Both flip or shift the answer. The check that costs nothing: substitute p = 1 and p = N into whatever formula you are using and confirm the two extremes land on the two ends of the chain. If they do not, the formula is wrong, and it is better to find that out in ten seconds than after a deprocessing run.

The worked case

# Failure observation - what the tester reported. Nothing here is inferred.
  Pattern            : 18432          (transition-delay pattern set)
  Failing cycle      : 3,417
  Failing output     : SO[7]  -> chain 7
  Chain 7 length     : 412 cells
  Unload position    : 137            (1-based, first bit out = 1)
  Expected / observed: 1 / 0          single-bit miscompare
  Other chains       : all pass on this pattern
  Other patterns     : 3 of 2,048 fail; all fail on chain 7
 
# Localization - arithmetic, still not a hypothesis.
  cell_index = N + 1 - p = 412 + 1 - 137 = 276
 
  Chain 7, cell 276.  Map through the scan-stitching report to the instance
  name and the capture cone feeding its D input:
 
  cell 276  ->  u_core/u_alu/rslt_reg[13]
  capture cone (fan-in of rslt_reg[13].D):
      u_alu/add_stage2/sum[13]
      u_alu/add_stage2/carry[12]
      u_alu/rslt_mux/sel_q
      ... 41 nets, 28 gates total
 
# Cross-pattern intersection - now the candidate set narrows.
  4 failing patterns, all observing chain 7:
     pattern 18432 -> cell 276  -> cone A  (41 nets)
     pattern 18719 -> cell 276  -> cone A
     pattern 19004 -> cell 281  -> cone B  (37 nets)
     pattern 20117 -> cell 276  -> cone A
  intersection(A,B) = 9 nets
 
  passing-pattern constraint: 6 of those 9 nets are observed by cells that
  PASSED on other patterns -> a defect there would have failed those too
  -> REJECT 6 -> 3 surviving candidates.
 
# Ranked candidates - the diagnosis HYPOTHESIS begins here.
  1. u_alu/add_stage2/carry[12]   score 0.87   transition/slow-to-rise
  2. u_alu/add_stage2/sum[13]     score 0.61   transition
  3. u_alu/rslt_mux/sel_q         score 0.22   stuck-at-0
  fault-type evidence: fails ONLY transition patterns, passes all stuck-at
                       -> a timing-dependent defect (resistive open / bridge),
                          not a hard stuck-at
  physical: candidate 1 at (2431.5, 1180.2) um, metal-3 -> PFA target

Observation is not hypothesis

Draw a hard line through the middle of that listing, and keep drawing it in every diagnosis review you attend.

Everything above the ranked list is observation: the tester measured it, or it follows from the measurement by arithmetic you can check. Pattern 18432 failed. The miscompare was at unload position 137 on chain 7. Cell index 276 follows from the chain length and the stated convention. These are facts, and if one is wrong it is because a convention was misread, not because a model was wrong.

Everything from the ranked list down is hypothesis. carry[12] at score 0.87 is the tool's statement that a defect there explains the observed fails and passes better than the alternatives given its fault model. It is not a measurement. It is conditional on the netlist matching the silicon, on the fault model covering the actual defect mechanism, and on the datalog being clean. A resistive open behaves like nothing in a stuck-at model, and a diagnosis run against the wrong model will still return a confident-looking ranked list — confidence scores are relative to the candidates considered, not to the truth.

The practical discipline: report observations and hypotheses in separate sentences. "Chain 7, cell 276, transition patterns only" is something you can defend. "The defect is on carry[12]" is something PFA either confirms or refutes, and it is a considerable difference when someone is about to spend a week deprocessing a die.

Diagnosis summary - die 07, wafer 12
  Failing patterns          : 1,904 of 2,048   (93%)
  Failing chains            : 6 of 12
  Candidate sites returned  : 40
  Top score                 : 0.11
  Score spread              : 0.11 ... 0.04   (essentially flat)
  Candidates within one hierarchy block : 3 of 40

STEP 1 - FLUSH TEST.  Shift a known pattern in and straight out, no capture.
         This exercises ONLY the shift path: cells, stitching, scan-enable,
         shift clock. Nothing about the logic is involved.
           chains 1,2,3,4,5,9,10,11,12 : flush PASS
           chains 6,7,8               : flush FAIL, and the failing bit
                                        position MOVES between runs
         -> the shift infrastructure is broken. STOP. Do not run diagnosis.
 
         A moving failure position is itself diagnostic: a stuck chain gives
         a fixed position, a marginal timing or mode-control problem gives a
         position that wanders.
 
STEP 2 - CHAIN DIAGNOSIS on the failing chains only.
         Localize a break with k = N + 1 - C  (see /dft/scan-chain-failure-debug).
         Here the position did not repeat -> not a hard break -> look at what
         the failing chains SHARE rather than at any one chain.
           chains 6,7,8 share scan_en buffer u_se_buf_3 and its region
         -> shared control, not per-chain structure.
 
STEP 3 - CLASSIFY shift vs capture.
         Re-run at half shift frequency: all chains flush PASS.
         -> timing-dependent shift-path failure, confirmed.
         -> the earlier capture data was never valid.
 
STEP 4 - ONLY NOW, with flush clean at the reduced rate, re-run the logic
         patterns and diagnose. Result on this die: 2 candidates, top score
         0.79, both in one block. PFA confirmed a resistive via on the
         scan-enable buffer output.

7. Industry Flow — diagnose, confirm, and (in volume) learn

Diagnosis localizes to candidates, PFA confirms, and volume diagnosis turns failures into yield learning:

8. Debugging Session — a real defect that diagnosed loose

9. Common Mistakes

• Diagnosing on a dirty datalog. Unmasked X / bad models (13.3) → garbage-in, garbage-out — clean the pattern debug first.
• Expecting tight resolution under compression. The compactor hides the failing cell (7.x) → use a diagnostic/bypass mode.
• Treating candidates as proof. Diagnosis localizes; PFA proves — candidates have confidence, not certainty.
• Ignoring the passing cells. Passes constrain the candidate set (reject candidates that would fail a pass).
• Missing the systematic signal. Same site across many dies = a process/design fix (volume diagnosis), not just a scrapped die.

10. Industry Best Practices

• Feed diagnosis a clean datalog (X masked, models right, 13.3) — resolution is only as good as the input.
• Use the failing and passing cells — intersection + consistency give the ranked candidates.
• Switch to a diagnostic mode when compression makes the result loose (7.x) — restore observability.
• Treat candidates as PFA targets, not verdicts — PFA confirms the physical defect.
• Run volume diagnosis — aggregate a Pareto to separate systematic (fixable mechanism) from random.

11. Senior Engineer Thinking

• Beginner: "Diagnosis gave dozens of candidates — the tool's bad, or there are many defects."
• Senior: "A loose list on a compressed design means missing observability, not a bad tool — the compactor hid which cell failed (7.x). I re-run in a diagnostic/bypass mode to un-compact, and the candidates collapse to a few. Then PFA proves the top one — diagnosis localizes, PFA proves. And I check volume: if this site fails across many dies, it's systematic — a process/design fix, not just a scrap. Garbage in, garbage out — so I only diagnose a clean datalog."

The senior reads loose resolution as an observability problem, uses a diagnostic mode, and separates localization (diagnosis) from proof (PFA).

12. Silicon Impact

Diagnosis is the step that converts a confirmed defect into an actionable location — and, in aggregate, converts test failures into yield learning. It is fundamentally an inverse problem: from the observed failures (which patterns, which cells) plus the netlist and fault model, compute the fault candidates that best explain what was seen — reasoning backward from effect to likely cause. The engine is back-cone intersection: the defect must lie in the intersection of the failing cells' cones and be consistent with the passing cells (a candidate that would have failed a passing cell is rejected), so more failing observations tighten the set. The output — a ranked candidate list, a suspected fault type (stuck-at/bridge/open/transition), and an xy/layer hint — exists to point PFA, which is the essential boundary: diagnosis localizes; PFA proves. Because the method is observation-driven, its resolution tracks observability: many observers → tight, few → loose — and this collides productively with compression (7.x), which hides which exact cell failed behind a compacted signature, lowering resolution. That's a real coverage-vs-diagnosability tradeoff, resolved by a DIAGNOSTIC (bypass/hi-res) mode that un-compacts and restores per-cell observability — the reason diagnosable, compressed designs provide such a mode. Two boundaries keep diagnosis honest: garbage in, garbage out (a wrong fault model or unmasked X from a dirty 13.3 debug degrades the result — so clean the pattern debug first), and candidates are confidence, not certainty (PFA is the arbiter). The highest-leverage use is volume diagnosis: aggregating diagnosis across many failing dies yields a Pareto of failing sites/layers that distinguishes systematic failures (the same site across many dies → a design/process marginality to fix at the mechanism) from random particle defects — turning DFT from per-die pass/fail into a yield-learning engine that feeds process and design. For the failure-analysis engineer, diagnosis is a PFA target; for the yield/process engineer, it's a Pareto that directs improvement; for the DFT engineer, it's the payoff of clean chain (13.2) and pattern (13.3) debug; and for the program, it's how a debugged failure becomes fewer failures next lot. The next lesson (13.5) takes this whole localize-and-confirm discipline onto the tester at silicon bring-up, where the environment is live and the pressure is highest.

13. Engineering Checklist

• Fed diagnosis a clean datalog (X masked, models right, 13.3) — no garbage-in.
• Used failing + passing cells — cone intersection + consistency → ranked candidates.
• Switched to a diagnostic/bypass mode when compression made the result loose (7.x).
• Treated candidates as PFA targets (with confidence) — PFA confirms the physical defect.
• Ran volume diagnosis — a Pareto to separate systematic (mechanism fix) from random.

14. Try Yourself

1. Explain diagnosis as an inverse problem — from failing cells back to a candidate site via cone intersection.
2. Show how the passing cells constrain (reject) candidates — and why more failing observers → tighter.
3. State the boundary: diagnosis localizes, PFA proves — and what each produces.
4. Explain why compression lowers diagnostic resolution and how a diagnostic/bypass mode restores it (7.x).
5. Describe volume diagnosis → a Pareto → systematic vs random → yield learning.

The diagnosis reasoning is tool-neutral; diagnosis is a DFT tool, PFA is a lab process, volume Pareto is yield engineering. No paid tool required to reason about localization.

15. Interview Perspective

• Weak: "Diagnosis tells you where the defect is."
• Good: "Diagnosis intersects the failing cells' cones to give candidate sites, and PFA confirms the physical defect."
• Senior: "Diagnosis is an inverse problem: from the failing patterns/cells (a clean datalog — garbage in, garbage out) plus the netlist and fault model, it computes candidates by intersecting the failing cells' back-cones, consistent with the passing cells, and ranks them with a fault type and xy/layer hint. Its resolution tracks observability — more observers, tighter — so compression (7.x) lowers it by hiding which cell failed, and I un-compact with a diagnostic/bypass mode when it's loose. The boundary is firm: diagnosis localizes, PFA proves. And the big win is volume diagnosis — aggregate across many dies into a Pareto to separate systematic (a process/design fix) from random, so DFT drives yield learning, not just per-die scrap."

16. Interview / Review Questions

16b. References & Related Reading

Diagnosis sits between two standardised worlds and one unstandardised one, and it is worth being explicit about which is which.

• IEEE 1149.1 (JTAG / boundary scan) and IEEE 1500 (embedded core test) — the standardised access mechanisms through which test modes and chains are reached. What is standardised here is the access, not the diagnosis.
• IEEE 1450 (STIL) — the standard pattern-and-datalog interchange format. Where a failure datalog is exchanged in STIL, the field meanings are defined; many production flows use vendor formats instead.
• Diagnosis algorithms, candidate scoring, confidence values, and the ranked-list format are not standardised. They are vendor implementations of cone-intersection and fault-simulation techniques, and the scores from two tools are not comparable. Treat a confidence number as an internal ranking, never as a probability.
• Scan cell numbering, unload-position indexing, and stitching-report formats are per-tool conventions. This is why section 6b states the convention before using it. The cell = N + 1 − p arithmetic follows from a stated convention, not from a standard.
• Physical failure analysis — deprocessing, imaging, and probing — is laboratory practice governed by procedure rather than by a test standard. It is the only step in this chapter that establishes a fact about the silicon.

Within this curriculum: the triage that must precede diagnosis is Pattern Mismatch Debug; chain-structure localization and the k = N + 1 − C derivation are in Scan Chain Failure Debug; the observability cost of compaction is in Compression Loss Debug and EDT Scan Compression; the same discipline under tester conditions is Silicon Bring-up & Tester Debug. For the fault models that determine what a candidate list can even express, see Stuck-at Faults, Transition Delay Faults and Bridging & IDDQ Faults. The chain ordering that maps a cell index to an instance is Scan Stitching & Ordering.

17. Key Takeaways

• Diagnosis is an inverse problem: from failing patterns/cells + netlist + fault model back to the fault candidates that best explain the observed failures — by intersecting the failing cells' back-cones, consistent with the passing cells (more failing observers → tighter).
• Output: a ranked candidate list (+ confidence), a suspected fault type (stuck-at/bridge/open/transition), and an xy/layer hint — but diagnosis localizes, it does not prove; PFA (deprocess/image) confirms.
• Resolution ~ observability: compression (7.x) hides which cell failed → loose candidates → use a DIAGNOSTIC (bypass/hi-res) mode to un-compact (a real coverage-vs-diagnosability tradeoff).
• Volume diagnosis aggregates across many dies into a Pareto of sites/layers → systematic (same site → design/process fix) vs random → yield learning (DFT beyond per-die pass/fail).
• Garbage in, garbage out: a wrong fault model or unmasked X degrades diagnosis → clean the pattern debug (13.3) first; diagnosis gives candidates + confidence, not certainty. Next: 13.5 — silicon bring-up & tester debug.

18. Quick Revision

Diagnosis & failure localisation. A mismatch that survived the fork (13.3) is REAL → DIAGNOSIS = an INVERSE problem: from failing patterns/cells + netlist + fault model → fault CANDIDATES by INTERSECTING the failing cells' back-cones, consistent with the PASSING cells (more failing observers = tighter). Output: ranked candidates + confidence + fault type (stuck-at/bridge/open/transition) + xy/layer. Boundary: diagnosis LOCALIZES, PFA PROVES (deprocess/image). Resolution ~ observability → compression (7.x) hides the failing cell → LOOSE → re-run in a DIAGNOSTIC (bypass/hi-res) mode to un-compact. VOLUME diagnosis → aggregate many dies → a Pareto → systematic (same site → design/process fix) vs random → yield learning. Garbage in = garbage out → clean 13.3 first. Next: 13.5 — silicon bring-up & tester debug.