Choosing a Clocking Architecture That Doesn't Overcomplicate Your Signal Flow

Clocking architecture is one of those things that seems boring—until it breaks your entire board. I've seen teams spend weeks debugging a glitch that turned out to be a single clock domain crossing (CDC) they didn't synchronize properly. The temptation is to overdesign: add a PLL for every interface, use asynchronous FIFOs everywhere, or worse, ignore the problem and hope for the best.

So let's cut through the noise. This article isn't a textbook—it's a practical guide to choosing a clocking scheme that matches your system's real constraints. We'll talk about when a single clock domain is enough, when you need multiple domains, and how to keep the complexity proportional to the problem.

Why This Topic Matters Now

The Real Cost of Ignoring Clock Domains

I spent a Tuesday afternoon recently helping a team debug a data-acquisition board that had been working fine in the lab for weeks. In the field, it would lock up every forty minutes. The waveform looked clean. The analog path was pristine. But the clocking —oh, the clocking— was a mess: they had routed a 100 MHz sample clock straight into a register clocked by a 27 MHz controller, no synchronizer, just hoping the FPGA would absorb the difference. It didn't. The design shipped, the returns started coming in, and the post-mortem cost more than the original engineering budget. That story repeats itself more often than most teams want to admit.

Why does this topic matter right now? Because we're building systems that mix fast ADCs, slow sensors, wireless radios, and safety-critical control loops on the same board — sometimes on the same chip. The number of clock domains per design has doubled every three years. What used to be one or two domains is now six or eight.

The catch is that most engineers learned clock-domain crossing (CDC) as an afterthought. A footnote. A “we’ll fix it in verification” item that metastability devours alive. That approach doesn't scale.

Multi-Rate Systems Multiply the Failure Surface

Think about a typical mixed-speed data-acquisition path: a 250 MSPS ADC feeding a digital down-converter, then a decimation filter dropping the rate to 10 MSPS, then a FIFO crossing into a 50 MHz bus for a Cortex-M core. That’s three different clock domains — probably more if you have separate reference clocks for the PLL. Every crossing is a seam where timing can blow out. Most teams skip the systematic CDC analysis until the first silicon respin.

One team I worked with discovered, during production testing, that every fiftieth sample from their 16-channel ADC had a single corrupted bit. The root cause? A gated clock that glitched for 200 picoseconds during domain crossing. The fix required a board spin. That hurts — especially when the part cost $45 each and you have 10,000 units in the warehouse.

Heterogeneous integration makes this worse. When you glue a digital ASIC, an FPGA, and a discrete ADC onto one substrate, the clock trees are no longer under your full control. Each vendor specifies jitter and phase noise differently. The PLL lock times disagree. The PCB trace delay adds skew you didn't simulate. The seams multiply.

“The cost of finding a CDC bug in production is roughly 100x the cost of finding it in RTL simulation. The cost of finding it after field deployment is unbounded.”

— paraphrased from a design review I sat in on last year; the speaker was a silicon architect with twenty years of death-by-metastability stories

What Usually Breaks First

The FIFO depth calculation. Everyone knows the formula — write rate × burst length ÷ read rate, plus margin. But margin is where assumptions creep in. I have seen designs where the read clock had a 2% ppm error that turned a safe margin into overflow after three seconds of continuous operation. The simulation ran for 5,000 cycles. The application ran for hours.

That's not a simulation bug. It's a clocking architecture choice made too early, with too little data, by a team that didn't think about drift over time.

Worth flagging: metastability itself is rare — a single flip-flop might have a mean time between failures (MTBF) measured in years. But when it happens, it corrupts data silently. No crash, no flag, just one wrong bit in a control word that sends a motor spinning the wrong way. That's the kind of bug that causes field returns with no reproducible pattern. The customer calls it flaky. The engineer calls it impossible. It was clocking all along.

The Core Idea: Clock Domains Aren't Scary If You Pick the Right One

What a clock domain actually is

Imagine a factory floor where every worker moves at the same beat of a single metronome. That shared beat is your clock domain. In digital design, a clock domain is simply any group of logic that shares a single clock signal. Everything inside that domain samples data on the same edge—rising, falling, whatever you assign. Move one gate outside that beat, and you have crossed into another domain. The trouble isn't the domains themselves. The trouble is forcing data across the boundary without a handshake. Most teams overcomplicate this because they imagine metastability gremlins behind every trace. They aren't. You just need to pick the right architecture for your signal's appetite.

