Electronics Guide

Types of Clock Relationships

Clock domains can have several relationships that affect synchronization requirements:

Synchronous clocks share a common source and maintain a fixed phase relationship. While separate domains, their predictable timing allows simplified synchronization approaches, though care is still needed due to clock skew and jitter.

Asynchronous clocks have no guaranteed phase relationship. They may come from independent oscillators or be derived through different PLLs. These truly asynchronous relationships require robust synchronization techniques because data transitions can occur at any point relative to the sampling clock.

Mesochronous clocks have identical frequencies but unknown or varying phase relationships. This situation often occurs when the same clock is distributed to different chips or board regions with different propagation delays. The constant frequency simplifies some aspects of synchronization while still requiring attention to phase uncertainty.

Plesiochronous clocks have nearly but not exactly equal frequencies. Small frequency differences cause the phase relationship to drift over time, requiring synchronization schemes that accommodate gradual timing drift.

CDC Challenges

Clock domain crossings introduce several challenges that synchronization techniques must address:

• Metastability when signals change during the sampling window of the destination clock
• Data coherence when multiple related signals cross together but may be sampled at different times
• Reconvergence when a single source signal takes multiple paths and arrives at the destination at different times
• Protocol synchronization when handshaking signals must cross both directions between domains
• Performance impact from latency introduced by synchronization stages

The Physics of Metastability

Every bistable element has three equilibrium points: two stable states and one unstable balance point between them. In normal operation, the regenerative feedback within the flip-flop rapidly drives the internal voltages toward one stable state or the other. When data transitions occur at the precise moment of sampling, the flip-flop may settle near the unstable equilibrium.

From this metastable condition, thermal noise and internal asymmetries gradually push the flip-flop toward a stable state. The resolution follows an exponential probability distribution characterized by a time constant τ that depends on the flip-flop's internal gain and transistor characteristics. The probability that the element remains unresolved falls by a factor of e for every further τ of settling time, so the resolution time is formally unbounded and merely grows very improbable as time passes.

The metastable output voltage sits at an intermediate level that may propagate through downstream logic, causing unpredictable behavior. Different logic gates interpret this intermediate voltage differently, potentially creating glitches, oscillations, or incorrect logic decisions that corrupt system state.

Metastability Parameters

Flip-flop metastability characteristics are described by several key parameters:

Resolution time constant (τ): The exponential time constant describing how quickly the flip-flop exits the metastable state. It is set by the regenerative loop gain and bandwidth of the bistable element, so its value is strongly technology-dependent: modern processes and dedicated synchronizer cells reach time constants of tens of picoseconds or below, while slower or older standard-cell flip-flops resolve more sluggishly. A smaller τ is better, and because τ sits in an exponent it outweighs every other term in the reliability calculation. The designer does not set τ by changing the circuit. It is a property of the library cell or of the FPGA fabric, so the only lever is to choose a different cell, a faster library, or a different device, and its value degrades at low supply voltage and high temperature along with every other timing parameter.

Metastability window (T₀): A fitted constant with units of time that scales how often metastability arises. The aperture around the clock edge within which a data transition leaves the flip-flop unresolved for longer than t measures T₀exp(−t/τ), so T₀ is that aperture extrapolated back to zero resolution time rather than a window anyone observes directly. It relates to, but differs from, the setup-and-hold window specified for reliable data capture. Vendors characterize T₀ and τ together by measurement, and FPGA timing tools carry the pair internally and report synchronizer MTBF from them.

Setup time (t_su) and hold time (t_h): The timing constraints that define when data must be stable for guaranteed correct capture. Operating within these bounds prevents metastability; operating outside them allows metastability to occur.

Mean Time Between Failures

Mean time between failures (MTBF) quantifies synchronizer reliability by predicting the average time between metastability events that propagate as downstream failures. For a signal captured by a synchronizer flip-flop:

MTBF = exp(t_r/τ)/(T₀f_clkf_data)

Here t_r is the resolution time the circuit actually allows, f_clk is the destination clock frequency, and f_data is the rate at which the incoming signal changes. The resolution time is not the whole clock period, and the difference matters. In a two-flip-flop synchronizer it is one destination clock period less the setup time of the second flip-flop, less the clock-to-output delay of the first, and less any interconnect delay between them. Those subtractions explain why the two flip-flops sit adjacent to one another and why no combinational logic may come between them: every picosecond spent on wiring is a picosecond taken out of the exponent. The equation reveals several things at once:

