Silicon Bring-up · All levels

Root Cause Closure and FA Handoff: Debug Playbook

Debug Playbook for Root Cause Closure and FA Handoff.

Debug playbook

Debug Playbook for Root Cause Closure and FA Handoff is anchored on Closure quality measured by root-cause confidence, mitigation durability, and FA turnaround from sample request to actionable evidence.. Convert observed behavior into mechanism-backed and owner-bound actions.

Freeze setup metadata and preserve first-failure state.
Locate first persistent boundary where behavior diverges.
Classify mechanism: dependency, margin, protocol, software, or silicon.
Apply one focused reproducer and one bounded fix.
Re-run replay, corner, and soak confidence matrix.

Review memo template

diagram

BRING-UP REVIEW MEMO - Failure Triage & Debug / Root Cause Closure and FA Handoff

1. Symptom
   - Failing metric: Closure quality measured by root-cause confidence, mitigation durability, and FA turnaround from sample request to actionable evidence.
   - Trigger context: <board/firmware/corner/test window>
   - First failing boundary: <power/reset/clock/interface/firmware>

2. Mechanism hypothesis
   - Candidate mechanism: A bring-up issue is not closed when the system boots once; closure requires causal proof, deployable mitigation, and a credible path for silicon-level confirmation. Teams first lock the digital root-cause narrative from trace evidence and controlled A/B toggles, then decide whether physical failure analysis is required to disambiguate design bug, process defect, packaging stress, or board interaction. For suspected physical defects, the FA handoff must be surgical: exact failing unit history, capture conditions, suspect block coordinates, and hypothesis-linked requests for FIB cross-sectioning, emission microscopy, or related techniques. The best war stories are boring in hindsight because the FA request was hypothesis-driven, the lab-to-FA chain of custody was clean, and returned evidence mapped directly to fix strategy and screening plan.
   - Competing hypotheses: setup, dependency, margin, software path, silicon defect
   - Missing evidence: <trace/scope/register/report>

3. Proposed action
   - Smallest reversible change: <setup/script/config/firmware>
   - Expected movement: <repro rate/latency/pass trend>
   - Regression risk: stability, safety, release timeline, ownership handoff

4. Signoff
   - Required artifact: Root-cause closure bundle: causal chain memo, mitigation validation matrix, FA request packet, and return-to-production screening checklist.
   - Required owners: failure analysis owner, silicon bring-up lead, design and RTL owner, product engineering owner, quality and RMA owner
   - Final decision: ship, bounded rollout, rollback, respin escalation

Silicon bring-up deep dive

Triage quality is measured by how quickly teams converge from symptom to proven root-cause class with minimal collateral churn.

Concept diagram

diagram

TRIAGE CONVERGENCE

symptom -> classify -> isolate -> prove -> bounded fix -> replay

Metric graph

diagram

TRIAGE EFFECTIVENESS

wide speculative edits   ██████
classified bounded fixes █████████

Metrics and artifacts to collect

time-to-classification
first-failure artifact completeness
hypothesis branch conversion rate
post-fix recurrence trend

Mini case study

Intermittent field-like failures closed faster once teams forced one-variable branch tests and owner-tagged evidence packets.

Debug branches

Preserve first-failure state before reruns.
Use disproof-oriented experiments to collapse cause tree quickly.
Promote fixes only after recurrence tracking windows pass.

Senior review question

Ask: what is the first failing boundary, which artifact proves it, and who owns bounded closure?

Key takeaways

Tie every bring-up claim to one reproducible setup state and one proving artifact.
Prefer bounded fixes with clear owner and rollback trigger over broad multi-variable edits.

Common pitfalls

Running parallel uncontrolled experiments and losing causality.
Declaring closure without replaying across representative corners.
Escalating severity before bench/setup hypotheses are disproven.

Debug ladder

Sequence: reproduce -> classify -> isolate -> instrument -> bounded fix -> replay.

Avoid parallel broad edits before first root-cause class is proven.

Practice this lesson