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
    • Reset Sequencing
    • RDC Structural Checks
    • Reset Debug Playbook
      • Symptoms to Causes
      • Glitchy Reset Release
      • Partial Reset States
      • Debug Checklist
  • 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 Debug Playbook
  1. Topics
  2. CDC & RDC
  3. Reset Domain Crossing
  4. Reset Debug Playbook
  5. Partial Reset States

Part 5 · Reset Domain Crossing · All levels

Partial Reset States

Domains reset at different times leaving inconsistent state: how to find it and how to prevent it.

A partial reset is any reset that clears some of a conversation while the rest keeps going: one domain of a handshake, one side of a credit scheme, the pointers but not the memory, the control but not the status the software polls. The cleared half restarts from idle; the surviving half resumes mid-dialogue. Everything after that is two sides speaking different protocols.

Finding it starts from the inconsistency, not the reset. Two pointers that should be equal are not; a credit count the two sides disagree on; a “valid” the receiver never sent paired with data the sender never meant. From the mismatched pair, walk each signal back to its reset net and list which resets clear which half: the reset that touches exactly one half is the partial one.

Prevention patterns

  • Reset protocol groups together: both sides of a handshake, both pointers plus the FIFO control, credits on both sides, or neither side resets while traffic can be live.

  • Where joint reset is impossible, give the surviving side a re-sync event: the reset domain's release raises a flag the neighbour treats as “peer restarted, return to idle”, the same armed-flag idea as the tolerant handshake.

  • Quiesce before resetting: stop new traffic, drain what is in flight, then reset. A reset that lands on an idle link has nothing to disagree about afterwards.

  • Make the reset scope reviewable: one table per reset listing every register it clears, so a partial reset of a protocol group is visible on paper before it ships.

Common pitfall

Resetting FIFO pointers without the associated control (or vice versa) builds a FIFO that believes it is both full and empty. Pointer, full/empty, and count logic are one reset group, never separate ones.

Check yourself After a one-sided reset, a handshake sender waits forever for an acknowledge the receiver believes it already sent. What happened?

Partial reset of a protocol group: the receiver's state was cleared while the sender kept its waiting state. Either reset both sides together or give the receiver a re-sync that returns the pair to idle.

Check yourself Why does quiescing before reset prevent partial-reset inconsistency?

With no transfer in flight and all wires at idle values, neither side holds state the other must match after release. The reset then starts both halves from a mutually known point instead of interrupting a dialogue.

Related topics

  • Symptoms to causes

  • Reset isolation

Previous

77 / 179

Next: Debug Checklist

Up next

Up nextDebug Checklist

Sign in to save progress

Practice this lessonReport an error

See also

  • Symptoms to Causes