• MTBF increases exponentially with available resolution time
• Higher clock and data frequencies proportionally reduce MTBF
• Flip-flops with a smaller τ provide exponentially better MTBF
• Each added stage extends the resolution time by one clock period, multiplying MTBF by exp(T_clk/τ)

Working the numbers shows how lopsided the equation is. Take a flip-flop characterized by τ = 20 picoseconds and T₀ = 20 picoseconds, a 100 MHz destination clock, and an input that changes 1 million times per second. One clock period of resolution time makes the exponent 10 nanoseconds divided by 20 picoseconds, or 500, while the denominator T₀f_clkf_data comes to 2,000 per second. The MTBF is then of the order of 10²⁰⁶ years, a figure with no meaning beyond never.

Now double the clock to 200 MHz. The denominator doubles, costing one factor of two, but the resolution time halves to 5 nanoseconds and the exponent falls from 500 to 250. The MTBF drops to roughly 10⁹⁷ years. Doubling the clock cost about 109 orders of magnitude, and the linear term contributed 0.3 of them. MTBF falls almost exponentially with the clock period and only linearly with the two frequencies, which is why a synchronizer that is comfortable at 100 MHz deserves rechecking rather than scaling when the clock reaches 1 GHz. Push that same flip-flop to a 1 GHz clock with data changing at 100 MHz and the MTBF falls to the order of tens of thousands of years, which is where the calculation stops being a formality.

Design targets sit far above the service life of one product, because the deployed fleet multiplies the failure rate. A single unit whose synchronizer has a 1,000-year MTBF will almost certainly never fail. A million such units produce a metastability failure somewhere in the field roughly every nine hours. The target therefore follows from the number of units shipped, the hours they run, and the cost of a failure, not from the lifetime of one board. Aerospace, medical, and nuclear systems set the highest targets because a failure costs the most there, not because their boards last longer.

Two-Flip-Flop Synchronizer

The two-flip-flop synchronizer (also called a two-stage or double-flop synchronizer) passes an asynchronous signal through two destination-clock flip-flops before the signal reaches any combinational logic. The first flip-flop may go metastable when sampling the asynchronous input, but the second flip-flop provides a full clock period for the first to resolve before its output affects the rest of the system.

Each stage added to the chain extends the time available for resolution by one destination clock period, which multiplies the MTBF by exp(T_clk/τ). The result is commonly stated more loosely as squaring the MTBF of a single stage. The shorthand is close enough numerically, because the correction is only the factor T₀f_clkf_data, but it is not exact, and the square of a time is not a time. The exponential factor is the exact statement. For ordinary flip-flops at moderate clock rates that factor is astronomically large, so two stages carry the MTBF far past any system lifetime, which is why the two-flip-flop synchronizer is the default rather than a compromise.

The two-flip-flop synchronizer solves exactly one problem: it makes metastability on a single bit improbable. It does not make the bit's arrival time predictable, and two limits follow directly. A multi-bit value must never cross through one synchronizer per bit, because the individual synchronizers may resolve on different clock cycles and hand the destination a combination that never existed in the source domain. A pulse shorter than the destination clock period may fall between two sampling edges and vanish, which is the usual outcome when a pulse crosses from a fast domain into a slow one. Both cases call for the techniques described under multi-bit synchronization and pulse synchronizers below, and neither is fixed by adding stages. A design that reaches for two flip-flops without checking which of the two limits applies is the most common way a crossing that passes review still fails in hardware.

Critical design considerations for two-flip-flop synchronizers include:

• Both flip-flops must be clocked by the destination clock only
• No combinational logic should exist between the synchronizer flip-flops
• The flip-flops should be placed physically close together to minimize interconnect delay
• Use flip-flops optimized for metastability (if available in the cell library)
• Ensure the synthesized or placed design maintains these constraints

Three-Flip-Flop Synchronizer

Adding a third flip-flop stage further increases MTBF at the cost of one additional clock cycle of latency. Three-stage synchronizers are appropriate for:

• Very high-frequency designs where resolution time is limited
• Safety-critical applications requiring extremely high MTBF
• Systems using flip-flops with poor metastability characteristics
• Designs operating across wide temperature and voltage ranges

Returns do not actually diminish beyond three stages: every extra flip-flop multiplies the MTBF by the same large exponential factor. What stops the designer is that two or three stages already carry the MTBF far past any stated requirement, so a fourth buys nothing measurable and costs another cycle of latency. If three stages still fall short, the resolution time per stage is too small for the flip-flop in question, and the remedy is a slower crossing, a better cell, or a different architecture rather than a longer chain.

