RDC Structural Checks: Worked Example

Worked example

Worked Example 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.

A milestone review shows unsafe reset crossing count, unresolved RDC warnings, waiver backlog. Teams disagree on severity. The right move is to isolate one representative issue, prove mechanism class, and decide fix or waiver with explicit residual risk.

Crossing under inspection

CROSSING FLOW — RDC Structural Checks

source clock domain -> launch signal -> crossing structure -> destination sample
      |                    |                 |                    |
   source FF           protocol           sync / fifo         destination FF

Key metric: unsafe reset crossing count, unresolved RDC warnings, waiver backlog

RDC structural classes

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

1. Capture warning, waveform, and owning module context.

2. Tag mode/reset/traffic state for the failure.

3. Validate assumptions against spec and assertions.

4. Compare outcome with RDC structural report, reset intent annotation, waiver log.

5. Choose one reversible action and define regression upfront.

Did the action work?

BEFORE / AFTER — RDC Structural Checks

open critical issues
  ^
  |  o baseline
  |     o after fix batch
  |         o after protocol proof
  |             o signoff-ready
  +---------------------------------> closure iteration

Track issue burn-down with evidence quality, not only count.

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.

Principal CDC/RDC review addendum

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

Metric: unsafe reset crossing count, unresolved RDC warnings, waiver backlog