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 (tau) that depends on the flip-flop's internal gain and transistor characteristics. Smaller time constants indicate faster resolution and lower metastability susceptibility.

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 (tau): The exponential time constant describing how quickly the flip-flop exits the metastable state. Typical values range from 20 to 200 picoseconds depending on the technology and circuit design. Smaller tau values indicate better metastability performance.

Metastability window (T0): The effective time window around the clock edge during which data transitions can cause metastability. This parameter relates to but differs from the setup/hold time window specified for reliable data capture.

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

Mean Time Between Failures

Mean time between failures (MTBF) quantifies synchronizer reliability by predicting the average time between metastability events that cause downstream failures. The MTBF equation for a single synchronizer flip-flop is:

MTBF = e^(tresolution / tau) / (T0 * fclk * fdata)

Where tresolution is the available resolution time (typically the clock period minus setup time), fclk is the clock frequency, and fdata is the rate at which data transitions occur. This equation reveals key insights:

• MTBF increases exponentially with available resolution time
• Higher clock and data frequencies proportionally reduce MTBF
• Flip-flops with smaller tau provide exponentially better MTBF
• Adding synchronizer stages multiplies MTBF values

For most applications, designers target MTBF values of years to decades, far exceeding the expected system lifetime. Critical applications such as aerospace, medical, or nuclear systems may require even higher MTBF targets.

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.

The total MTBF of a two-stage synchronizer equals the product of the individual stage MTBFs, providing an exponential improvement over a single flip-flop. For typical flip-flops at moderate frequencies, two stages provide MTBF values exceeding millions of years, sufficient for virtually all commercial applications.

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

Beyond three stages, additional flip-flops provide diminishing returns. If three stages do not provide adequate MTBF, the design likely needs architectural changes rather than more synchronizer stages.

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 may be filtered, with narrow pulses potentially missed entirely. For reliable detection, input pulses must be wider than one clock period of the destination clock, though two periods provides margin for metastability resolution time.

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 either an extra pointer bit or a different encoding scheme. With an extra bit, full occurs when the pointers differ only in the MSB after accounting for the wrap-around, while empty occurs when they are exactly equal including the extra bit.

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 verification requires accurate clock domain definitions. Designers must specify which clocks are asynchronous, synchronous, or have other relationships. False paths must be correctly identified to prevent tools from erroneously flagging valid structures.

Common CDC constraints include:

• Clock domain definitions grouping clocks by relationship
• Synchronizer recognition patterns for tool identification
• False path specifications for intentionally unsynchronized signals
• 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.

Pulse synchronizers can miss or merge pulses if they arrive faster than the round-trip synchronization latency allows. For high pulse rates, FIFO-based approaches provide reliable transfer of every pulse 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.

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 MTBF analysis must account for all synchronizers in the design. Each synchronizer contributes to the overall failure rate, and the system MTBF is approximately the inverse of the sum of individual failure rates:

System MTBF = 1 / (sum of 1/MTBF_i for all synchronizers)

A design with 100 synchronizers, each with 1000-year MTBF, has a system MTBF of approximately 10 years. This calculation highlights the importance of high individual synchronizer MTBF in designs with many domain crossings.

MTBF Requirements by Application

Different applications have vastly different MTBF requirements:

• Consumer electronics: 10-100 years system MTBF may be acceptable
• Industrial equipment: 100-1000 years to minimize service calls
• Telecommunications: 1000+ years for carrier-grade reliability
• Medical devices: High MTBF required by regulation, typically 10000+ years
• Aerospace and defense: Extremely high MTBF, often requiring redundancy

Requirements should specify acceptable failure rates considering the number of deployed units, operating hours, and consequences of failure.

Improving MTBF

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

• Add synchronizer stages (each stage exponentially improves MTBF)
• Use flip-flops with better metastability characteristics (smaller tau)
• 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 CDC-specific constraints to prevent optimization that breaks synchronizers

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