Clock Domain Crossing & Reset
The CDC and reset questions that dominate DV interviews: why metastability happens and how a two-flop synchronizer tames it, pulse and multi-bit crossings with Gray code and handshakes, async FIFOs, reset synchronizers (async assert / sync deassert), reset domain crossing, and how to actually verify all of it.
By the end you can
- Explain metastability and size a synchronizer for it
- Cross single-bit, pulse and multi-bit signals safely
- Build an async FIFO with Gray-coded pointers
- Apply correct reset synchronization and verify CDC
0 / 8 assignments done
Move each assignment through the stages — progress saves automatically.
Metastability & single-bit synchronization
0/2Why crossing clocks is dangerous, and the two-flop and pulse synchronizers that make single-bit crossings safe.
Two-flop synchronizer and metastability
Build a two-flop synchronizer for a single-bit control signal crossing from clock A to clock B. Explain what metastability is, why two flops help, and how MTBF depends on the second flop's settling time.
Requirements
- Two back-to-back flops in the destination domain
- The first flop's output never used directly
- A written explanation of metastability and MTBF factors
- A note on when two flops isn't enough (high freq)
You'll be able to
- Explain metastability and the 2-FF fix
- Reason about MTBF and synchronizer depth
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Pulse synchronizer across clock domains
A single-cycle pulse in a fast domain must produce exactly one pulse in a slower domain. Build a toggle-based pulse synchronizer and explain why directly synchronizing the pulse can miss or duplicate it.
Requirements
- Toggle in the source domain on each pulse
- Two-flop sync of the toggle in the destination
- Edge-detect in the destination to regenerate one pulse
- Correct behavior when the pulse is narrower than the dest clock
You'll be able to
- Cross events without losing or duplicating them
- Explain why level/toggle beats raw pulse crossing
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Multi-bit CDC & async FIFO
0/3Buses can't use a plain synchronizer — cross them with Gray code, a handshake (MCP), or an async FIFO.
Gray-code counter crossing
Cross a counter value between domains using Gray code so that at most one bit changes per step (avoiding multi-bit skew). Convert binary→Gray in the source and Gray→binary in the destination after synchronizing.
Requirements
- Binary-to-Gray and Gray-to-binary conversion
- Only the Gray value crosses (through 2-FF sync)
- Correct value on the destination side
- An explanation of why multi-bit binary can't cross directly
You'll be able to
- Use Gray code to cross a counter safely
- Explain the multi-bit skew problem
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Handshake (MCP) data crossing
Cross a multi-bit data word using a request/acknowledge handshake (multi-cycle path formulation): hold the data stable, cross a request, wait for the synchronized acknowledge, then release. Explain the throughput cost.
Requirements
- Data held stable while the req/ack handshake completes
- req and ack each crossed with a 2-FF synchronizer
- No new data launched until ack returns
- A note on the latency/throughput trade-off
You'll be able to
- Cross arbitrary data with a handshake
- Reason about MCP latency vs an async FIFO
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Async FIFO with Gray-coded pointers
Build a dual-clock (asynchronous) FIFO: dual-port RAM, Gray-coded read/write pointers synchronized into the opposite domain, and full/empty generated from the synchronized pointers. This is the workhorse for streaming across clocks.
Requirements
- Separate read and write clocks
- Gray-coded pointers crossed with 2-FF synchronizers
- full computed in the write domain, empty in the read domain
- No metastable multi-bit pointer values used directly
You'll be able to
- Implement the canonical async FIFO
- Generate full/empty from crossed Gray pointers
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Reset & CDC verification
0/3Reset done right — async assert, sync deassert — the reset-domain-crossing hazard, and how to verify CDC structurally and dynamically.
Reset synchronizer: async assert, sync deassert
Build a reset synchronizer that asserts reset immediately (asynchronously) but deasserts it synchronously to a clock, so no flop leaves reset within a setup/hold window. Explain the removal/recovery timing problem it solves.
Requirements
- Asynchronous assertion of reset
- Synchronous, metastability-safe deassertion (2 flops)
- One synchronizer per clock domain
- A note on recovery/removal timing
You'll be able to
- Apply the async-assert/sync-deassert pattern
- Explain reset recovery/removal checks
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Reset domain crossing (RDC) hazards
Identify a reset-domain-crossing hazard: a flop reset by reset A drives a flop reset by reset B, and A can assert while B's clock is running. Explain the corruption risk and a mitigation (e.g. isolation or a common ordered reset).
Requirements
- A concrete RDC example between two reset domains
- The failure explained (spurious value captured on the far side)
- A mitigation strategy described
- A note on why static CDC tools flag RDC separately
You'll be able to
- Recognize reset-domain-crossing bugs
- Propose an RDC mitigation
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Verifying CDC: assertions and a review checklist
Put together how CDC is verified: a structural review (every crossing has a synchronizer, no combinational logic between crossing flops), plus dynamic assertions (data stable across the crossing, one-bit-change on Gray buses). Produce a short CDC checklist.
Requirements
- A structural checklist (synchronizer present, no comb logic in the path)
- A stability assertion for a handshake-crossed bus
- A one-hot/one-change check for a Gray-coded crossing
- A note on why static CDC analysis complements simulation
You'll be able to
- Combine static and dynamic CDC verification
- Write CDC stability/robustness checks
Submitting your solution link marks this assignment done.
A full worked solution with a step-by-step walkthrough — included with the domain pack and All-Access. Try it yourself first.
Put it to work
Drill the matching interview questions, then see where this module sits in the full Design Verification roadmap.