Synchronizer Timing

The synchronizer adds latency to the signal path, typically two to three clock cycles depending on the number of stages. This latency must be accounted for in system timing analysis and protocol design.

The synchronized output reflects the input state from several clock cycles earlier. Fast-changing inputs are filtered, and narrow pulses are missed entirely. To guarantee that the destination sees at least one sampling edge with the signal stable, a level must be held longer than one full destination clock period plus the setup-and-hold aperture of the first stage. Designers commonly require two destination clock periods, which leaves margin for clock jitter and for the frequency tolerance between the two domains. A source that cannot hold its signal that long needs a pulse synchronizer rather than a plain one.

Four-Phase Handshake

The four-phase (or level-sensitive) handshake uses two control signals: a request from the sender and an acknowledge from the receiver. The protocol proceeds through four distinct phases:

1. Request assertion: The sender places valid data on the data bus and asserts the request signal high
2. Acknowledge assertion: The receiver detects the request (after synchronization), captures the data, and asserts acknowledge high
3. Request deassertion: The sender sees the acknowledge, knows the data was received, and deasserts request low
4. Acknowledge deassertion: The receiver sees request go low and deasserts acknowledge, completing the cycle

This return-to-zero protocol is robust and simple to implement. Each signal transition provides an event that the other side can detect and respond to. The protocol works correctly regardless of the relative clock frequencies because each side waits for the other's response.

The four-phase handshake requires multiple clock cycles for each data transfer, making it unsuitable for high-throughput applications. However, its simplicity and robustness make it appropriate for control signals, configuration data, and moderate-bandwidth interfaces.

Two-Phase Handshake

The two-phase (or transition-sensitive) handshake improves throughput by signaling with transitions rather than levels. Request and acknowledge signal by toggling rather than asserting and deasserting, halving the number of transitions per transfer.

1. Request transition: The sender places valid data and toggles the request signal
2. Acknowledge transition: The receiver detects the request change, captures data, and toggles acknowledge

This non-return-to-zero protocol doubles throughput compared to four-phase handshaking. However, it requires edge detection or toggle tracking on both sides, adding some complexity. The receiver must remember the previous state of the request signal to detect changes.

Handshake Implementation

Implementing a handshake requires synchronizers for both the request and acknowledge paths, as these signals cross between clock domains. The sender synchronizes the acknowledge signal to its clock, and the receiver synchronizes the request signal to its clock.

Data signals in handshake transfers can often avoid synchronization because the handshake protocol ensures data is stable when sampled. The sender holds data stable from request assertion until acknowledge is received. The receiver samples data only after detecting the synchronized request, by which time the data has been stable for multiple clock cycles.

This approach requires careful design to ensure data setup time is met relative to when the receiver samples. For wide data buses, slight skew between data bits is acceptable because the handshake guarantees all bits are stable when sampled.

FIFO Architecture

An asynchronous FIFO consists of a dual-port memory with independent read and write ports, each operating in its own clock domain. The write side pushes data into the FIFO when space is available, while the read side pops data when the FIFO is not empty. Address pointers track the write and read positions within the circular buffer.

The key challenge is generating reliable full and empty status signals when the write and read pointers exist in different clock domains. Comparing pointers requires crossing between domains, which is where Gray code encoding becomes essential.

The FIFO depth must accommodate the maximum expected difference between write and read rates. Insufficient depth causes overflow (data loss) or underflow (invalid data reads), while excessive depth wastes memory resources. Proper depth selection requires understanding the data burst characteristics and rate variations of both sides.

Gray Code Counters

Gray code is essential for asynchronous FIFO design because only one bit changes between adjacent values. This single-bit-change property eliminates the possibility of sampling multiple bits at different times and obtaining a completely wrong value.

With binary counters, a transition like 7 to 8 (0111 to 1000) changes all four bits simultaneously. If some bits are sampled before the transition and others after, the result could be any value from 0 to 15. This error would cause incorrect full/empty detection and potential data corruption.

Gray code eliminates this problem. The sequence 7 to 8 in 4-bit Gray code is 0100 to 1100, changing only the MSB. Any sampling during this transition yields either 0100 or 1100, both valid adjacent states. The worst case is reading the old or new value, not an arbitrary incorrect value.