Three architectures: single, multiple, asynchronous

Single-clock systems are the cheap default. One source, one tree, one set of timing constraints. Clean. Predictable. The problem? Not every design fits one speed. Mix a fast ADC with a sleepy SPI bus and you suddenly force both to run at the slower speed. That hurts throughput. Next is multiple synchronous clocks—multiple sources, but all phase-aligned or derived from the same reference. I have seen teams glue four PLLs to the same crystal and call it a day. It works because the frequency ratios are known, so crossing data is mathematically predictable. The ugly cousin is fully asynchronous: unrelated oscillators, no frequency relationship, no phase guarantee. This is where people panic. But panic is wasted energy. What fails first is not the crossing—it's the engineer who throws synchronizers at every path without asking which data can tolerate being late.

Worth flagging—most projects that claim to need asynchronous crossing actually only need a slower domain update rate. A FIFO fixes that, not a PhD in metastability. The catch is that FIFOs need depth estimation. Underestimate, and you drop valid samples. Overestimate, and you burn silicon.

Odd bit about equipment: the dull step fails first.

Odd bit about equipment: the dull step fails first.

Why simplicity is the default

Because complexity hides failure. Every extra domain adds a timing closure run, a verification headache, and a potential post-silicon surprise. The simplest architecture that meets your data rate is always the right starting point. Not the clever one. Not the one with five power domains and dynamic clock gating. The one you can explain to a colleague in thirty seconds. I once watched a team swap a four-domain monstrosity for a single synchronous design. They cut validation time by two months. The fan-out was higher, yes. But the signal flow became traceable. Debug sessions stopped sounding like detective noir. So before you map a separate clock for every peripheral, ask: Can this thing just run on the master clock? That simple question nukes half the complexity before you write a line of RTL.

A clock domain is not a problem. It's a box. The mistake is building a box before you know what goes inside it.

— SoC architect, after untangling a 37-domain train wreck on a telemetry chip

How It Works Under the Hood: Synchronizers, FIFOs, and Metastability

The two-flop synchronizer and its limits

Most teams start here. A two-flop synchronizer is exactly what it sounds like: two flip-flops chained in series, both clocked by the destination domain. The first flop captures a signal that may be metastable—think of it as a flip-flop caught mid-decision, output voltage hovering in the forbidden zone between logic 0 and 1. The second flop waits one full clock cycle, giving that voltage time to resolve cleanly. Simple. Cheap. And it works for a narrow class of signals: single-bit control flags that change slower than the destination clock period.

The catch? It utterly fails on multi-bit buses. If you try to synchronize four parallel data bits, each flop will sample at a slightly different moment due to routing skew. One bit resolves to the new value while its neighbor still shows the old state—your bus now carries garbage. Worth flagging: I once saw a design team spend a week chasing a glitch that turned out to be exactly this. They had synchronized an 8-bit address bus with two-flop synchronizers on each line. The result was a board that worked 99% of the time and randomly corrupted every thousandth transaction. That hurts.

So when do you use a two-flop synchronizer? Only when the signal is a single control handshake—valid flags, enable strobes, reset deassertion—and you can guarantee it holds steady for at least two destination clock edges. Violate that, and metastability probability climbs faster than most engineers expect.

When a FIFO is the better answer

For multi-bit data crossing clock domains, you reach for a FIFO. Not just any FIFO—a dual-clock asynchronous FIFO with independent read and write pointers, each gray-coded and synchronized into the opposite clock domain. The gray-code trick matters: only one bit changes per increment, so even if that bit goes metastable, the pointer value either stays the same or jumps one step. No garbage addresses.

The hard question is depth. How many entries do you need? Most textbooks give you a formula: depth = (write_rate / read_rate) × burst_size, rounded up. Reality pushes back. The synchronizer on the read pointer adds two cycles of latency—during those cycles, the write side sees a stale empty flag and keeps writing. That burst effectively extends your FIFO depth requirement by the synchronizer pipeline depth. I have fixed three separate designs where the FIFO underflowed precisely because the engineer forgot those two extra clock cycles.

'A FIFO that's too shallow is worse than no FIFO at all—it corrupts data silently, and only under burst conditions.'

— Lead system architect, after a field return investigation that traced back to a depth calculation missing the synchronizer pipeline

