Clock Domain Crossing (CDC)

A clock domain is a region of a chip driven by a single clock. A clock domain crossing (CDC) happens whenever a signal travels from logic clocked by one clock into logic clocked by another that is asynchronous, at a different frequency, or in an unrelated phase. A typical ASIC has several domains — for example a fast hashing domain and a slower control or interface domain — so crossings between them are unavoidable and must be handled deliberately rather than left to chance.

The metastability problem

If a signal changes right as the receiving clock samples it, the capturing flip-flop can enter metastability, an unstable state that is neither a clean 1 nor a clean 0 and may resolve unpredictably after an unbounded delay. Propagated downstream, that ambiguity corrupts data and causes intermittent, hard-to-reproduce failures — exactly the kind of flaky behaviour that is maddening to diagnose in the field, because it may appear only under a particular temperature, voltage, or workload and vanish the moment you attach a probe. Metastability can never be eliminated entirely; it can only be made astronomically unlikely to matter.

How it is handled

Designers insert synchronizers at every crossing. The classic two-flip-flop synchronizer samples the incoming signal, then gives any metastability a full clock cycle to decay before a second flip-flop captures a now-settled value. Multi-bit buses need more care: a plain synchronizer per bit can let bits arrive skewed, so designs use gray-coded counters, where only one bit changes at a time, or asynchronous FIFOs that hand off whole words safely. Verifying that every crossing is properly synchronized — CDC verification — is a standard, mandatory step in taping out any chip with multiple clocks, and it is a class of bug that ordinary functional simulation can miss entirely because simulators often assume idealized timing.

Where domains meet in a miner

A mining ASIC is a natural home for CDC because it deliberately runs its hashing logic much faster than the interface that talks to the control board. Nonces, work items, and status all cross between the fast core and the slower serial link that carries data over the hashboard ribbon. Each of those handoffs is a designed-in crossing with a synchronizer behind it, which is why a well-made chip stays reliable even though two very different clocks are cooperating inside it.

Why it shows up in the field

For anyone diagnosing hardware, CDC is a reminder that not every fault is a broken component. A board that mostly works but throws rare, unrepeatable errors may be sitting on a marginal timing path rather than a failed part, and chasing it with a multimeter will find nothing. That distinction — between a hard failure you can measure and a probabilistic one you can only characterize — is useful context on any repair bench where a miner “sometimes” misbehaves.

CDC also has a subtler cost that never shows up as a bug: latency. Every synchronizer deliberately delays a signal by one or more clock cycles to give metastability time to settle, so information crossing between domains always arrives a little later than it strictly could. In most designs this is negligible, but in tightly-optimized data paths the designer must budget for it, and deciding how many domains a chip should have becomes a real trade-off between flexibility and the accumulated cost of all those crossings. For anyone reasoning about how a mining chip is put together, this is a reminder that the neat block diagram hides a web of carefully engineered handoffs, each one a small insurance policy against the physics of two clocks that never quite agree on when now is.

The clocks that define each domain are produced on-chip by the phase-locked loop and delivered by the clock tree; the fast domain in a mining chip is the one feeding the array of hash engines.