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

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
    • Reset Architecture
    • Metastability and Synchronisation
    • Asynchronous FIFO
    • CDC Protocols
      • Choose a Protocol by Traffic Shape
      • 4-Phase Request/Acknowledge
      • Pulse Synchronisers and Event Toggles
      • Mux Recirculation for Multi-Bit Capture
      • CDC Handshake Checklist
    • Reset Domain Crossing
    • CDC Verification
  • Memory & Buses57
  • Advanced RTL28
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

←CDC Protocols
  1. Topics
  2. RTL Design
  3. Reset & CDC
  4. CDC Protocols
  5. CDC Handshake Checklist
On this page

    Part 6 of 9, lesson 22 of 34Part 6 of 9/Reset & CDC/Lesson 22 of 34Intermediate

    CDC Handshake Checklist

    A short list to review any control or data crossing built from the structures in this topic.

    Handshakes break most often when a reset lands mid-transfer: one side sees req stuck high, or an ack with no req. A review list makes every crossing show how it handles this and the other common failures.

    After this lesson you can: review a CDC crossing against the handshake checklist, including reset in mid-transfer and the timing constraints the crossing needs.

    Review list

    Every crossing should pass each row of the table. Each check names what to verify and why it matters.

    Check

    Why

    Every crossing signal is a single bit, a Gray-coded value, or a held-stable data bus

    Anything else can be sampled in a mixed state

    Each single-bit crossing has a 2FF (or more) with no logic between the flops and only the last flop used

    Settling time

    Control signals come directly from flops in the source domain

    No glitches at the synchroniser input

    Data is stable for the whole window in which the destination may capture it

    Hold time (handshake or counter) is stated and checked

    Open-loop pulse spacing has explicit clock/jitter/resolution assumptions, or events are acknowledged/counted/buffered

    A fixed two-period heuristic alone is not deterministic lossless delivery

    A busy/ready signal stops the source from starting a new transfer too early

    No overwriting

    Resets of both domains are consistent (see RDC)

    No stuck handshake after reset

    No handshake can deadlock: every state has an exit

    Include a timeout in robust designs

    Constraints are crossing-specific: scoped control exceptions, timed synchronizer stages, bundled-data arrival and Gray delay/skew bounds

    Inspect effective per-bit timing and exception precedence; clock groups plus structural CDC checking alone do not establish bus timing

    Testbench uses a metastability-aware model and a mutation (unstable data or too-short hold)

    Proves the test is sensitive

    For example, AMD documents that broad asynchronous clock groups override datapath-only maximum-delay exceptions. Use scoped exceptions that preserve the required bus checks and audit the implemented reports, not just the constraint text.

    Reset and recovery

    A reset in the middle of a transfer is where handshakes break most often. Define the safe state and test it directly.

    • If one domain is reset while a handshake is in flight, the other side may see req stuck high or an ack with no req. Define the safe state (both req and ack low) and reset both sides together.

    • Add a timeout or abort if the other side can disappear (a clock gated off, a domain powered down).

    • Test reset in the middle of a transfer; this is where handshakes break most often.

    Common mistakes

    Put each crossing in a named wrapper module (cdc_hs_word, cdc_pulse, cdc_bit) and keep the checklist next to it. Design reviews then check the wrapper once, and the rest of the design only instantiates it.

    Common question: “How do you know your CDC is safe?” Structural: every crossing is one of the approved structures. Functional: tests with a metastability model. Static: a CDC tool that classifies every crossing. Constraint: delay and skew bounds on the crossing paths.

    Check yourself A teammate wants to send a 4-bit enable word through four 2FFs because “the bits are independent”. When is that acceptable?

    Only if the bits are truly independent: no logic in the destination depends on two of them being consistent in the same cycle. If the four bits form a mode selection, sending them separately can produce an illegal combination for a cycle.

    • Define the safe state (req and ack low) and reset both sides together. Add a timeout if a clock can be gated or a domain powered down.

    • Constraints are crossing-specific. A broad clock group can override a datapath-only max-delay exception, so audit the implemented reports.

    • Show a crossing is safe in three layers: approved structures, tests with a metastability model, and a CDC tool that classifies every crossing.

    Rule of thumb: put each crossing in a named wrapper and keep the checklist next to it.

    • Practice: CDC handshake failure from early deassertion

    • Practice: Ack signal missed in an asynchronous handshake

    • Interview: run a mock interview on this topic

    Related topics

    • Next: Reset domain crossing

    Previous

    176 / 350

    Next: Reset Domain Crossing

    Up next

    Up nextReset Domain Crossing

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Choose a Protocol by Traffic Shape
    • 4-Phase Request/Acknowledge
    • Pulse Synchronisers and Event Toggles