Clock domain crossing: which synchronizer to choose, and why
RTL Design · InterviewPS team · 30 October 2026
In short
Choose the synchronizer from what crosses: a single-bit level signal uses a two-flop synchronizer, a multi-bit value that changes rarely uses a handshake, a counter uses gray code, and a stream of data uses an asynchronous FIFO with gray-coded pointers. Never synchronize the bits of a bus one by one, because each bit can resolve on a different cycle and the receiver sees a value that never existed.
Start with the problem: metastability
When a flip-flop samples a signal that changes too close to its clock edge, it can go metastable: its output hangs between 0 and 1 for an unpredictable time before settling. You cannot prevent this when two clocks are unrelated. You can only give the flop enough time to resolve before anything else uses its output, so that a failure becomes very unlikely.
That likelihood is measured as mean time between failures. MTBF grows exponentially with the resolution time you allow, which is why adding one more flop stage raises it so sharply. Interviewers like to hear that MTBF also falls as the clock and data rates rise, so a synchronizer that is safe at a low frequency may not be safe at a higher one.
The four common schemes
What crosses
Scheme
Why it works
One bit, held long enough
Two-flop synchronizer
The first flop may go metastable; the second gives it a full cycle to resolve
A multi-bit value that changes rarely
Request/acknowledge handshake
The data is held stable while a single synchronized control bit says it is ready
A counter or pointer
Gray code, then synchronize
Only one bit changes per step, so a late bit gives the old or new value, never a wrong one
A stream of data
Asynchronous FIFO
Data sits in memory; only gray-coded read and write pointers cross
A short pulse from a fast domain needs extra care, since it can be shorter than one period of the slow clock and disappear. A common fix is to turn the pulse into a level change (a toggle) in the source domain, synchronize the toggle, and detect its edge in the destination.
The follow-ups to expect
- •"Why not synchronize each bit of a bus?" Each bit resolves independently, so for one cycle the receiver can see a mix of old and new bits, a value that was never sent.
- •"How many flops?" Two is the usual minimum. Designs with fast clocks or strict reliability targets use three. Justify the choice with MTBF, not habit.
- •"What constraints go on the crossing?" The synchronizer's first flop must not be timed as an ordinary path between the clocks. But a blanket false path can hide a real problem on a gray-coded bus, where the bits must arrive close together. A delay limit on the crossing is safer than ignoring it.
- •"How do you know the design is clean?" Structural CDC checking finds unsynchronized crossings and convergence of synchronized signals. Assertions check the protocol, for example that handshake data stays stable until acknowledged.
What a senior answer adds
A junior answer names the two-flop synchronizer. A senior answer starts from the traffic: how often the value changes, how wide it is, how fast each clock runs, and whether data may be lost. It also mentions reconvergence, where two separately synchronized signals are combined in the destination domain and may arrive a cycle apart, and reset crossings (RDC), where an asynchronous reset is released in a different domain.
Mistakes that cost candidates the question
- •Saying a two-flop synchronizer "removes" metastability. It makes failure unlikely; it does not make it impossible.
- •Using a two-flop synchronizer on a multi-bit bus.
- •Forgetting that a pulse from a fast domain can be missed entirely by a slow clock.
- •Treating the crossing as a false path without thinking about skew between the bits of a gray-coded bus.
Sources
- R. Ginosar, "Metastability and Synchronizers: A Tutorial", IEEE Design & Test of Computers, 28(5), 2011