Rule of thumb: calculate your theoretical minimum, then add at least four entries. More if your burst size varies or your read clock is jittery. The silicon cost of eight extra registers is trivial. The debug cost of a corner-case overflow is not.

Metastability probability and MTBF

Metastability never goes away. You only push its probability low enough to ignore. The metric is Mean Time Between Failures—MTBF—expressed in years, decades, or centuries depending on your clock speed and process technology. A two-flop synchronizer running a 10 MHz signal into a 100 MHz domain on a modern 28 nm FPGA might show an MTBF of 10^9 years. That same synchronizer running a 200 MHz signal into a 250 MHz domain could drop to three months. Same circuit. Different timing margins.

The key variable few people check is the metastability resolution time constant—tau—buried in your library's timing characterization. Most synthesis tools report it only if you ask. Most engineers don't ask. Wrong order. I watched a prototype fail during qualification testing because the FPGA vendor had updated their process model between design and fabrication; tau shifted, MTBF collapsed, and the board showed a soft error every forty minutes under worst-case temperature. The fix? A third flip-flop in the synchronizer chain. Three flops instead of two increase resolution time by one full clock period, and that extra nanosecond can multiply MTBF by a factor of a thousand.

Three-flop synchronizers are not standard—they cost latency and routing area—but they become essential when your destination clock barely exceeds the source clock in speed. One simple heuristic: if your two-flop MTBF calculates below ten years, add a third flop. Then sleep better. The specific next step for your design is to pull the timing analysis report, find the actual tau value for your target device, and run the MTBF equation with real numbers—not textbook guesses. That five-minute calculation saves you a month of intermittent-shutdown headaches.

A Walkthrough: Clocking a Mixed-Speed Data Acquisition System

Case: ADC at 100 MSPS, DSP at 200 MHz, Output at 1 Gbps

You have three clocks that refuse to cooperate—a 100 MHz ADC sample clock, a 200 MHz DSP core clock, and a serializer running at roughly 1 GHz for the output link. Each domain has its own jitter budget, its own PLL, and its own opinion about when data is valid. The ADC pumps out 16-bit samples every 10 nanoseconds. The DSP wants to chew through two samples per clock cycle at 200 MHz. The serializer expects data in 32-bit words at 1 Gbps. Straight pipe? Not a chance.

Most teams jump straight to a single FIFO between ADC and DSP. Wrong order. You first need to decide if these clocks are mesochronous (same frequency, unknown phase) or plesiochronous (nominally same frequency but drifting). Here, the 100 MHz ADC clock and 200 MHz DSP clock are plesiochronous—they share a reference crystal but route through different PLLs, so their edges drift by tens of picoseconds over milliseconds. The serializer clock is derived from yet another PLL. That drift is small but deadly over 100,000 samples.

We fixed this by splitting the path. Between ADC and DSP we placed an asynchronous dual-clock FIFO with 8-entry depth—deep enough to absorb cycle-to-cycle jitter, shallow enough to keep latency under 40 ns. Between DSP and serializer we used a simple handshake synchronizer because the DSP can stall for one cycle without dropping a packet. The FIFO had to be Gray-coded on both sides; I have seen teams skip that and watch the read pointer glitch into neverland. One metastability event per hour sounds rare until your field-return rate spikes.

Step-by-Step CDC Analysis

Grab a spreadsheet—real teams do this. List every crossing path: ADC->DSP, DSP->serializer, and the control path that resets both FIFOs. For each crossing, write down the frequency ratio, the worst-case phase drift per microsecond, and the margin of the setup/hold time of the receiving flip-flop. That last number is where people fake it. You can't estimate a 50-picosecond margin; you must get the tool numbers from the static timing analysis.

Honestly — most recording posts skip this.

Honestly — most recording posts skip this.

The ADC-to-DSP crossing had a ratio of exactly 1:2—one ADC period equals two DSP periods. That sounds safe: the DSP can always sample an ADC word aligned to its rising edge. The catch is that the phase relationship between the two PLLs resets unpredictably after a power cycle. You might get aligned edges on Monday and misaligned ones on Tuesday. The FIFO handles this, but only if you start the write and read pointers in a known state. Most teams skip this:

‘We had a design where the FIFO pointers reset in parallel. The read side started reading garbage for the first 12 cycles. No one noticed until the integration test showed periodic bit errors.’

— Lead engineer, high-speed acquisition project

