BIST Signoff: Debug Playbook

Debug playbook

Debug Playbook for BIST Signoff focuses on MBIST/LBIST pass criteria, startup test time, in-field diagnostic readiness. The goal is to convert metric movement into mechanism, owner, and release decision.

Debug aims to find the first incorrect assumption, not the loudest downstream symptom. Start with reproducibility and ownership.

Root-cause tree

ROOT-CAUSE TREE - BIST Signoff

MBIST/LBIST pass criteria, startup test time, in-field diagnostic readiness regresses
        |
  setup changed?
    /        \
  yes         no
  |            |
constraint    silicon or
or ATPG       physical/test path
 /    \          |
SDC   model    chain/clock/power/diagnosis
diff  diff     isolate first failing signature

1. Freeze run tags for patterns, constraints, and tester setup.

2. Isolate first failing metric bucket and scenario.

3. Classify failure source: model, constraints, physical, or silicon.

4. Prove mechanism with one reduced replay or targeted run.

5. Apply smallest owner-controlled fix.

6. Re-run timing, power, and quality regression matrix.

Review memo template

STAFF DFT REVIEW MEMO - MBIST & LBIST / BIST Signoff

1. Symptom
   - Watched metric: MBIST/LBIST pass criteria, startup test time, in-field diagnostic readiness
   - Failing scenario: <mode/lot/corner/program>
   - Pattern class: <scan/transition/compressed/BIST/JTAG>
   - Tags: <constraints, patterns, tester program, netlist>

2. Mechanism hypothesis
   - Primary mechanism: BIST signoff verifies architecture correctness, quality targets, safety intent, and production programmability before release.
   - Competing hypothesis: <constraint issue, model issue, physical issue, silicon issue>
   - Missing evidence: <report, replay, diagnosis trace>

3. Proposed action
   - Minimal reversible change: <constraint fix, architecture tweak, pattern update>
   - Expected metric movement: <delta>
   - Regression risk: timing, power, quality, schedule

4. Signoff
   - Re-run artifact: BIST signoff checklist, startup test profile, release approval memo
   - Required owners: DFT lead, product test owner, quality owner
   - Final decision: release, waive, rollback, or escalate

DFT deep dive

BIST value is realized only when insertion, diagnosis, and repair are tied to production flow.

Concept diagram

BIST FLOW

insert MBIST/LBIST -> execute -> collect signatures -> diagnose/repair -> signoff

Metric graph

REPAIR EFFECT

yield
  ^
  |      o pre-repair
  |             o post-repair
  +---------------------> lot

Reports and artifacts

• MBIST insertion coverage

• repair signature report

• LBIST resistant fault list

• BIST release checklist

Mini case study

Fuse programming mismatch blocked repair activation; corrected bring-up script recovered expected yield uplift.

Debug branches

• Validate BIST reachability

• Correlate fail maps to repair signatures

• Audit in-field boot test budget

Senior review question

Ask: what evidence proves this DFT decision is safe for production?

Key takeaways

• State metric, lot/corner context, and pattern tag with every claim.

• Treat timing, power, and quality as one signoff problem.

Common pitfalls

• Chasing coverage without legality checks.

• Ignoring test-power side effects of pattern changes.

• Debugging silicon without reproducible tags.

Principal DFT review addendum

BIST signoff verifies architecture correctness, quality targets, safety intent, and production programmability before release.

Metric: MBIST/LBIST pass criteria, startup test time, in-field diagnostic readiness