CDC / RDC · All levels
RDC Structural Checks: Theory Deep Dive
Theory Deep Dive for RDC Structural Checks.
Foundational theory
RDC Structural Checks anchors Reset Domain Crossing. RDC tools detect reset-origin and release-domain mismatches; violations must be triaged by intent, not mechanically waived. Senior signoff discussions tie every warning to mechanism class, operational mode, and risk containment evidence.
Core concepts explained
RDC tools detect reset-origin and release-domain mismatches; violations must be triaged by intent, not mechanically waived.
Primary metric: unsafe reset crossing count, unresolved RDC warnings, waiver backlog
Primary artifact: RDC structural report, reset intent annotation, waiver log
Owners: RDC owner, RTL owner, methodology lead
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 source A controls flop in domain B
|
release relationship legal?
/ \
yes no
pass violation/waiver reviewWorked intuition
Classify crossing intent and direction.
Name clock/reset relationship assumptions.
Inspect primary metric: unsafe reset crossing count, unresolved RDC warnings, waiver backlog.
Collect structural plus dynamic evidence.
Differentiate real hazard from tool noise.
Pick smallest safe fix and define regression matrix.
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
RDC structural classes
reset source A controls flop in domain B
|
release relationship legal?
/ \
yes no
pass violation/waiver reviewLayer responsibilities
CDC/RDC OWNERSHIP LAYERS — RDC Structural Checks
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 waiversCDC/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 transactionMetric graph
BOOT STABILITY
passes per 1k boots: 920 -> 980 -> 999Reports 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.