CDC / RDC · All levels

RDC Structural Checks: Mechanism

Mechanism for RDC Structural Checks.

Mechanism to understand

Mechanism for RDC Structural Checks focuses on unsafe reset crossing count, unresolved RDC warnings, waiver backlog. The goal is to convert issue observations into mechanism-backed closure decisions.

RDC tools detect reset-origin and release-domain mismatches; violations must be triaged by intent, not mechanically waived. Treat each warning as a behavior contract violation candidate, then prove whether it is real risk or tool noise.

  • Classify crossing type and data criticality.

  • State source/destination clock or reset relationship.

  • Identify when protocol semantics dominate topology choice.

System flow

diagram
CDC/RDC SIGNOFF FLOW — RDC Structural Checks

crossing inventory + reset map
          |
          v
crossing classification (level/pulse/bus/reset)
          |
          v
structure + protocol + reset checks
          |
          v
critical issues + waiver review
          |
          v
fix / validate / regress / signoff

RDC structural classes

diagram
reset source A controls flop in domain B
            |
     release relationship legal?
        /             \
      yes             no
      pass          violation/waiver review

Layer responsibilities

diagram
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 waivers

CDC/RDC deep dive

Reset release ordering is a first-order reliability contract.

Concept diagram

diagram
RESET RELEASE FLOW

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

Metric graph

diagram
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.

Mechanism deep dive

RDC tools detect reset-origin and release-domain mismatches; violations must be triaged by intent, not mechanically waived.