Clock domain crossings are one of the few categories of digital design bugs that are genuinely hard to test your way out of. Metastability is a probabilistic phenomenon. A two-flop synchronizer that's theoretically correct can still produce metastable output on a specific set of transitions under a specific PVT corner, and functional simulation — which models flip-flops as ideal binary elements — won't reproduce that failure. You can run a billion-cycle simulation and never see the CDC bug that will fail in the field after six months of operation.
This is why static CDC analysis exists as a discipline distinct from simulation: the class of bugs it's designed to catch is structurally undetectable in RTL simulation, and partially detectable in gate-level simulation only with special metastability injection modes that most teams don't use in their standard flow.
What static CDC analysis can reliably tell you, what it cannot, and where simulation is still necessary — that's what this post is about.
What Static CDC Analysis Reliably Finds
Unguarded Single-Bit Crossings
The simplest CDC hazard: a single-bit signal driven from flip-flops in domain A, sampled directly by logic in domain B with no synchronizer in between. This is a structural property of the netlist — the clock domain assignment of the source flop and the destination flop can be determined from the clock tree structure, and the absence of a synchronizer stage on the path is checkable without any simulation.
For single-bit crossings, static analysis achieves close to complete coverage. The check is: does every path from a register in domain A to a register in domain B pass through a recognized synchronizer topology (two-flop, three-flop, or a qualified custom synchronizer cell)? Paths that don't pass this check are flagged. False positive rate on this check is low — the main sources of false positives are intentional constant-driven paths (which should be annotated as such) and paths through formally verified gray-code encodings.
Synchronizer Topology Validation
Having a synchronizer in the path isn't sufficient — the synchronizer needs to be topologically correct. A two-flop synchronizer where both flops are in the same clock domain (a common cut-and-paste error) doesn't synchronize anything. A three-flop synchronizer where the first flop has combinational logic between it and the second stage has a hold time vulnerability that negates the synchronization.
Static analysis can verify synchronizer topology against a pattern library: is the first flop driven directly from domain A logic with no intervening combinational logic? Are both destination flops in the same domain B? Is the MTBF (mean time between failure) of the synchronizer topology consistent with the operating frequency? These are structural checks that are well within the scope of RTL analysis.
Multi-Bit Bus Crossings Without Proper Encoding
Multi-bit data crossings are where CDC analysis gets more complex. A multi-bit bus where bits can transition independently can arrive in partially-updated state at the destination domain — some bits reflecting the old value, some reflecting the new value. This is correct behavior from the bus driver's perspective but produces a corrupt intermediate value at the receiver.
The standard solutions are: gray-code encoding (where only one bit changes per valid transition), handshaking protocols (where a valid/ack pair in each domain controls the transfer), or a properly designed asynchronous FIFO with gray-coded read/write pointer crossings. Static analysis can verify that multi-bit buses crossing domains are using one of these patterns, and flag buses that are being treated like single-bit signals.
Reconvergence Paths
A reconvergence path is one where two signals originating in different source domains (or different phases of the same domain) arrive at a gate in the destination domain. Even if each individual crossing is synchronized, the two synchronized copies may disagree for one cycle due to different synchronizer latencies, and their reconvergence at a combinational gate produces a glitch.
Reconvergence detection is one of the more computationally intensive parts of CDC analysis because it requires tracing all fanout paths from multiple source domains simultaneously. But it's still a structural check on the netlist topology — no simulation required — and it catches a class of bugs that's particularly difficult to detect by inspection.
What Static CDC Analysis Cannot Reliably Find
Protocol-Level CDC Hazards
Static analysis operates on the structural netlist — which signals exist, which domains they live in, how they're connected. It doesn't understand protocol semantics. If a bus protocol requires that signal A be stable for two clock cycles before signal B is asserted, and a CDC crossing violates that relationship under specific timing conditions, static analysis has no way to verify the protocol constraint unless it's been formally specified.
An example: an AHB burst transfer where the address is registered in the master domain and the data is registered in a separate clock domain controlled by the bus fabric. Structurally, both signals may be correctly synchronized individually. The protocol hazard is that the address and data may not be coherent at the bus interface under certain bus contention scenarios. This requires protocol-level verification — either formal property checking against an AHB specification, or targeted simulation scenarios that exercise the contention case.
MTBF-Failure Scenarios Under Corner PVT
Static analysis can compute MTBF estimates for synchronizer topologies based on cell library parameters and operating frequency. What it cannot predict is which specific silicon samples will fail under which specific PVT corner. A synchronizer that achieves acceptable MTBF at nominal conditions may fall below the acceptable threshold at maximum frequency + worst-case voltage + high-temperature operation.
This is a characterization problem, not a structural problem. It requires silicon or SPICE-level analysis, not RTL static analysis. We flag synchronizer topologies where the MTBF estimate is marginal — below 10 years at the operating frequency — but we explicitly document that this is an estimate, not a guarantee.
Asynchronous FIFO Implementation Correctness
An asynchronous FIFO is one of the standard solutions for multi-bit CDC data transfer. The FIFO itself is a module with well-understood correctness requirements: gray-coded read and write pointer crossings, correct binary-to-gray and gray-to-binary conversion, correct empty/full flag generation from the pointer comparison. Static analysis can verify that the pointer crossing topology looks like a correct async FIFO pattern. It cannot formally verify that the gray code implementation is correct for all pointer values and all transition sequences — that requires formal verification or exhaustive simulation of the FIFO module in isolation.
We treat async FIFO verification as a split responsibility: static analysis verifies that the FIFO is being used correctly in the design context (crossing topology, synchronizer stages present, correct read/write interface), and we flag async FIFOs that haven't been validated against a formal correctness checklist for independent module-level verification.
When Simulation Closes the Gap
The place where simulation adds meaningful CDC coverage beyond static analysis is in scenarios where the protocol behavior and CDC behavior interact. Specifically:
Reset sequence CDC interactions. Asynchronous reset deassertion across clock domains is a CDC crossing that interacts with the initialization protocol. If the design relies on reset propagating to all domains before clock activity begins, but the reset deassertion is not synchronized per domain, static analysis flags the crossing, but the protocol consequences of an incorrect deassertion sequence require simulation to exercise.
Power domain wake-up sequences. In designs with multiple power domains (a common pattern in mobile and IoT silicon), domain wake-up involves both CDC crossings and power-up sequencing constraints. The combination of CDC timing and power-up sequencing is a scenario space that benefits from targeted simulation of corner-case wake-up sequences, not just structural static analysis.
CDC under clock gating. When one of the involved clock domains is gated, the CDC behavior changes — the destination flop may be holding state during the gated period, and the source domain may have advanced. Static analysis can identify that a crossing is in a gated clock domain, but the correct behavior during and after the gating event depends on the design's clocking architecture in ways that benefit from simulation confirmation.
Structuring the CDC Verification Plan
Our recommended layering for CDC verification in an ASIC development flow:
At RTL checkin (every commit): structural CDC analysis covering unguarded crossings, synchronizer topology validation, multi-bit bus encoding checks, and reconvergence detection. This runs in under 5 minutes for most blocks and catches the structural violations that account for the majority of CDC silicon bugs.
At design freeze (once per milestone): formal CDC verification for the highest-risk blocks — specifically, any block containing asynchronous FIFOs, complex handshaking protocols across domains, or multiple interacting clock gating domains. This is a 2-5 day effort per block and requires a dedicated formal engineer or a team member with formal tool experience.
In simulation: targeted CDC scenarios that exercise the protocol-level interactions that static analysis can't verify. This means writing testbench scenarios that specifically exercise reset deassertion sequences, clock domain wake-up events, and bus transactions that cross domain boundaries under contention conditions. Not exhaustive simulation — targeted scenario coverage of the specific interactions that the static and formal passes identified as unverifiable by structure alone.
The combination of these three layers covers the realistic CDC risk space for a mid-complexity ASIC design. Any one layer in isolation leaves meaningful gaps — but the layer that's most often missing from teams we work with is the first one: consistent structural CDC analysis at RTL checkin, before any other verification has run.