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
      • The RDC Signoff Flow
      • Reset Intent and Reset Domains
      • Classifying RDC Findings
      • RDC Closure Criteria
    • Reset-aware Simulation
    • Chip-level RDC Closure
    • RDC Signoff Dashboard
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹RDC Methodology
  1. Topics
  2. CDC & RDC
  3. RDC Signoff
  4. RDC Methodology
  5. Classifying RDC Findings

Part 8 · RDC Signoff · All levels

Classifying RDC Findings

Which findings are defects, which are acceptable with evidence, and the decision table.

On this page

    A structural report lists every reset-domain crossing it can see, including crossings the designer intended. Classification is the judgement that turns that list into work: each finding becomes a defect to fix or an acceptable crossing backed by evidence. An unclassified finding is an open finding.

    The decision table

    Finding

    Usual disposition

    Evidence needed

    Asynchronous deassertion with no synchroniser

    Defect.

    None: add a reset synchroniser or re-parent the reset, then re-analyse.

    Reset crossing with a synchronised, ordered release

    Acceptable.

    The synchroniser structure plus passing reset-aware tests of the release sequence.

    Quasi-static signal sampled while reset is settled

    Waiver candidate.

    Proof the signal cannot change near release, plus review approval.

    Reset tied to a constant in this configuration

    Waiver candidate.

    The configuration record showing the tie-off is permanent, plus review approval.

    Undocumented reset or unmapped register

    Defect in the intent.

    Completed intent and a re-run; never waived.

    Shared synchroniser across unrelated domains

    Defect: split the synchronisers.

    A waiver with skew analysis exists only for synchronous, related domains; across asynchronous domains the release cannot be aligned to both clocks.

    Defect or acceptable: the test

    Ask one question: does the receiving logic see a clean, ordered release under every allowed reset sequence? If the answer is yes and there is proof, usually the synchroniser plus a passing reset sequence, the finding is acceptable. If the answer is yes but only by argument, it needs a waiver with that argument written down and approved. Anything else is a defect.

    What the review looks for

    The review reads the classification, not just the count. It checks that every finding has exactly one disposition, that no defect is closed by argument alone, and that each waiver names its evidence and expiry. A report where the defect count fell because findings were reclassified without new evidence goes back for rework.

    Common pitfall

    Closing findings to hit a count target, for example reclassifying defects as acceptable because only a few are left, corrupts the whole flow. Classify each finding on its own evidence; the count is an output, never a goal.

    Interview

    Expect: when would you waive an RDC finding? Answer: only for a crossing that is safe by construction, such as a settled quasi-static input or a permanent tie-off, with written evidence, review approval, and an expiry so the waiver dies if the RTL changes.

    Check yourself A finding shows asynchronous deassertion with no synchroniser, and the designer argues the reset is rarely asserted. Defect or acceptable?

    Defect. Rarity is not synchronisation: the first assertion can still release into metastability. Add a reset synchroniser or re-parent the reset.

    Check yourself What distinguishes an acceptable finding from a waiver candidate?

    An acceptable finding meets the signoff rule directly, with proof such as a synchroniser plus passing tests. A waiver candidate is safe only by extra argument, such as a settled quasi-static input, and needs that argument written, approved, and expired.

    Related topics

    • Reset intent and reset domains

    • RDC closure criteria

    • Waivers in RDC

    Previous

    121 / 179

    Next: RDC Closure Criteria

    Up next

    Up nextRDC Closure Criteria

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • The RDC Signoff Flow