Reset Deassertion CDC: Theory Deep Dive

Foundational theory

Reset Deassertion CDC anchors Reset Domain Crossing. Asynchronous assertion is usually safe, but reset deassertion must be synchronized per destination domain to prevent uncertain startup state capture. Senior signoff discussions tie every warning to mechanism class, operational mode, and risk containment evidence.

Core concepts explained

• Asynchronous assertion is usually safe, but reset deassertion must be synchronized per destination domain to prevent uncertain startup state capture.

• Primary metric: reset release violations, metastability-on-release risk, boot instability

• Primary artifact: reset tree map, release synchronizer audit, RDC report

• Owners: reset architect, CDC owner, RTL owner

• Distinguish structural cleanliness from functional correctness.

• Tie every waiver to silicon-risk framing and expiry.

Why this matters at signoff

At tapeout, unresolved CDC/RDC issues become latent reliability bugs. Reset release is an asynchronous interface problem with sequencing consequences.

Mental model

reset_n (global) ----> assert immediately
                  |
                  +--> per-domain release synchronizer

Unsynchronized deassertion can metastabilize startup flops.

Worked intuition

1. Classify crossing intent and direction.

2. Name clock/reset relationship assumptions.

3. Inspect primary metric: reset release violations, metastability-on-release risk, boot instability.

4. Collect structural plus dynamic evidence.

5. Differentiate real hazard from tool noise.

6. Pick smallest safe fix and define regression matrix.

7. Document signoff rationale or waiver ownership.

Common misconceptions

• CDC clean report means protocol is proven.

• All resets are equivalent if assertion works.

• Gray code alone guarantees FIFO correctness.

• Waivers are harmless schedule shortcuts.

Visual reinforcement

Async assert, sync release

reset_n (global) ----> assert immediately
                  |
                  +--> per-domain release synchronizer

Unsynchronized deassertion can metastabilize startup flops.

Layer responsibilities

CDC/RDC OWNERSHIP LAYERS — Reset Deassertion CDC

layer                 owns                            common failure
------------------    -----------------------------   -----------------------------
design intent         crossing architecture           wrong topology selected
protocol semantics    req/ack, fifo, ordering        liveness/deadlock bugs
reset behavior        assert/deassert sequencing      boot instability
analysis setup        tool rules + waivers            false confidence
signoff governance    risk acceptance + dashboard     stale critical waivers

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.

Theory reinforcement

Reset release is an asynchronous interface problem with sequencing consequences.