Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • Reading Path
  • CDC/RDC Glossary
  • CDC/RDC Metrics Reference
  • CDC/RDC Interview Prep
  • CDC/RDC Signoff Cheatsheet
  • Clock Domains and Failure Modes8
  • Metastability and Synchronizers16
  • CDC Protocols and Handshakes16
  • Reconvergence and Gray Coding16
  • Reset Domain Crossing16
  • Architecture and Design Rules16
  • CDC Signoff Methodology24
  • RDC Signoff16
    • RDC Methodology
    • Reset-aware Simulation
    • Chip-level RDC Closure
    • RDC Signoff Dashboard
      • What to Track
      • Reading RDC Progress
      • Waivers in RDC
      • Final Signoff Package
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹RDC Signoff Dashboard
  1. Topics
  2. CDC & RDC
  3. RDC Signoff
  4. RDC Signoff Dashboard
  5. Waivers in RDC

Part 8 · RDC Signoff · All levels

Waivers in RDC

RDC waiver evidence, review, and expiry.

On this page

    A waiver is a written argument that a finding is safe, approved by someone with authority to accept the risk, and it dies on its expiry date. RDC waivers follow the same shape as the general waiver process described in the CDC waiver policy topic of the CDC signoff methodology section of this course; this lesson covers what makes RDC waivers specific: the evidence they need and the ways they go stale.

    What an RDC waiver must contain

    Element

    What good looks like

    The finding

    Identified by report, run revision, and location, so the waiver cannot drift onto a different finding.

    The safety argument

    Why this crossing is safe: settled quasi-static input, permanent tie-off, or synchronised release proven elsewhere.

    The evidence

    The proof behind the argument: simulation results, coverage rows, configuration records, or analysis excerpts.

    The reviewer and date

    A named approver with authority over the risk, and the approval date.

    The expiry

    A date or a triggering condition, such as any change to the connected RTL, after which the waiver is void.

    The re-check plan

    How the waiver is re-verified at renewal: which evidence must be reproduced.

    Review and expiry

    Review approves waivers one by one against their evidence, never in bulk, and records the expiry where the dashboard can see it. Expiry is automatic: an expired waiver re-opens its finding without debate, and renewal repeats the full review with fresh evidence, not a rubber stamp. A waiver whose RTL changed since approval has effectively expired even if its date has not: the safety argument was about the old structure.

    What the checks and the review look for

    The review checks that no defect is closed by waiver, that each waiver maps to exactly one finding, and that waiver evidence is itself current: simulation results on final RTL, coverage rows that still exist, configuration records matching the taped-out configuration. Waivers referencing stale runs or draft intent go back for rework.

    Common pitfall

    Bulk-approving a list of similar waivers approves the pattern, not the instances. Two identical-looking crossings in different domains can have different neighbours and orderings, so each waiver earns its own evidence and its own signature.

    Check yourself A waiver cites passing simulation results from two RTL revisions ago. Approve or send back?

    Send back. The evidence is stale: the current RTL may have moved the crossing the argument was about. Reproduce the evidence on final RTL first.

    Check yourself The connected RTL changed but the waiver date has not arrived. Is the waiver still valid?

    No. The safety argument described the old structure, so the change voids it regardless of the calendar date. Re-open the finding and re-review.

    Related topics

    • What to track

    • Final signoff package

    • Classifying RDC findings

    Previous

    133 / 179

    Next: Final Signoff Package

    Up next

    Up nextFinal Signoff Package

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • What to Track