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
    • Reset Deassertion CDC
      • Why Deassertion Is the Hazard
      • Reset Synchroniser Structure
      • Recovery and Removal
      • Deassertion Hazards
    • Reset Sequencing
    • RDC Structural Checks
    • Reset Debug Playbook
  • Architecture and Design Rules16
  • CDC Signoff Methodology24
  • RDC Signoff16
  • Debug and Case Studies11
  • CDC and RDC Interview Prep30
  • Capstone: Sign Off a Multi-clock Peripheral4
Loading lesson

‹Reset Deassertion CDC
  1. Topics
  2. CDC & RDC
  3. Reset Domain Crossing
  4. Reset Deassertion CDC
  5. Recovery and Removal

Part 5 · Reset Domain Crossing · All levels

Recovery and Removal

Recovery and removal checks in plain terms and how they relate to reset release timing.

A flop with an asynchronous reset has two timing requirements that apply at the moment of release. They are the reset analogues of setup and hold, and they exist for the same reason: the flop needs its control inputs stable around the clock edge to decide cleanly.

Check

Plain meaning

Data analogy

Recovery

The release must happen at least the recovery time before the next active clock edge

Setup: data stable before the edge

Removal

Deassertion is forbidden inside the removal window just after a clock edge (the release must not sit just after the previous edge); the minimum asserted pulse width is a separate check

Hold: data stable after the edge

A raw asynchronous release lands at a random point in the clock period, so it violates one of the two windows with a probability roughly equal to the windows' combined width divided by the period. The sketch below works that share for illustrative numbers:

Diagram
illustrative share of releases landing in a forbidden window
recovery window 0.30 ns, removal window 0.15 ns, period 10 ns
share = (0.30 + 0.15) / 10 = 0.45 / 10 = 0.045 = 4.5% (illustrative)

A few percent of releases going metastable is catastrophic at chip scale: one bad release can corrupt a whole domain's starting state, and the failure never repeats the same way twice. The reset synchroniser converts the problem from a random-timed release into an ordinary clocked path, because the domain reset now changes only just after a clock edge of its own domain.

What signoff expects

  • Recovery and removal are timed like setup and hold on every flop with an asynchronous reset, across the operating corners.

  • The inter-stage path inside the synchroniser and the path from its output to the domain's flops are ordinary same-domain paths. The entry path (the asynchronous source into the first flop) is not: it needs its asynchronous exception plus a delay bound, reviewed with the CDC evidence.

  • Any flop whose reset bypasses the synchroniser keeps the raw-release hazard and must be justified or fixed; there is no statistical argument that makes a raw release acceptable.

Interview

State each window in one sentence: recovery means release early enough before the edge, removal means the release must not land just after the previous edge. Then say what the synchroniser changes: the release becomes a clocked event, so both windows are met by construction.

Check yourself With illustrative windows of 0.30 ns and 0.15 ns on a 10 ns clock, about what share of random releases violate a window?

About 4.5%: (0.30 + 0.15) / 10 = 0.045. The sketch above shows the arithmetic.

Check yourself After inserting a reset synchroniser, what kind of timing path is the reset release?

An ordinary flop-to-flop path on the domain clock, checked like any other synchronous path. That is the point of the synchroniser: no more randomly timed edge.

Related topics

  • Deassertion hazards

  • RTL: Reset Domain Crossing

Previous

65 / 179

Next: Deassertion Hazards

Up next

Up nextDeassertion Hazards

Sign in to save progress

Practice this lessonReport an error

See also

  • Why Deassertion Is the Hazard