Reset Sequencing: Debug Playbook

Debug playbook

Debug Playbook for Reset Sequencing focuses on domain bring-up order violations, dependency deadlocks, reset latency. The goal is to convert issue observations into mechanism-backed closure decisions.

CDC/RDC debug is about finding the earliest violated assumption. Start with intent and context before touching low-level signal traces.

Root-cause tree

ROOT-CAUSE TREE — Reset Sequencing

crossing failure observed
        |
   reproducible?
     /        \
   no          yes
   |            |
stress mode   classify issue
expansion       /      |      \
            synchronizer protocol reset/reconvergence
                 |         |           |
            MTBF fit    liveness    release ordering

1. Freeze RTL/config/tool tags for reproducibility.

2. Reproduce in smallest mode/reset/traffic scenario.

3. Classify mechanism: synchronizer, protocol, reset, reconvergence, or governance.

4. Collect one decisive artifact that proves the class.

5. Pick minimal fix or bounded waiver.

6. Run targeted and full-regression matrices before closure.

Review memo template

STAFF CDC/RDC REVIEW MEMO — Reset Domain Crossing / Reset Sequencing

1. Symptom
   - Failing metric: domain bring-up order violations, dependency deadlocks, reset latency
   - Context: <mode, traffic, reset state, corner>
   - Risk class: <critical/high/medium/low>
   - Database tags: <rtl, config, assertions, tool setup>

2. Mechanism hypothesis
   - Primary mechanism: Reset ordering enforces dependency contracts so control domains and memories become valid before downstream consumers execute.
   - Competing hypothesis: <false warning / protocol bug / reset order / reconvergence>
   - Missing evidence: <assertion, waveform, formal proof, stress replay>

3. Proposed action
   - Minimal reversible change: <sync/protocol/reset/waiver decision>
   - Expected metric movement: <critical count delta>
   - Regression risk: throughput, boot, latency, mode interaction

4. Signoff
   - Re-run artifact: bring-up sequence spec, dependency matrix, firmware reset script
   - Required owners: SoC integration owner, firmware owner, RTL lead
   - Final decision: fix, bounded waiver, or escalate

CDC/RDC deep dive

Reset release ordering is a first-order reliability contract.

Concept diagram

RESET RELEASE FLOW

assert global -> clocks stable -> sync release per domain -> first transaction

Metric graph

BOOT STABILITY

passes per 1k boots: 920 -> 980 -> 999

Reports and artifacts

• reset dependency matrix

• RDC warning classes

• boot stress logs

• waiver aging

Mini case study

Domain B released before producer A was valid, causing rare startup deadlock.

Debug branches

• Correlate reset and clock timelines

• verify async assert/sync release

• exercise skewed release tests

Senior review question

Ask: what evidence proves this risk is closed for silicon, not just tool-clean?

Key takeaways

• State crossing class, assumptions, and owner with every issue.

• Run structural and dynamic regressions after each fix.

Common pitfalls

• Treating all warnings as equivalent risk.

• Waiving issues without containment evidence.

• Skipping reset and reconvergence stress after CDC fixes.

Principal CDC/RDC review addendum

Reset ordering enforces dependency contracts so control domains and memories become valid before downstream consumers execute.

Metric: domain bring-up order violations, dependency deadlocks, reset latency