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
      • Why Reset-aware Simulation
      • Reset Sequences and Random Resets
      • Reset Checks and Assertions
      • Reset Coverage
    • 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

‹Reset-aware Simulation
  1. Topics
  2. CDC & RDC
  3. RDC Signoff
  4. Reset-aware Simulation
  5. Reset Coverage

Part 8 · RDC Signoff · All levels

Reset Coverage

Coverage questions for reset scenarios: which resets moved, when, and against what design state.

On this page

    Passing reset tests prove the scenarios that ran. Coverage proves the scenarios ran at all. Reset coverage asks, for every reset and every interesting design state, whether a reset landed there during the regression. An empty answer is a hole in the signoff, not a pass.

    The coverage questions

    Question

    What a hole means

    Did each reset assert at time zero?

    The baseline release sequence for that reset never ran.

    Did each reset assert while its domain was busy?

    Mid-operation recovery is untested for that domain.

    Did each reset assert while its neighbour kept running?

    Partial-reset behaviour is untested.

    Did each sequenced domain release in every allowed order?

    Only the easy order is proven; the risky orders are assumed.

    Did back-to-back resets occur?

    Recovery-during-recovery is untested.

    Did reset coincide with a stalled handshake or a full buffer?

    Reset-under-backpressure is untested.

    Did every waiver-relevant condition occur?

    A waived crossing claims a condition, such as a settled input, that no test ever produced.

    How to collect it

    Each question becomes a small coverable event: the reset name, the design state, and their coincidence. A simple approach that works without special tooling is a checklist table filled from the test plan and confirmed against logs: for each reset and each scenario, the seed and the test that covers it. Whatever the mechanism, the review reads the holes, not the hits: one uncovered row re-opens the dynamic-checks item for that reset.

    What the checks and the review look for

    The review maps every reset in the intent to at least the time-zero and mid-operation rows, and every sequenced domain to the ordering rows. Coverage collected only on the default configuration, or only with all resets moving together, is rejected: partial resets and staggered releases must appear in the evidence.

    Common pitfall

    Counting cycles with reset active as coverage inflates the numbers without proving anything. Coverage is reset landing in each design state, not reset being held for many cycles in one state.

    Interview

    Expect: how do you know reset testing is complete? Answer: per-reset coverage of assertion during busy, idle, and stalled states, plus release-order coverage for sequenced domains, reviewed as holes rather than totals.

    Check yourself A regression runs one million cycles with reset asserted once at time zero. Is reset coverage good?

    No. One scenario ran for many cycles. Coverage asks which scenarios ran, and mid-operation, partial, ordered, and back-to-back resets are all missing.

    Check yourself A waiver claims a configuration input is always settled at release. What coverage row must exist?

    A row showing reset released while that input held its settled value, in every configuration the waiver covers. Without it the waiver argument is untested.

    Related topics

    • Reset sequences and random resets

    • Reset checks and assertions

    • What to track

    Previous

    126 / 179

    Next: Chip-level RDC Closure

    Up next

    Up nextChip-level RDC Closure

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Why Reset-aware Simulation
    • Reset Sequences and Random Resets