The FIFO maintains write and read pointers in binary for addressing the memory, then converts them to Gray code for crossing between clock domains. The receiving side synchronizes the Gray-coded pointer and may convert back to binary if needed for comparison, though Gray code comparison is also possible.

Full and Empty Detection

The FIFO is empty when the read pointer equals the write pointer, indicating no data is available. The FIFO is full when the write pointer has wrapped around and is about to overtake the read pointer, meaning no space remains for new data.

For empty detection, the read side compares its local read pointer with the synchronized write pointer. Because of synchronization latency, the synchronized write pointer may lag the actual write pointer, potentially indicating empty when data is actually available. This conservative approach is safe, causing no data corruption though potentially reducing throughput.

For full detection, the write side compares its local write pointer with the synchronized read pointer. The synchronized read pointer may lag the actual read pointer, potentially indicating full when space is actually available. Again, this conservative approach prevents overflow at the cost of potential throughput reduction.

Distinguishing full from empty requires one pointer bit beyond those needed to address the memory, so that a pointer one full lap ahead is distinguishable from one in the same place. With binary pointers the rule is simple: empty when the two pointers match in every bit, full when they differ in the extra most significant bit alone.

That rule does not survive conversion to Gray code, and the mistake is easy to carry across. A Gray-coded pointer one lap ahead differs from its counterpart in the top two bits, not the top one. In a FIFO of depth eight with four-bit pointers, a write pointer of binary 1000 and a read pointer of binary 0000 are Gray-coded as 1100 and 0000. The full test therefore reads: full when the two most significant bits of the write pointer are the complements of the two most significant bits of the synchronized read pointer and all remaining bits are equal. Empty stays a plain equality, because Gray coding is a bijection and preserves it.

FIFO Design Considerations

Several factors influence asynchronous FIFO design:

• Depth selection: Must accommodate burst sizes and rate mismatches while minimizing memory usage
• Power of two depth: Simplifies Gray code implementation and pointer comparison
• Almost full/empty flags: Provide early warning to prevent stalls or overflows
• Reset synchronization: Both sides must enter reset state safely and exit coordinated
• Memory type: Register-based for small FIFOs, SRAM-based for larger depths
• Latency: Synchronization stages add cycles between data written and available for reading

The Multi-Bit Problem

Consider synchronizing an 8-bit bus that transitions from 0xFF to 0x00. Each bit uses its own synchronizer. Due to slight timing differences, some bits might sample the old value while others sample the new. The receiver could see any value from 0x00 to 0xFF, including values like 0x0F or 0xF0 that never existed on the bus.

This problem affects any group of signals that must maintain a consistent relationship. Bus values, control signal groups, and state machine encodings all require coherent synchronization to prevent transient invalid values.

Gray Code for Data

As used in FIFO pointers, Gray code ensures that multi-bit values change only one bit at a time. When the data naturally represents a counter or has sequential semantics, Gray coding provides a simple solution. The worst case is reading the value immediately before or after the current value, both valid states.

Gray code is inappropriate for arbitrary data patterns. Converting to Gray code and back adds logic and latency, and the technique only works for incrementing or decrementing sequences. For general data, other approaches are necessary.

Handshake-Based Synchronization

Handshaking protocols naturally handle multi-bit data by ensuring data is stable before and during sampling. The sender holds all data bits constant while asserting the request, and the receiver samples all bits simultaneously after synchronizing the request. No per-bit synchronization is needed because the handshake guarantees data stability.

This approach trades throughput for simplicity and reliability. Each transfer requires multiple clock cycles for the handshake, but any width of data can be transferred coherently without additional complexity.

MUX Recirculation

MUX recirculation uses a synchronized control signal to select between old and new data values. The destination domain flip-flops recirculate their current values until the synchronized control indicates that new source data is stable and ready. At that point, all destination flip-flops capture the new value simultaneously.

This technique requires only one synchronizer (for the control signal) rather than one per data bit. The control signal indicates when the source data has been stable for sufficient time to ensure clean capture. The destination samples all bits at once using its local clock, avoiding coherence issues.

FIFO-Based Transfer

Asynchronous FIFOs provide the most robust solution for multi-bit data transfer. The FIFO naturally maintains coherence because each memory location stores a complete data word that is written atomically in the source domain and read atomically in the destination domain.

FIFOs add latency and resource overhead compared to simpler techniques but provide the highest throughput for continuous data streams. They also buffer rate differences, making them suitable for interfaces where source and destination rates vary.

