Reset-aware Simulation: Debug Playbook

Debug playbook

Debug Playbook for Reset-aware Simulation focuses on reset scenario coverage, X-propagation escapes, boot repeatability. 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-aware Simulation

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 — RDC Signoff / Reset-aware Simulation

1. Symptom
   - Failing metric: reset scenario coverage, X-propagation escapes, boot repeatability
   - Context: <mode, traffic, reset state, corner>
   - Risk class: <critical/high/medium/low>
   - Database tags: <rtl, config, assertions, tool setup>

2. Mechanism hypothesis
   - Primary mechanism: Simulation with realistic reset jitter, sequencing, and asynchronous release uncovers scenarios that static analysis alone cannot classify.
   - 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: reset stress testbench, X-prop report, scenario coverage table
   - Required owners: DV lead, RDC owner, firmware owner
   - Final decision: fix, bounded waiver, or escalate

CDC/RDC deep dive

RDC closure must connect IP assumptions to SoC reality.

Concept diagram

RDC CLOSURE

IP reset intent + SoC sequencing -> structural checks -> dynamic stress -> signoff

Metric graph

MILESTONE READINESS

M-2 55%
M-1 82%
M0  100%

Reports and artifacts

• top-level RDC opens

• reset simulation coverage

• chip integration blockers

• waiver backlog

Mini case study

Each IP was locally clean, but top-level sequencing violation created cross-subsystem boot intermittency.

Debug branches

• Audit subsystem assumptions

• stress chip-level reset scenarios

• close ownership gaps

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

Simulation with realistic reset jitter, sequencing, and asynchronous release uncovers scenarios that static analysis alone cannot classify.

Metric: reset scenario coverage, X-propagation escapes, boot repeatability