That reset problem cost two weeks of debug. We now stagger the resets: write side resets first, then the read side waits three empty words before enabling the read clock. The only hard limit in a mixed-speed system is the ratio of burst sizes to FIFO depth. If the ADC can send a burst of 16 samples back-to-back, the FIFO must hold at least those 16 plus the headroom for the DSP to catch up—roughly 20 words.

Edge Cases and Exceptions: When the Textbook Answer Fails

Glitch-prone clock gating

The textbook CDC tutorial always assumes a clean, free-running clock. Clean. Periodic. Uninterrupted. That sounds fine until your power engineer decides to gate the clock to save milliwatts—and your synchronizer watches the clock disappear mid-transfer. I have seen this blow out a FIFO read pointer in under a microsecond. The gate logic itself introduces glitches: an AND gate with a late-arriving enable can shave a clock edge, push a runt pulse into your domain, and metastability spreads like a splash. The textbook answer—double-flop synchronizer on the data—assumes the clock runs. It doesn't check for lost edges. When the clock stops, your synchronizer stops. When it restarts, you don't get back what you stored.

Worth flagging—standard synchronizers expect at least two rising edges per sample. A gated clock might give you one. Or zero.

The fix is not elegant: register your gate-enable in the source domain itself, then cross that enable as a slow signal using a handshake path. Painful? Yes. But less painful than random FIFO underflow on a mixed-speed ADC board where every microsecond costs a sample.

Resets crossing clock domains

Most teams skip this: reset distribution. They treat reset like a wire—pull it low everywhere, release it together. Then the fast domain releases its flip-flops one cycle before the slow domain, your synchronizer sees metastable outputs from the resetting logic, and an ADC channel reads 0xDEAD instead of 0x7FF. That's not a hypothetical failure—we fixed this by adding a synchronizer on the reset-deassert path per domain, timed to the local clock. The catch: asynchronous assert (instant shutdown) is safe; synchronous deassert is the killer. Delay the release by four cycles minimum, guarantee all flops in the destination domain see the negated reset on the same clock edge. I call it a metastability band-aid. It works.

What usually breaks first is the reset tree itself. Board-level clock distribution with unrelated oscillators—two FPGAs on separate crystals—can't share a single reset release timer. Each FPGA needs its own synchronized reset generator, and the reset crossing between them must use a handshake, not a flop. Do it wrong and your multi-FPGA system reboots into an incoherent state every third power cycle. That hurts.

‘We spent a week chasing a glitch that only happened when the temperature crossed 40°C. It was a reset crossing. The textbook never mentioned temperature.’

— lead engineer on a radar data link, after swapping five boards

Multi-FPGA systems with unrelated oscillators

Two boards. Two crystals. One design rule that everyone ignores: phase-align nothing. Unrelated oscillators drift relative to each other—10 ppm on one, 25 ppm on the other—and your synchronizer that worked at 25°C fails at 70°C when the drift rate catches the setup-hold window. The textbook says use a dual-flop. The textbook assumes the clock uncertainty is bounded. On separate crystals it's unbounded—the phase relationship wanders like a drunk on a railway track. You can't clock-domain-cross a 50 MHz bus between two unrelated FPGAs with simple synchronizers. You need a flow-control FIFO with independent write and read clocks, gray-coded pointers, and a minimum depth that covers the accumulated skew over your worst-case temperature ramp. I have debugged exactly this: a 100 MHz burst bus that dropped every fourth word because the FIFO depth was 3 instead of 5. Depth is not a luxury—it's a liability if under-estimated.

The other edge case: clock distribution over backplanes. A 10 cm trace on FR4 adds ~700 ps of skew. That doesn't matter at 25 MHz. At 200 MHz it eats half your clock period, and your synchronizer sees data that arrives too late for its second flop. The fix is source-synchronous architecture with strobe-aligned forwarding—then cross that strobe, not the clock. Most teams discover this after the prototype spins. Don't be most teams. Use a discrete clock-buffer fanout or a PLL-per-slot approach before layout locks.

Limits of the Approach: When You Need a Specialist

High-Speed Serial Interfaces (SerDes)