Structural Analysis

CDC verification tools perform structural analysis to identify signals that cross between clock domains and verify that appropriate synchronization exists. The tools trace signal paths through the netlist, flagging crossings that lack synchronizers or use incorrect synchronization patterns.

Structural checks verify that:

• All signals crossing between domains pass through synchronizers
• Synchronizers have the correct number of stages
• No combinational logic exists between synchronizer stages
• Multi-bit buses use appropriate synchronization schemes
• Reconvergent paths are properly handled

Functional Verification

Structural analysis ensures synchronizers exist but cannot verify correct behavior. Functional verification tests the system's response to various CDC timing scenarios using simulation or formal methods.

Simulation-based verification requires modeling synchronizer behavior including metastability effects. Some simulators can inject random delays in synchronizers to stress test the design. Lengthy simulations with realistic data patterns help uncover CDC protocol issues.

Formal verification can prove CDC protocol correctness by exhaustively analyzing all possible timing scenarios. Formal CDC tools verify handshake protocols, FIFO pointer relationships, and data stability requirements without requiring simulation vectors.

CDC Constraints

CDC analysis needs accurate clock domain definitions before it reports anything useful. Designers must declare which clocks are asynchronous to one another, which share a source, and which signals change so rarely that they need no synchronizer, so that the tool neither misses a real crossing nor buries its report under false violations.

Synthesis and static timing analysis need a separate declaration, and the choice among the available forms matters more than it first appears. A truly asynchronous crossing offers no phase relationship for the timing tool to check, so the path must come out of ordinary setup and hold analysis. Declaring it a false path removes it completely, which also releases the tool from any obligation to keep the path short. For a single control bit entering a two-flip-flop synchronizer that consequence is harmless. For a data bus whose correctness depends on arriving no later than the control signal that announces it, the consequence is a design that captures stale data. AMD's Vivado guidance accordingly advises against a blanket false path and recommends bounding such crossings with a maximum-delay constraint applied to the data path only, so that the physical delay stays inside a known bound while the clock relationship is ignored, together with a bus-skew constraint that bounds the spread between the bits of a multi-bit crossing.

Synchronizer flip-flops also need protection from the optimizer, which is otherwise free to merge, replicate, or retime them. Vendor attributes exist for this, ASYNC_REG in Vivado being the common example. The attribute keeps synthesis from restructuring the chain, directs the placer to keep the stages together so that interconnect delay does not eat into the resolution time, and makes gate-level simulation hold the previous value on a timing violation rather than propagate an unknown through the design.

An unconstrained crossing is the defect that survives every stage of review. Register-transfer simulation shows nothing, because a zero-delay model never goes metastable. Static timing analysis either reports a violation that somebody waives as spurious or reports nothing at all, because the clocks were declared unrelated. The failure appears first in hardware, intermittently, and often on one unit out of a batch, which is the most expensive place and time to find it.

Common CDC constraints include:

• Clock group declarations identifying which domains are asynchronous to one another
• Synchronizer recognition attributes so that tools identify and protect the chains
• Maximum-delay constraints on the data path of each crossing, in preference to blanket false paths
• Bus-skew constraints bounding the spread between the bits of a multi-bit crossing
• Quasi-static signal identification for rarely changing configuration signals
• Gray code path identification for FIFO pointers

Pulse Synchronizers

When a signal in the source domain is a brief pulse rather than a level, standard synchronization may miss the pulse entirely if it is shorter than the destination clock period. Pulse synchronizers convert pulses to level changes, synchronize the level, then detect the edge to regenerate a pulse in the destination domain.

The source domain toggle flip-flop converts each input pulse to a level transition. This transition is synchronized to the destination domain using a standard two-flip-flop synchronizer. An edge detector in the destination domain generates an output pulse for each transition, effectively recreating the original pulse events.

The toggle form runs open loop and carries no acknowledgment, so it imposes a minimum spacing on its input: successive pulses must be separated by at least two destination clock periods, or the second toggle arrives before the first has been observed and the pair cancels silently. A closed-loop variant that waits for an acknowledgment before accepting the next pulse cannot lose an event, but it limits the rate to the round-trip synchronization latency across both domains. For pulse rates above either bound, a FIFO carries every event.

Reset Synchronization

