Silicon Bring-up · All levels

Scan Dump for State Observability During Bring-Up: Debug Playbook

Debug Playbook for Scan Dump for State Observability During Bring-Up.

Debug playbook

Debug Playbook for Scan Dump for State Observability During Bring-Up is anchored on Coverage of critical state elements in dump sets, dump-to-hypothesis convergence rate, and reproducibility confidence across failing samples.. 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 - Debug Interfaces & Observability / Scan Dump for State Observability During Bring-Up

1. Symptom
   - Failing metric: Coverage of critical state elements in dump sets, dump-to-hypothesis convergence rate, and reproducibility confidence across failing samples.
   - Trigger context: <board/firmware/corner/test window>
   - First failing boundary: <power/reset/clock/interface/firmware>

2. Mechanism hypothesis
   - Candidate mechanism: Scan dump techniques repurpose DFT scan chains to snapshot internal flop state after a failure signature, giving broad structural observability when live tracing is unavailable or too narrow. During bring-up, teams coordinate failure freeze points, clock-gating overrides, and capture controls so the dumped state reflects the true failing moment rather than post-failure drift. Interpretation requires mapping scan bits back to architectural intent, correlating with reset values and expected boot progression, and filtering X-propagation or uninitialized domains that can mislead diagnosis. When combined with SWD snapshots and targeted trace windows, scan dumps form a high-confidence triage loop for elusive hangs, dead boots, and protocol stalls that do not reproduce cleanly in simulation.
   - 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: State-observability dossier with scan chain maps, freeze-and-capture procedure, bit-to-register decode automation, and anomaly ranking worksheet.
   - Required owners: DFT owner, post-silicon debug owner, validation automation owner, microarchitecture owner
   - Final decision: ship, bounded rollout, rollback, respin escalation

Silicon bring-up deep dive

Debug interfaces are useful only when access paths are trusted, minimally intrusive, and synchronized to failure context.

Concept diagram

diagram

DEBUG ACCESS STACK

physical probes -> debug transport -> trace/scan capture -> correlated analysis

Metric graph

diagram

OBSERVABILITY MATURITY

access failures          ████
partial captures         █████
actionable captures      ███████

Metrics and artifacts to collect

JTAG/SWD access success rate
trace trigger hit coverage
scan dump decode turnaround time
observability gap backlog

Mini case study

A misdiagnosed silicon issue was cleared after TAP chain validation revealed a board-level debug domain assumption error.

Debug branches

Validate access-layer prerequisites before deep protocol decode.
Correlate trace timestamps with software checkpoints.
Treat missing evidence as an observability gap, not closure.

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