clock domain crossing

**Clock Domain Crossing (CDC)** is the **safe transfer of signals between asynchronous clock domains — using synchronizers (flip-flops), gray-code encoding, and handshake protocols — mitigating metastability risk and preventing data corruption**. CDC is essential for systems with multiple independent clocks. **Metastability Risk and Fundamentals** Metastability occurs when a flip-flop input transitions near clock edge, violating setup/hold time. Output is undefined (neither 0 nor 1) for some period, potentially settling to wrong value. Metastability probability: P_metastable ∝ exp(-2(t_r - t_hold) / τ), where t_r is recovery time (time after clock edge when output settling), t_hold is hold time, τ is flip-flop time constant. Metastability is rare (~10⁻¹⁰ to 10⁻¹⁵ per clock cycle) but inevitable at long intervals (trillions of cycles, failures occur). CDC design ensures that if metastability occurs, it is masked (synchronized, not propagated). **Two-Flip-Flop Synchronizer** Standard CDC solution: cascade two flip-flops in destination clock domain. First flop samples metastable input; if metastable, settles by second flop clock (very high probability: ~10⁻²⁰). Output of second flop is synchronized (stable, low metastability risk). MTBF (mean time between failure) improvement: two-flop vs one-flop is exponential (factor of 10⁶+ improvement). Typical MTBF with two-flop synchronizer: >10 million years (acceptable for most applications). Trade-off: two-flop synchronizer adds 2 clock cycles latency. **MTBF Calculation** MTBF is calculated via: MTBF = 1 / (f_clk × P_metastable), where f_clk is clock frequency, P_metastable is metastability probability per cycle. P_metastable depends on: (1) setup/hold violations (frequency of timing violations), (2) clock frequencies (freq_src and freq_dest, determines window of vulnerability), (3) flip-flop parameters (τ, t_hold). Example: f_clk = 1 GHz, P_metastable = 10⁻¹⁵, MTBF = 10¹⁵ cycles / 10⁹ cycles/sec = 10⁶ seconds ~ 11 days. Two-flop synchronizer reduces P_metastable exponentially: MTBF improves to years/decades. **Gray Code Encoding for Multi-Bit CDC** Multi-bit CDC (e.g., address/counter crossing domains) cannot use simple two-flop synchronizer: only one bit is synchronized at a time, others may be partially transferred (data corruption). Gray code (binary reflected code) ensures only one bit changes between consecutive values: Gray(n) = n XOR (n >> 1). Example: 0→1, 1→3, 3→2, 2→6 in gray code (only 1 bit changes per transition). Synchronizing gray code via two-flops on destination domain guarantees at most one-bit difference from source (no corruption). Decoding gray back to binary is done after synchronization: Bin(gray) via XOR tree. **Handshake Protocol (Req/Ack) for Control Signals** For control signals (enables, resets, bus grants), handshake protocol ensures reliable transfer: (1) source asserts req (request) when data ready, (2) destination detects req (via synchronizer), services request, (3) destination asserts ack (acknowledge) when done, (4) source detects ack (via synchronizer), deassserts req, (5) destination detects req deassertion, deasserts ack. Handshake is robust against metastability: sync latency adds delay (3-4 cycles per direction), but guarantees data integrity. Used for low-bandwidth control (handshake adds latency, unsuitable for high-bandwidth data). **FIFO-Based CDC for Data** For high-bandwidth data crossing domains, FIFO (first-in-first-out) buffer with CDC on read/write pointers is used. FIFO: (1) write port in source domain, (2) read port in destination domain, (3) write pointer (source domain) tracks write location, (4) read pointer (destination domain) tracks read location, (5) full/empty flags derived from pointer comparison. Pointers are gray-coded before CDC (safe multi-bit transfer). FIFO enables pipelined, high-bandwidth data transfer without handshake latency. Trade-off: FIFO buffer area/power vs bandwidth advantage. **CDC Sign-off Tools** Formal verification tools (Cadence JasperGold CDC, Mentor Questa CDC, Synopsys VC Formal) check CDC compliance: (1) identify clock domain crossings (nets crossing from one clock to another), (2) verify synchronizers present (two-flop or equivalent), (3) verify gray-code usage for multi-bit CDC, (4) verify no combinational CDC paths (all CDC goes through synchronizers). Tools report: (1) CDC violations (missing synchronizers), (2) potential metastability, (3) false paths (intentional CDC, not errors). Sign-off tools are mandatory: many silicon bugs originate from CDC violations. **False Path Constraints for CDC Paths** CDC synchronizer introduces delay (2-3 clock cycles). Timing analysis must mark CDC paths as false (not analyzed for setup/hold timing), since synchronizer intentionally violates timing in source domain. Constraint: "set_false_path -from [get_pins source_clk*] -to [get_pins dest_clk*]" marks all CDC paths false. Incorrect constraint (forgetting to mark CDC false) causes timing violations (STA incorrectly reports setup violations on intentional CDC paths, inflating timing issues and confusing timing closure). **Reset Synchronization** Reset is often global (released asynchronously), causing all flip-flops to reset. However, if reset is released near clock edge in some domain, metastability occurs (reset partially takes effect). Reset synchronizer: (1) global async reset (fast, sets all flops), (2) local sync reset (delayed, synchronous in each domain) for fine-grained control. Async reset for critical paths (guarantees fast reset), sync reset elsewhere (acceptable delay). Proper reset synchronization is often overlooked and causes mysterious failures in edge cases. **Summary** Clock domain crossing is a critical design consideration, requiring careful synchronizer placement and formal verification. CDC violations are a common cause of silicon bugs; rigorous methodology and tool use are essential.