Reset signals require special synchronization consideration because they affect system startup and recovery. Asynchronous reset assertion typically needs to propagate immediately to all flip-flops without synchronization delay. However, asynchronous reset release can cause metastability if it occurs near a clock edge, since the flip-flop must see the reset go inactive a recovery time before the edge and hold it inactive a removal time after, exactly as it must meet setup and hold on its data input.

The common solution uses asynchronous assert, synchronous release reset synchronizers. The reset signal asynchronously clears the synchronizer flip-flops, ensuring immediate reset propagation. When reset deasserts, the synchronizer releases reset synchronously to the local clock, preventing metastability.

Each clock domain requires its own reset synchronizer to ensure reset release is synchronous to that domain's clock. Reset sequencing between domains must be carefully designed to ensure proper system initialization order.

Clock Domain Partitioning

Good architecture minimizes clock domain crossings by partitioning functionality appropriately. Related logic should reside in the same clock domain when possible, reducing the number of synchronization points and associated latency and complexity.

When crossings are necessary, grouping them into well-defined interfaces simplifies verification and maintenance. Standard interface blocks with proven synchronization can be reused, reducing the risk of CDC bugs.

Consider data flow direction when partitioning. Unidirectional data flow requires simpler synchronization than bidirectional communication. Pipeline stages can often be grouped to minimize crossings while meeting timing requirements.

Calculating System MTBF

System-level analysis must account for every synchronizer in the design. Failure rates add; mean times do not. Writing the rate of each synchronizer as the reciprocal of its MTBF:

1/MTBF_system = ∑ 1/MTBF_i

The reciprocal relation holds here because metastability events are independent of one another and arrive at a constant average rate. That is a property of this particular failure mechanism rather than a general property of MTBF, which equals the reciprocal of a failure rate only while the rate stays constant.

A design with 100 synchronizers, each with a 1,000-year MTBF, has a system MTBF of about 10 years. The more useful consequence is that a sum is dominated by its largest term, so the single worst synchronizer sets the system figure almost by itself. Improving a crossing that already has an enormous MTBF changes nothing, and effort belongs at the fastest domain crossing with the shortest resolution time.

MTBF Requirements by Application

Different applications set very different targets. No standard fixes a number for synchronizer MTBF, so the figures below describe the orders of magnitude commonly adopted as internal design targets rather than externally mandated values:

• Consumer electronics: The most relaxed targets, since an occasional reset over a large fleet costs little and the product life is short
• Industrial equipment: Higher targets, because a single field service call costs far more than the unit that prompted it
• Telecommunications: Very high targets, since carrier availability budgets allow only minutes of outage per year across large deployed fleets
• Medical and other safety-related devices: Targets derived from a hazard analysis. The governing standards require risk management rather than a numeric synchronizer MTBF, and the analysis normally lands well above the commercial classes
• Aerospace and defense: The highest targets, commonly backed by redundancy and voting rather than by synchronizer margin alone

A requirement is only meaningful when it names the acceptable failure rate for the whole deployed population: the number of units shipped, the hours each runs, and what a failure costs when it happens.

Improving MTBF

When MTBF analysis reveals inadequate reliability, several approaches can improve the numbers:

• Add synchronizer stages (each stage exponentially improves MTBF)
• Select a flip-flop with a smaller τ, which means a different library cell or device rather than a different circuit
• Reduce clock frequency if possible (linear MTBF improvement)
• Reduce data transition rate (linear MTBF improvement)
• Use FIFOs instead of simple synchronizers where appropriate
• Reduce the number of domain crossings through architectural changes

Synchronizer Implementation

• Use at least two synchronizer stages for all asynchronous inputs
• Place synchronizer flip-flops close together in layout to minimize interconnect delay
• Use dedicated synchronizer cells if available in the cell library
• Never place combinational logic between synchronizer stages
• Apply the vendor's synchronizer attribute so that optimization cannot merge, replicate, or retime the chain
• Bound each crossing with a maximum-delay constraint on the data path rather than a blanket false path

Multi-Bit Crossing Guidelines

• Use Gray code for counters and sequential data
• Use handshaking or FIFOs for general multi-bit data
• Never synchronize a binary-coded bus with per-bit synchronizers
• Ensure control signals precede or accompany data to guarantee stability
• Verify data coherence requirements for each crossing

Verification Best Practices

• Run CDC analysis tools early and often during design
• Review all CDC tool waivers carefully
• Include CDC scenarios in functional verification
• Document all clock domain crossings and their synchronization approach
• Track MTBF calculations and verify they meet requirements