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 Paths
  • Concept Map
  • Meet DCRouter
  • Glossary
  • Part 0: What Verification Is8
  • Part 1: What Can Go Wrong11
  • Part 2: Specifications as Checkable Rules8
  • Part 3: Observability and Controllability7
  • Part 4: Stimulus11
  • Part 5: Checking11
  • Part 6: Coverage10
  • Part 7: Formal and Simulation10
  • Part 8: Verification Levels and Reuse8
  • Part 9: Planning and Risk9
  • Part 10: Emulation and Prototyping8
  • Part 11: Post-Silicon Validation8
  • Part 12: Bug Economics8
  • Part 13: Debug7
  • Part 14: Sign-Off7
  • Part 15: Verification in Context8
    • Functional Safety Verification
    • Security Verification
    • Low-Power Verification Strategy
    • CDC and RDC in the Plan
    • Verifying Processors
    • Verifying AI Accelerators
    • Verifying Configurable IP
    • Drills: Verification in Context
  • Part 16: Case Studies5
  • Part 17: Capstones5
  • Part 18: Interview Preparation6
Loading lesson

‹Part 15: Verification in Context
  1. Topics
  2. First Principles of Verification Strategy
  3. Part 15: Verification in Context
  4. CDC and RDC in the Plan

Part 15 · Verification in Context · Senior (S)

CDC and RDC in the Plan

Signals crossing between clock domains, or between reset domains, can fail in ways RTL simulation does not model at all: metastability, reconvergence, glitches, partial resets. They are verified mainly by structural analysis, supported by assertions on the crossing protocols and targeted simulation. Why simulation is not enough, and how CDC and RDC fit into a verification plan.

On this page

    Note

    Level: Senior (S) · Answers: What changes for safety, security, processors and AI hardware?

    Before this: Low-Power Verification Strategy, Reset, Clock and Power Bugs

    DCRouter runs on one clock, which made every lesson in this course simpler. In a real SoC its APB register port might run on a slow peripheral clock while its packet ports run on a fast fabric clock. Every register value then crosses between clocks. In RTL simulation, the crossing works perfectly every time: the simulator moves a value from one flip-flop to another in zero time with no uncertainty. In silicon, a flip-flop sampling a signal that changes near its clock edge can go metastable, and two bits sampled separately can arrive in different cycles.

    Why isn't simulation enough for clock-domain crossings?

    The obvious answer, and why it breaks

    The obvious approach simulates the two clocks at different frequencies and checks the results. RTL simulation does not model metastability or the variable delay of a synchroniser; a missing synchroniser behaves perfectly in simulation, and a multi-bit bus crossing with no protocol looks fine because all bits arrive together. The failure lives in physics the simulator abstracts away, so the main verification method has to be structural.

    The idea: structure first, protocols second, simulation third

    Method

    What it checks

    Finds

    Structural CDC analysis

    Every signal crossing between clock domains: is it synchronised, and by an approved structure?

    Missing synchronisers, multi-bit buses crossed bit by bit, reconvergence of separately synchronised signals, glitch-prone logic before a synchroniser

    Protocol assertions on crossings

    Handshakes and FIFO pointers obey their rules (stable data while a request is pending; Gray-coded pointers change one bit at a time)

    Protocol misuse at synchronised crossings

    Simulation with metastability modelling

    Random extra or fewer cycles of delay on synchronised signals

    Logic that depends on exact crossing latency

    Structural RDC analysis

    Reset domains: asynchronous resets crossing domains, resets released at different times

    Registers left in inconsistent states by partial resets; glitches from reset assertion

    If DCRouter had two clocks

    • CTRL writes from the APB clock to the packet clock: synchronise as a multi-bit value with a handshake or a pulse-and-hold scheme, never bit by bit.

    • Counters read back (ERR_CNT, PKT_CNT): capture a stable snapshot in the packet domain, then cross it with a handshake.

    • sleeping and wake: single-bit level signals through two-flop synchronisers, with the wake latency now variable by a cycle; the R13 rules would need a bound of a few cycles instead of "next cycle".

    • The plan gains features for each crossing, a structural CDC sign-off criterion, and protocol assertions on the handshakes.

    CDC and RDC in the plan

    • A clock and reset architecture document listing domains and intended crossings.

    • Structural CDC and RDC analysis as a sign-off criterion, with every violation fixed or waived (lesson 14.3).

    • Assertions on every crossing protocol, run in simulation and formal.

    • Metastability-aware simulation for logic sensitive to crossing latency.

    • Re-run on every change to clocks, resets or crossing logic.

    How real teams verify crossings

    Practice

    Purpose

    CDC and RDC tools run on every RTL release

    Structural crossing bugs found before simulation

    Approved synchroniser and FIFO libraries

    Crossings built from verified structures

    Waivers for analysed crossings recorded and reviewed

    Exceptions owned, not ignored

    What breaks

    A team (illustrative) crossed a 4-bit configuration field between clocks with a two-flop synchroniser on each bit. Every simulation passed. In silicon, a write changing the field from 0111 to 1000 was occasionally seen for one cycle as 1111, because the bits resolved in different cycles, briefly selecting an illegal mode. A structural CDC check flags multi-bit crossings without a protocol on the first run.

    Why this matters

    Senior lens. Make structural CDC and RDC analysis a sign-off criterion, not an afterthought: list domains and crossings, build crossings from approved structures, put assertions on their protocols, and model crossing latency in simulation where logic depends on it. Simulation alone cannot see the failures that matter here.

    Interview

    Asked: "Why isn't simulation enough for CDC?"

    Weak answer: Because the clocks run at different frequencies.

    Strong answer: RTL simulation doesn't model metastability or the variable delay of a synchroniser, so a missing synchroniser or a multi-bit bus crossed bit by bit behaves perfectly in simulation and fails occasionally in silicon. CDC is verified mainly structurally: a tool checks every crossing is synchronised by an approved structure, flags multi-bit and reconvergent crossings and glitch-prone logic, with assertions on handshake and FIFO-pointer protocols and metastability-aware simulation where logic depends on exact latency. RDC analysis does the same for resets.

    Follow-ups: (1) What is reconvergence? (2) How would you cross a multi-bit counter?

    Check yourself Why does a multi-bit field synchronised bit by bit pass every simulation?

    The simulator delivers every bit in the same cycle; in silicon, bits can resolve in different cycles and produce a transient illegal value.

    Check yourself How would DCRouter's R13 wake rule change if in_vld crossed a clock boundary?

    Wake would arrive through a synchroniser with a cycle of uncertainty, so the rule would need a bound (within a few cycles) instead of "in the next cycle".

    Key takeaways

    • CDC and RDC failures live in physics RTL simulation does not model.

    • Verify crossings structurally first, then with protocol assertions and latency-aware simulation.

    • Make structural CDC and RDC analysis a sign-off criterion with owned waivers.

    Keep going

    Next: Lesson 15.5, Verifying Processors. ISA compliance, random instructions and lock-step comparison.

    Related topics

    • Part 15 overview: Verification in Context

    Previous

    140 / 160

    Next: Verifying Processors

    Up next

    Up nextVerifying Processors

    Sign in to save progress

    Practice this lessonReport an error

    See also

    • Functional Safety Verification
    • Security Verification
    • Verifying AI Accelerators