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
      • What Is an RDC Crossing
      • RDC Categories
      • Reset Ordering Violations
      • Reading RDC Findings
    • 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

‹RDC Structural Checks
  1. Topics
  2. CDC & RDC
  3. Reset Domain Crossing
  4. RDC Structural Checks
  5. Reset Ordering Violations

Part 5 · Reset Domain Crossing · All levels

Reset Ordering Violations

Findings caused by release order: what they mean and how to read and clear them.

Some findings are not about missing circuits but about time: the structure is correct, yet analysis shows a domain can start operating before a domain it depends on is ready. A producer released before its consumer, a sender before its receiver's ready flag, or a user of a memory before the controller has left reset.

These findings read differently from structural ones. There is no gate to add; the fix is a sequencing change, a ready flag, or a documented guarantee that the early traffic is harmless (for example, the consumer ignores everything until its own enable, and that ignore path is itself verified).

How to read an ordering finding

  1. Identify the two domains and the dependency direction: who must be ready before whom, and what flows between them.

  2. Check the sequencer or the ready flags: is there any mechanism at all, or did both domains simply release on their own clocks?

  3. If a mechanism exists, check it covers this pair: a global sequencer with the wrong order for this interface, or a ready flag the sender never waits on, still fails.

  4. Clear it by fixing the order (sequencer), adding the handshake (ready flag), or proving harmlessness with a test that releases in the worst order and checks the traffic.

Common pitfall

Proving harmlessness needs the adversarial test, not the nominal one. Releasing in the designed order and observing success says nothing about the violation, which is precisely about other orders. Stagger the releases the wrong way on purpose and check that nothing is lost or duplicated.

Check yourself The structure has per-domain synchronisers and isolation, yet an ordering finding is reported on a producer/consumer pair. What is missing?

Sequencing: nothing orders the two releases or makes the producer wait for the consumer's readiness. Synchronisers align each release to its clock; they do not order the pair.

Check yourself What test clears an ordering finding by proof rather than by a design change?

A test that releases the domains in the worst order the design permits and checks the traffic is complete and unduplicated. Passing only in the nominal order proves nothing about the finding.

Related topics

  • Reading RDC findings

  • Release order across domains

Previous

73 / 179

Next: Reading RDC Findings

Up next

Up nextReading RDC Findings

Sign in to save progress

Practice this lessonReport an error

See also

  • What Is an RDC Crossing