Debugging Pattern Mismatches

Chapter 13 · Section 13.3 · DFT Debug Methodology

Project thread — the mini-SoC's pattern miscompares triaged: verify the expected value, hunt the X, and only call the survivor a real defect (which feeds diagnosis, 13.4).

1. Why Should I Learn This?

Pattern-mismatch debug is where you separate a real defect from a false miscompare — and unmasked X makes that separation the most common trap in DFT debug.

• A mismatch = captured ≠ expected at a cell/cycle (the datalog gives pattern/cell/cycle) — re-run the fork first (13.1).
• FALSE causes: unmasked X (uninit flop / non-scan cell — the #1 cause), capture race, a bad expected value, wrong mode.
• Verify the expected value with golden sim before trusting the miscompare — if sim also shows X, the pattern/model is wrong, not silicon.
• REAL = repeats, localizes, matches the fault the pattern targeted → feeds diagnosis (13.4).

2. Real Silicon Story — the miscompare that was an uninitialized flop

A team saw a handful of patterns miscompare at a few cells and prepared to scrap the affected dies as defective. The failures were repeatable, which looked like a defect.

Golden sim saved them. Before dispositioning, a DFT engineer re-ran those exact patterns in simulation on the good netlist — and sim also produced an X at the same compare cells. That meant the 'expected' value the tester compared against was itself untrustworthy: an uninitialized non-scan flop was feeding the compare point, injecting an X that the pattern set hadn't masked. This was an unmasked X, not a defect — the #1 cause of false pattern mismatches. They masked the X source (and fixed the initialization so the flop had a known value), re-ran, and the mismatches cleared. The dies were good. Lesson: a mismatch is captured ≠ expected, and before trusting the miscompare you must trust the expected value — golden-sim the pattern; if sim also shows X/mismatch, the pattern/model is the problem, not silicon. Unmasked X is the dominant false-mismatch source — hunt it before you call a mismatch a defect.

3. Factory Perspective — pattern debug through each lens

• What the test/DFT engineer sees: the miscompare triage — golden sim the pattern, hunt the X, check the mode, and only then call it real.
• What the RTL/DV engineer sees: the X sources (uninit flops, non-scan cells, black-boxes) and model mismatches (bidir/pull/tri-state) that make expected ≠ reality — a design/model fix.
• What the STA engineer sees: the capture-timing / multi-clock false causes (a race, an unconstrained inter-clock path, 12.x) — a constraint fix.
• What management cares about: that false miscompares aren't scrapped as defects (yield) and real defects aren't dismissed (quality) — the fork, applied at pattern level.

4. Concept — the miscompare fork and the golden-sim check

What a mismatch is:

• A pattern mismatch = the captured value at a cell ≠ the ATPG-expected value for that pattern.
• The datalog gives which pattern, which cell(s), which cycle — your OBSERVE.

First: re-run the fork (REAL vs FALSE):

• REAL (a defect): the pattern detected a fault — repeats deterministically, localizes, matches the fault model the pattern targeted → feeds diagnosis (13.4).
• FALSE (test-setup/pattern): the miscompare is not a defect. The specific pattern-debug FALSE causes:
  • X / UNKNOWN sources — uninit flop, non-scan cell, bus contention, memory read-before-write → an X propagates to a compare point → miscompare that's not a defect. Fix = mask the X source / initialize. #1 cause.
  • Multiple-clock / capture-timing — wrong-clock capture, a race, an unconstrained inter-clock path → captured at the wrong time (12.x). Not a defect.
  • Bad / mis-simulated pattern — the expected value is wrong from a modeling mismatch (bidir, pull, tri-state, black-box, timing exception). Expected ≠ reality.
  • Setup/mode — wrong test_mode / scan_enable / clock program at apply (12.5) → DUT not in the mode the pattern assumed.

The golden-sim / expected-value discipline:

• Always verify the expected value before trusting the miscompare.
• Simulate the pattern on the good netlist. If sim also produces X/mismatch at that point → the PATTERN/MODEL is the problem, not silicon (golden sim vs tester).

X-handling is central:

• Unmasked X is the dominant false-mismatch source.
• An X at a compare point can also corrupt a MISR/compactor signature (aliasing, 7.x/9.x) → mask X at the source or bound it.

Narrow it (change one variable):

• One pattern or many? One cell or many? One mode or all? At-speed only? — each narrows real-vs-false and points at a cause.
• Change one variable per experiment (slower clock, different pattern, mask an X).

5. Mental Model — checking the answer key before failing the student

Pattern debug is like a teacher who checks the answer key before failing a student for a 'wrong' answer.

• The student's answer is the captured value; the answer key is the ATPG-expected value. A mismatch looks like the student got it wrong (a defect).
• But a wise teacher first asks: is the answer key right? Maybe the question was ambiguous (an X-source — the input wasn't even defined), or the key has a typo (a bad expected value from a model mismatch), or the student answered a different exam (the wrong mode at apply). Re-solving the problem yourself (golden sim) reveals whether the key — not the student — is at fault.
• If your own solution also comes out 'undefined' at that question (sim shows X too), the question/key is broken, not the student — fix the exam (mask the X, fix the model/mode), don't fail them (scrap the die).
• Only when the key is verified right and the student still got it wrong, repeatably, in a way that matches a known misconception (the fault model) do you mark it a real error (a defect) — and investigate which concept they missed (diagnosis).

Check the answer key (golden-sim the expected value) before failing the student (scrapping the die) — a mismatch is often a broken question (unmasked X / bad model / wrong mode), not a wrong answer (a defect).

6. Working Example — triaging a mismatch with golden sim

Trace a mismatch through the golden-sim check and the fork:

# Pattern-mismatch triage - REPRESENTATIVE, tool-neutral:
  OBSERVE (datalog): pattern P57 miscompares at cell c (bit 812), cycle = capture, repeats every run
  --- FORK: REAL (defect) or FALSE (test-setup/pattern)? ---
  STEP 1 - VERIFY THE EXPECTED VALUE (golden sim on the GOOD netlist):
     re-simulate P57 -> does sim ALSO show X or a mismatch at cell c?
        YES, sim shows X at c    -> the EXPECTED value is untrustworthy -> a PATTERN/MODEL problem, NOT silicon
        NO, sim gives a clean 0/1 -> the expected value is trustworthy -> the miscompare is more likely REAL
  STEP 2 - HUNT the FALSE causes (if sim showed X, or to be sure):
     X source?      trace c's cone -> an UNINIT flop / NON-SCAN cell / bus contention / mem read-before-write feeding c
                    -> MASK the X source or INITIALIZE it (X = #1 false cause ; also corrupts MISR/compactor, 7.x/9.x)
     capture race?  wrong-clock capture / unconstrained inter-clock path (12.x) -> re-run with corrected capture
     bad expected?  a bidir/pull/tri-state/black-box/timing-exception the ATPG model missed -> fix the model
     wrong mode?    test_mode/scan_enable/clock program wrong at apply (12.5) -> put the DUT in the assumed mode
  STEP 3 - NARROW (change ONE variable): one pattern vs many? one cell vs many? one mode? at-speed only?
  --- DISPOSITION ---
     FALSE -> fix the setup/pattern/model, re-run -> mismatch clears (good die)
     REAL  -> repeats, localizes, matches the targeted fault -> feed DIAGNOSIS (13.4) to localize the defect

An X from an uninitialized flop propagating to a compare point is the classic false miscompare:

7. Industry Flow — verify expected, hunt X, then diagnose the real ones

Pattern debug verifies the expected value, hunts the false causes (X first), and only sends survivors to diagnosis:

8. Debugging Session — repeatable miscompares that were unmasked X

9. Common Mistakes

• Trusting the miscompare before the expected value. Golden-sim the pattern — if sim shows X, the pattern/model is wrong, not silicon.
• Calling a repeatable miscompare a defect. X-noise repeats too — repeatability alone doesn't prove a defect.
• Not hunting X first. Unmasked X is the #1 false cause — trace the compare cone for uninit/non-scan/contention.
• Ignoring the compactor. An X at a compare point corrupts the MISR/compactor signature (aliasing, 7.x/9.x) — mask at the source.
• Changing many variables at once. Change one (slower clock, mask an X, different pattern) per experiment.

10. Industry Best Practices

• Golden-sim the failing pattern on the good netlist before dispositioning — verify the expected value.
• Hunt X first — mask the source or initialize; X is the dominant false-mismatch cause (and corrupts signatures).
• Check capture timing / mode (12.x/12.5) — a race or wrong mode at apply mimics a defect.
• Narrow with one variable per experiment — one pattern/cell/mode, at-speed vs slow.
• Only send survivors to diagnosis — mismatches that repeat, localize, and match the targeted fault are real (13.4).

11. Senior Engineer Thinking

• Beginner: "These patterns miscompare and it repeats — it's a defect, scrap the dies."
• Senior: "Repeatable doesn't mean real — X-noise repeats too. First I golden-sim the patterns: if sim also shows X at those cells, the expected value is untrustworthy — a pattern/model problem, not silicon. I hunt the X source (uninit/non-scan/contention), mask it (it also corrupts the compactor signature), and re-run. Only a mismatch that repeats, localizes, and matches the targeted fault is a real defect — that one goes to diagnosis. Verify the key before failing the student."

The senior golden-sims the expected value and hunts X before ever calling a mismatch a defect.

12. Silicon Impact

Pattern-mismatch debug is where the fork of 13.1 gets its sharpest, most error-prone test, because a miscompare is inherently ambiguous — the same observation (captured ≠ expected, repeatably) can be a real defect or a false artifact of the test itself. With the chain verified by a good flush (13.2), the failures are genuine pattern-level events, but your first move is still triage, not disposition: re-run the fork. The FALSE causes are specific and dominated by one: unmasked X. An uninitialized flop, a non-scan cell, a bus contention, or a memory read-before-write injects an X that propagates to a compare point, producing a repeatable miscompare that is not a defect — and crucially, repeatability alone never proves a defect, because X-noise repeats too. (An unmasked X is doubly costly: it can also corrupt a MISR/compactor signature via aliasing, 7.x/9.x, turning one stray X into a whole-signature failure.) The other FALSE causes — a capture race / multi-clock issue (captured at the wrong time, 12.x), a bad/mis-simulated expected value from a model mismatch (bidir, pull, tri-state, black-box, timing exception), and a wrong mode at apply (12.5) — all share the same trap: the 'expected' value is untrustworthy. That is why the decisive discipline is the golden-sim / expected-value check: simulate the failing pattern on the good netlist, and if sim also shows X/mismatch at that compare point, the PATTERN/MODEL is the problem, not silicon — you fix the setup (mask the X at its source, initialize the flop, correct the capture/mode/model) and re-run, rather than scrapping good dies (the pattern-level echo of the wafer-scrap mistake in 13.1). Only a mismatch that survives — one that repeats, localizes, and matches the fault the pattern targeted — is a REAL defect, and it feeds diagnosis (13.4) for precise localization. For the test/DFT engineer, this is the golden-sim-and-hunt-X loop; for the RTL/DV engineer, it's a call to initialize state and fix models; for the STA engineer, it's the capture-timing false causes; and for the program, it's the yield-vs-quality balance struck at the finest grain. The throughline of the chapter holds: verify the expected value before trusting the miscompare, hunt X before calling a mismatch a defect — and pass only the survivors to diagnosis.

13. Engineering Checklist

• Re-ran the fork — REAL vs FALSE — before dispositioning the mismatch (13.1).
• Golden-simmed the failing pattern on the good netlist — verified the expected value.
• Hunted X first — masked the source / initialized (and protected the compactor signature, 7.x/9.x).
• Checked capture timing / mode (12.x/12.5) and narrowed with one variable per experiment.
• Sent only survivors (repeat + localize + match the targeted fault) to diagnosis (13.4).

14. Try Yourself

1. Define a pattern mismatch (captured ≠ expected) and name what the datalog gives you (pattern/cell/cycle).
2. List the FALSE pattern-debug causes — and why unmasked X is the #1 one.
3. Explain the golden-sim check: why verifying the expected value on the good netlist comes before trusting the miscompare.
4. Show an uninit-flop X reaching a compare point → a false miscompare → and how masking/init fixes it.
5. State what makes a mismatch REAL (repeats, localizes, matches the targeted fault) and where it goes next (13.4).

The triage/golden-sim reasoning is tool-neutral; patterns come from ATPG, the datalog from the ATE, golden sim from a simulator. No paid tool required to reason about pattern debug.

15. Interview Perspective

• Weak: "If a pattern fails, the chip has a defect there."
• Good: "I check whether it's a real fault or an X / bad expected value, and I mask X sources."
• Senior: "A mismatch is captured ≠ expected, and it's ambiguous — so I re-run the fork. The #1 false cause is unmasked X (an uninit flop, non-scan cell, contention) propagating to a compare point — a repeatable miscompare that's not a defect (and it can corrupt the compactor signature too, 7.x/9.x). So before trusting the miscompare I verify the expected value with golden sim on the good netlist: if sim also shows X, the pattern/model is wrong, not silicon — I mask the X source or initialize, fix any capture-race / wrong-mode issue (12.x/12.5), and re-run. Repeatability alone doesn't prove a defect — only a mismatch that repeats, localizes, and matches the targeted fault is real, and that one goes to diagnosis (13.4)."

16. Interview / Review Questions

17. Key Takeaways

• A pattern mismatch = captured ≠ ATPG-expected at a cell/cycle (the datalog gives pattern/cell/cycle) — re-run the fork first (13.1); repeatability alone does not prove a defect.
• FALSE pattern-debug causes: unmasked X (uninit flop / non-scan cell / contention / mem read-before-write — the #1 cause), multi-clock / capture race (12.x), a bad/mis-simulated expected value (model mismatch), and the wrong mode at apply (12.5).
• Verify the expected value with golden sim on the good netlist before trusting the miscompare — if sim also shows X/mismatch, the PATTERN/MODEL is wrong, not silicon.
• X-handling is central: unmasked X is the dominant false-mismatch source and can corrupt a MISR/compactor signature (aliasing, 7.x/9.x) → mask X at the source or bound it (or initialize).
• A REAL mismatch repeats, localizes, and matches the fault the pattern targeted → it feeds diagnosis (13.4). Narrow with one variable per experiment (slower clock, mask an X, different pattern). Next: 13.4 — diagnosis & failure localisation.

18. Quick Revision

Debugging pattern mismatches. With a GOOD flush (13.2), debug PATTERN miscompares: captured ≠ ATPG-expected at a cell/cycle (datalog = pattern/cell/cycle). FORK FIRST (13.1). FALSE causes: unmasked X (uninit flop / non-scan cell / contention — the #1 cause, also corrupts MISR/compactor via aliasing 7.x/9.x), multi-clock/capture race (12.x), bad expected value (bidir/pull/tri-state/black-box model mismatch), wrong mode at apply (12.5). DISCIPLINE: verify the EXPECTED value with golden sim on the good netlist BEFORE trusting the miscompare — if sim also shows X/mismatch, the pattern/model is wrong, NOT silicon → mask X at the source / initialize / fix model/mode, re-run. Repeatable ≠ real (X-noise repeats). REAL = repeats + localizes + matches the targeted fault → diagnosis (13.4). Narrow with ONE variable per experiment. Next: 13.4 — diagnosis & localisation.