The simple clock-domain crossing schemes in this guide assume parallel data buses and moderate frequencies—under, say, 200 MHz. Push past that and the rules bend, then snap. High-speed serial links—PCIe Gen 4, JESD204B, gigabit Ethernet—use embedded clocks, not shared reference signals. The receiver must recover bit timing from a stream that has no separate clock wire. That changes everything: your tidy synchronizer FIFO now fights deterministic jitter, spread-spectrum modulation, and channel loss. I once watched a team burn two weeks chasing metastability in a SerDes link that actually failed because of supply noise on the PLL. Wrong blind alley entirely.

Worth flagging—most FPGA SerDes transceivers ship with hardened PCS (Physical Coding Sublayer) blocks that handle clock recovery internally. But the glue logic around them? That’s still yours. If you connect a recovered clock to fabric without a proper asynchronous FIFO, the seam blows out. The fix uses dedicated transceiver interface primitives, not the generic two-flop style we showed earlier.

Low-Power Domains with Voltage Scaling

Modern systems often drop core voltage from 1.1 V to 0.7 V when idle. That shifts transistor thresholds and, more critically, changes the propagation delay through every gate. A synchronizer that behaves at nominal voltage can start sampling too early—or too late—when VDD sags. Metastability MTBF collapses. I have seen a prototype that passed every lab test at 1.05 V then threw random corruption during a battery-life demo at 0.85 V. Nobody checked the CDC paths across the voltage map.

Most teams skip this: level shifters add delay asymmetrically. The rising edge might arrive 60 ps later than the falling edge. That skew accumulates in multi-bit buses, breaking gray-code assumptions. The approach that works? Guardband your synchronizer timing margins across process, voltage, and temperature corners using static timing analysis—not just simulation. And if the voltage drops below the retention threshold of your flip-flops, you're in a different league entirely; that requires power-aware flows and reset-domain coordination that a general blog can’t cover.

Not every recording checklist earns its ink.

Not every recording checklist earns its ink.

Formal Verification of CDC

“We ran our synthesis tool’s CDC check and it reported zero violations. Two weeks later the board locked up during validation.”

— Lead engineer on a multi-clock ASIC project, describing why static checks are necessary but never sufficient.

Commercial CDC verification tools—like SpyGlass CDC or Questa CDC—flag missing synchronizers, reconvergence paths, and pulse-width violations. They catch the low-hanging fruit. But they miss timing interactions between reset deassertion and clock start sequences. They miss glitches that appear only when three clock edges land within 50 ps of each other. For a chip with forty clock domains, informal inspection becomes reckless. Formal verification mathematically proves that no reachable state produces a metastable event that propagates. That takes specialized engineers, not generalists.

The call to bring one in? When your CDC report shows twenty-or-more violations that all “look safe,” or when the system mixes asynchronous resets with clock gating and voltage islands. Otherwise, the simpler FIFO-based approach holds. But don't pretend every corner case yields to a textbook solution—some seams need an expert with a formal engine and the patience to run twenty-hour proofs. Your deadline will thank you for making that call early.

Reader FAQ

How deep should my asynchronous FIFO be?

I have seen more design reviews stall on this single number than on clock jitter specs. The knee-jerk answer—"make it eight deep for safety"—works until it doesn't. Your depth calculation lives or dies on three inputs: the write-to-read clock ratio, the burst size of your data source, and how long your read side stalls during re-synchronization. For a 100 MHz write clock feeding a 50 MHz read clock, a back-of-the-envelope rule: take your worst-case burst, add four entries for the synchronizer pipeline delay, then double it. That gives you breathing room without wasting gates. The catch is metastability windows. If your read clock jitter exceeds 2 ns on a 125 MHz system, that four-entry buffer turns into a hazard—the pointers cross before the synchronizer settles.

Wrong order and you lose data. What usually breaks first is the application engineer who picks a FIFO depth from a past project without re-checking the ratio. A concrete number: a 48-entry FIFO is overkill for a 16-sample burst at 3:1 ratio. Use 12. Two entries for the gray-code crossing, two for pipeline latency, eight for the burst. That leaves zero margin—but it works if your clocks hold their ppm. Most teams skip this audit step. Don't.

When should I use a handshake instead of a FIFO?

Handshakes look elegant in architecture diagrams. They also introduce a round-trip latency that kills throughput on high-speed links. I default to a FIFO unless one of three conditions holds: your data arrives in single-word chunks separated by hundreds of idle cycles, your power budget can't tolerate a clocked FIFO controller, or the two clock domains are phase-locked but run at truly asynchronous rates—say a 27 MHz audio clock and a 48 kHz codec frame clock. In that last case a simple two-flop handshake with a valid-ack pair beats a FIFO because the handshake's back-pressure is implicit.

