Silicon Bring-up · All levels
Failure Triage & Debug: Tricky Q&A
Senior interview and review questions for Failure Triage & Debug.
Section Q&A bank
Use these drills after completing all topics in Failure Triage & Debug. Answer with setup context, mechanism proof, artifact, owner, and release decision.
When a bring-up failure disappears after enabling verbose tracing, what should you conclude first?
[INT][BRINGUP][FAILURE-TRIAGE]
Q: When a bring-up failure disappears after enabling verbose tracing, what should you conclude first?
A:
Treat observability as a perturbation and assume the failure window shifted, not that the bug vanished. Verbose tracing can change timing, interrupt load, memory pressure, and power states, so you should re-establish a minimally intrusive repro path before trusting any hypothesis.
FOLLOW-UP TRAP: Declaring the issue fixed because the instrumented build now passes repeatedly.How do you differentiate livelock from deadlock during a silicon hang investigation?
[INT][BRINGUP][FAILURE-TRIAGE]
Q: How do you differentiate livelock from deadlock during a silicon hang investigation?
A:
Look for bounded but non-productive activity. Livelock shows repeated state transitions and traffic with no completion progress, while deadlock shows a stable wait cycle with no legal escape. Heartbeat counters plus dependency graph analysis are the fastest discriminator.
FOLLOW-UP TRAP: Classifying any non-booting system as deadlocked without checking ongoing state churn.Why is a failure-rate curve more valuable than a single deterministic reproduction for marginal bugs?
[INT][BRINGUP][FAILURE-TRIAGE]
Q: Why is a failure-rate curve more valuable than a single deterministic reproduction for marginal bugs?
A:
Marginal bugs are often probabilistic interactions of timing and environment. A curve across controlled stress axes reveals sensitivity and confidence bounds, helping you distinguish true causality from incidental correlation and quantify mitigation impact.
FOLLOW-UP TRAP: Optimizing for one deterministic setup that cannot explain field variability.What makes an FA request likely to produce actionable evidence instead of an expensive dead end?
[INT][BRINGUP][FAILURE-TRIAGE]
Q: What makes an FA request likely to produce actionable evidence instead of an expensive dead end?
A:
A hypothesis-linked handoff with exact failing context, suspect region, and requested technique rationale. Asking for FIB or emission microscopy without a constrained failure model usually returns interesting images but weak causality for fix decisions.
FOLLOW-UP TRAP: Escalating to FA with generic 'chip fails to boot' notes and no experiment-backed suspect boundary.Q&A drill guide
SYMPTOM -> ROOT-CAUSE CLASS -> ARTIFACT -> OWNER ACTION -> VALIDATIONSketch while answering
TRIAGE CONVERGENCE
symptom -> classify -> isolate -> prove -> bounded fix -> replayCommon traps
Preserve first-failure state before reruns.
Use disproof-oriented experiments to collapse cause tree quickly.
Promote fixes only after recurrence tracking windows pass.
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.