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. Confirm the chain first with a flush (scan chain failure debug) — a broken chain fails every 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 — uncontrolled clocks, resets and latches catalogues where they come from, and under compression one X can fail a whole set (compression loss debug).
  • 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:

6b. Localizing a mismatch, worked

The datalog says which pattern, which chain, which unload bit. Turning that into a cell is arithmetic, and it runs from the scan-out end — the bits that emerge first are the cells nearest scan-out.

DATALOG EXTRACT
  device      : lot 4471, wafer 12, die (14,9)
  pattern     : 18432          (transition, LOC)
  chain       : 7    (length L = 412 cells)
  unload bit  : 137            (1-based, first bit out = 1)
  expected    : 1
  observed    : 0
  other chains: all pass
 
LOCALIZE
  Cell k, numbered 1..L from SCAN-IN:
 
      k = L + 1 - u  =  412 + 1 - 137  =  276
 
  So unload bit 137 is the capture value of scan cell 276 on chain 7.
 
  Sanity-check the direction, every time:
      u = 1  -> k = 412 : first bit out is the cell nearest SCAN-OUT
      u = L  -> k = 1   : last  bit out is the cell nearest SCAN-IN
  If your formula gives the opposite, you are counting from the wrong end -
  on a 412-cell chain that is a 275-cell error.
 
CROSS-REFERENCE
  Map cell 276 in chain 7's stitched order to its instance name (see
  /dft/scan-stitching-ordering), then ask the
  ATPG tool which fault(s) pattern 18432 targeted at or near that cell. A
  mismatch at a cell the pattern was NOT targeting is a strong hint of a FALSE
  cause (an X arriving from elsewhere) rather than the intended detection.

Separating shift infrastructure from capture logic

The single most useful experiment on a mismatch is the one that decides which half of the scan operation is broken, because the two lead to completely different investigations. Both experiments use the same silicon and the same tester setup, changing one variable.

EXPERIMENT A - SHIFT ONLY (chain integrity / flush)
  Load a known pattern, shift it straight out, perform NO capture.
  This exercises the chain and nothing else: cell -> cell connectivity,
  shift clock, scan_enable held high, lock-up latches.
 
    unload == load (delayed by L)  ->  SHIFT INFRASTRUCTURE IS GOOD
    unload != load                 ->  SHIFT problem: stop here.
                                       Every pattern result is noise until
                                       the chain is fixed (see
                                       /dft/scan-chain-failure-debug).
 
EXPERIMENT B - CAPTURE ONLY (load, capture, unload)
  Run the full pattern but compare ONLY the cells the pattern targets, with
  everything else masked.
 
    A passes and B fails   ->  the chain carries data correctly, so the fault
                               is in the CAPTURE path: combinational logic,
                               capture clocking, an X source, or a stale
                               expected value.
    A fails and B fails    ->  fix A first. A broken chain fails every
                               pattern and tells you nothing about capture.
 
THE DECISION TABLE
  flush   patterns   conclusion
  ------  ---------  ----------------------------------------------------
  FAIL    FAIL       shift infrastructure. Localize the break; ignore
                     pattern content entirely until it is fixed.
  PASS    FAIL(all)  capture-side and systemic: mode/OCC program, a global
                     X source, or patterns generated against a stale netlist.
  PASS    FAIL(few)  capture-side and local: a real defect, or an X reaching
                     a small set of compare points. Golden-sim first.
  PASS    PASS       no mismatch to debug.

The middle row is the one that catches teams out. All patterns failing on a chain that flushes cleanly is not a defect signature — a single die does not develop hundreds of independent faults. It points at something applied to every pattern equally: the wrong test mode, an OCC program that does not match what ATPG assumed, or expected values generated from a netlist that no longer matches the silicon.

  Simulate pattern 18432 on the netlist ATPG was run against (rev C):
    cell 276 expected = 1      matches the pattern file
 
  Simulate the SAME pattern on the netlist that was actually taped out (rev D):
    cell 276 expected = 0      matches what silicon returned

# At pattern generation, record what the patterns were built from.
set nl_md5 [exec md5 -q $netlist_file]
write_patterns -format stil -comment "netlist_md5=$nl_md5" -output pat_18432.stil
 
# At apply, refuse to run patterns whose fingerprint does not match the
# netlist that was taped out.
if {$pattern_netlist_md5 ne $taped_out_netlist_md5} {
  error "PATTERN/NETLIST MISMATCH: patterns built from $pattern_netlist_md5,\
         silicon is $taped_out_netlist_md5 - regenerate before applying"
}

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

16b. Where This Is Specified

• IEEE 1149.1-2013 — Standard for Test Access Port and Boundary-Scan Architecture. The boundary-scan register and TAP, whose unload ordering follows the same scan-out-first model used by the localization arithmetic above.
• IEEE 1500-2005. Core test wrappers and wrapper chains, localized identically.
• Standard Test Interface Language (STIL), IEEE 1450. The pattern-interchange format in which expected values and their netlist provenance are carried between ATPG and the tester.

Fault models, ATPG pattern generation, X-masking strategies, compression and MISR signature behaviour, and datalog formats are established engineering practice rather than standardised behaviour, and are documented per tool and per tester.

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.