RDC Methodology: Debug Playbook

Debug playbook

Debug Playbook for RDC Methodology focuses on reset-domain hazard coverage, unresolved RDC severity count, closure quality. 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 — RDC Methodology

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 / RDC Methodology

1. Symptom
   - Failing metric: reset-domain hazard coverage, unresolved RDC severity count, closure quality
   - Context: <mode, traffic, reset state, corner>
   - Risk class: <critical/high/medium/low>
   - Database tags: <rtl, config, assertions, tool setup>

2. Mechanism hypothesis
   - Primary mechanism: RDC methodology treats reset behavior as a first-class asynchronous interface requiring intent capture, structural checks, and targeted dynamic proof.
   - 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: RDC methodology guide, rule-set config, hazard taxonomy
   - Required owners: RDC lead, methodology owner, verification lead
   - 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

RDC methodology treats reset behavior as a first-class asynchronous interface requiring intent capture, structural checks, and targeted dynamic proof.

Metric: reset-domain hazard coverage, unresolved RDC severity count, closure quality