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. Symptoms to Causes

Part 5 · Reset Domain Crossing · All levels

Symptoms to Causes

A table from symptom (X after reset, stuck blocks, sporadic post-release failure, warm-reset state loss) to likely cause.

When a reset-domain bug bites, the fastest route to the cause is the symptom. Each classic symptom points at a small set of reset mechanisms; checking those first beats re-reading the data path. Confirm the guess with the smallest test that reproduces it, usually a reset at a chosen instant rather than a full rerun.

Symptom

Likely reset cause

First check

X after reset in simulation or on the bench

A flop or memory with no reset, or a reset that never reached it (gated clock off, missing synchroniser output)

Trace the X source back to its reset net; check the flop is on a live reset

One block stuck while neighbours run

Block still in reset (sequencer never released it, lost lock re-asserted), or waiting on a peer's ready flag

Read back the block's reset and ready flags; check the sequencer order

Sporadic failure just after release, never the same twice

Release violating recovery/removal on some boots; raw or gated release path

Inspect the release path for a synchroniser and combinational logic; sweep the release instant

State loss on warm reset (config gone, link dead)

Warm reset clearing registers it should preserve, or keeping protocol state the partner forgot

Diff the cleared-versus-preserved list against the spec for that reset kind

Duplicate or stale words after a one-sided reset

Interrupted handshake without protocol tolerance; reset values sampled as data

Check isolation plus the armed/qualify logic on the crossing

Notice the pattern: the first two symptoms are about reset not doing its job (reach and order), the next two about reset doing too much or at the wrong time (release timing, over-clearing), and the last about the crossing protocol meeting a reset halfway. Naming which of the three classes the symptom belongs to halves the search space before any waveform is opened.

Tip

Reproduce with intent: assert and release each reset at several instants across the clock cycle, reset one side only, and release in the wrong order on purpose. A bug that needs a specific misalignment never appears in a test that always does the tidy thing.

Check yourself A block works after power-up but wedges after a warm reset, with its configuration registers reading defaults. Which class of cause?

Over-clearing: the warm reset clears registers it should preserve. Compare the reset's cleared-versus-preserved list against the spec for warm reset.

Check yourself Failures appear only on some boots, always shortly after reset release. What is the first structure to inspect?

The release path: look for a missing synchroniser or combinational logic on the reset net, then sweep the release instant to confirm the timing dependence.

Related topics

  • Glitchy reset release

  • Partial reset states

Previous

75 / 179

Next: Glitchy Reset Release

Up next

Up nextGlitchy Reset Release

Sign in to save progress

Practice this lessonReport an error

See also

  • Partial Reset States
  • Debug Checklist