CDC / RDC · All levels

RDC Signoff Dashboard

RDC Signoff: An RDC dashboard tracks readiness across blocks and milestones, preventing unresolved reset risks from being hidden by aggregate pass rates.

What this topic teaches

RDC Signoff Dashboard focuses on closing CDC/RDC risk with mechanism-level reasoning. An RDC dashboard tracks readiness across blocks and milestones, preventing unresolved reset risks from being hidden by aggregate pass rates. Senior signoff depends on proving behavior with targeted evidence, not just clearing tool warnings.

The senior-engineer question

When RDC critical trend, waiver aging, milestone readiness regresses, can you classify the hazard, identify accountable owners, and choose the smallest fix or waiver backed by evidence?

diagram
CDC/RDC SIGNOFF FLOW — RDC Signoff Dashboard

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

Picture the crossing behavior

Draw the behavior before touching tools. These visuals are the expected whiteboard baseline for reviews and interviews.

RDC readiness board

diagram
milestone M-2: critical 12 -> 4
milestone M-1: critical 4 -> 0
waivers stale >30d: must be reviewed

Crossing sequence

diagram
CROSSING FLOW — RDC Signoff Dashboard

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

Key metric: RDC critical trend, waiver aging, milestone readiness

Ownership layers

diagram
CDC/RDC OWNERSHIP LAYERS — RDC Signoff Dashboard

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

Evidence to collect

  • Primary metric: RDC critical trend, waiver aging, milestone readiness.

  • Primary artifact: RDC dashboard snapshot, milestone report, owner action queue.

  • Owners to involve: RDC lead, program manager, signoff owner.

  • At least one reproducer tied to mode/reset/traffic context.

  • Decision record: fix, waive, or escalate with rationale.

Ownership map

diagram
OWNERSHIP MAP — RDC Signoff Dashboard

artifact                  owner
----------------------    -------------------------
design intent           RDC lead
verification evidence   program manager
signoff decision        signoff owner

Every open CDC/RDC issue needs one accountable owner before waiver or fix.

Subpages in this topic

Each topic includes mechanism, I/O contract, metrics, debug, worked example, pitfalls, interview drills, checklist, theory, design tradeoffs, expanded case study, walkthrough, comparison matrix, software view, and silicon impact.

Key takeaways

  • Classify crossing/reset hazards before proposing fixes.

  • Pair structural results with protocol/reset behavioral proof.

  • Treat waivers as bounded risk contracts, not cleanup shortcuts.

Common pitfalls

  • Mass-waiving warnings near tapeout.

  • Assuming local IP cleanliness guarantees SoC behavior.

  • Skipping reconvergence and reset stress after CDC fixes.

CDC/RDC deep dive

RDC closure must connect IP assumptions to SoC reality.

Concept diagram

diagram
RDC CLOSURE

IP reset intent + SoC sequencing -> structural checks -> dynamic stress -> signoff

Metric graph

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