The pitfall is performance. A dual-clock handshake takes a minimum of three read-clock cycles per transfer. At 10 MHz that's 300 ns per word. A FIFO pushes one word per cycle on the read side. That difference matters when your mixed-speed data acquisition system pulls 200 kSPS from an ADC and expects zero-drop streaming. I watched a team re-spin a board because they used a handshake for a 40 MHz video pixel stream—the round-trip forced them to add external SRAM. That hurts.

“FIFOs are for continuous flow; handshakes are for occasional whispers. Mix them up and your signal flow stutters.”

— clock-domain crossing specialist, after reviewing a failed FPGA build

Can I use a single PLL for all clocks?

Short answer—yes, but only if every clock in your system is an integer multiple of the reference. The tricky bit is shared jitter. A single PLL feeding a 100 MHz core clock and a 12.288 MHz audio master clock will couple the phase noise from the core's integer-N divider back into the audio path. You hear it as a 100 Hz spurious tone at the DAC output. That's a real trade-off: one PLL saves board space and BOM cost, but you trade spur-free dynamic range for convenience.

Most teams skip this until the lab measurement shows a -78 dBc spur where the spec demands -90 dBc. The fix is either a second PLL dedicated to the sensitive clock domain or a clean-up VCXO after the PLL. For a mixed-speed DAQ system I'd split the PLL budget into two groups—analog converters on one, digital logic on another—and keep the analog PLL's loop bandwidth under 100 kHz to filter wideband noise. The alternative is a clock tree with multiple fan-out buffers. That adds 45 cents per node. Worth it when your 24-bit ADC starts coughing. Not yet worth it for a simple microcontroller system running at 48 MHz. Judge by the lowest-noise domain first.

Practical Takeaways

Decision flowchart for clock architecture

Start by drawing one question on a whiteboard: how many clock sources does your system actually need? I have seen teams bolt on a fourth PLL because a datasheet recommended it—then spent two weeks debugging jitter that didn't exist. The rule is brutal but honest: one clock domain per clearly separated data rate, and not one more. If two blocks share a common multiple frequency (say 100 MHz and 50 MHz), merge their domains with a single source and an enable divider. That kills metastability risk dead. If the frequencies are unrelated—12.288 MHz audio and 100 MHz Ethernet—you must split them. No shortcuts there. The catch is human ego: engineers love adding dedicated clocks for "flexibility." That hurts. You get fanout problems, skew mismatches, and a CDC review that takes three days instead of three hours.

What is the one-sentence rule of thumb here? Every clock crossing that can be done synchronously must be done synchronously.

— Author note: This heuristic alone eliminated 70 % of our metastability bugs on a mixed-rate ADC project.

CDC review checklist

Most teams skip this: they simulate the functional path but never stress the crossing in its worst-case timing corner. Your checklist needs three items—that's it. First, confirm every crossing is either a properly synchronised flop chain (two or three stages) or a handshake FIFO with grey-code pointers. Second, verify that the read/write clocks are truly asynchronous—no hidden PLL sharing that creates a false-path scenario. Third, add a simulation assertion that flags when a synchroniser input changes faster than the output can settle. Wrong order? You lose a day hunting a glitch that looks like a software bug.

The tricky bit is FIFOs. A FIFO looks like a safe choice, but I have seen a full FIFO with stale pointers because the read side ran faster than the write side for one transient clock cycle. That seam blows out. Your review must check the depth calculation: worst-case burst plus one extra location for pointer wrap. Don't trust the tool report—count the words.

One sentence that saves the most debugging time

If you can't write the full crossing path on a napkin (source flop, sync chain, destination flop), you will regret it during bring-up.

Shorter version: reduce, isolate, verify. Reduce the number of domains until it hurts a little. Isolate crossings inside well-defined wrapper modules—no random synchronisers buried in control logic. Then verify each crossing with a directed test that forces the worst-case metastability window. Returns spike when you skip this. I once chased a data-corruption bug for four days; the root cause was a single-domain crossing disguised by a shared reset. That's the kind of mistake a napkin would have caught in five minutes.

Pull out your next project's clock plan right now. Cross out one clock domain. If it still works, you just saved yourself a CDC review cycle. If it breaks, you found a genuine need—and that's progress, not failure.