CDC Bridges

This closes Module 15 with clock-domain crossing (CDC) — bridging AHB between two asynchronous clock domains safely. When an AHB master in one clock domain must reach a slave in a different, asynchronous clock domain (e.g. a fast CPU domain and a slow peripheral domain on unrelated clocks), you can't just wire the signals across — that risks metastability (a flop sampling a signal mid-transition, settling unpredictably) and incoherent multi-bit values (different bits captured on different edges). So a CDC bridge sits between them, with logic in each domain, applying the CDC discipline. Three rules. (1) Synchronise single-bit control — control/handshake signals cross through a multi-flop synchroniser (2+ flops in the destination clock) to let metastability settle. (2) Move multi-bit data coherently — never directly sample a multi-bit bus across domains (the bits could be captured on different edges → incoherent); instead use an async FIFO or a request-acknowledge handshake that guarantees the whole value is stable when captured. (3) Accept added latency — the crossing costs synchroniser + FIFO/handshake cycles. This chapter covers the CDC bridge structure and these rules — the safe way to cross AHB between asynchronous clocks.

1. What Is It?

A CDC bridge crosses AHB transfers between two asynchronous clock domains safely. Its elements:

• Logic in both domains — the bridge straddles the boundary, with a part clocked by each domain.
• Synchronise single-bit control — control/handshake signals cross through a multi-flop synchroniser (2+ flops) in the destination clock — to let metastability settle.
• Move multi-bit data coherently — never raw-sample a multi-bit bus across domains; use an async FIFO or req-ack handshake (whole value stable when captured).
• Added latency — the crossing costs synchroniser + FIFO/handshake cycles.

So a CDC bridge is the safe boundary between asynchronous AHB clock domains. The danger it addresses is metastability: when a signal generated in domain A is sampled by a flop in domain B (on B's clock), and the signal changes near B's clock edge, the flop can go metastable (its output hovers between 0 and 1, settling unpredictably after a delay). For a single control bit, a multi-flop synchroniser lets the metastability settle (the first flop may go metastable, but it settles before the second flop samples it — giving a clean, if delayed, value). For a multi-bit bus, synchronising each bit independently is not enough — different bits could settle to old or new values, giving an incoherent combination (a value that was never valid). So multi-bit data needs an async FIFO or handshake that ensures the whole value is stable when captured. So a CDC bridge applies the CDC discipline (synchronise control, coherent data) to make the asynchronous AHB crossing safe. So it's the safe inter-clock-domain AHB bridge.

2. Why Does It Exist?

CDC bridges exist because asynchronous clock domains are a physical reality (different subsystems run on unrelated clocks), and naively crossing signals causes metastability and data incoherence — so a disciplined crossing (synchronisers, FIFOs/handshakes) is required for correctness.

The asynchronous-domains reality is the root: a real SoC has multiple clock domains — a fast CPU/bus domain, a slow peripheral domain, an external-interface domain (e.g. a USB/Ethernet PHY on its own clock), etc. — often on unrelated (asynchronous) clocks (different PLLs, different frequencies, no fixed phase). So an AHB master in one domain will sometimes need to access a slave in another — crossing an asynchronous boundary. So the crossing is necessary. So CDC bridges exist because asynchronous domains exist and must be crossed.

The metastability danger is why the crossing is hard: when a signal from domain A is sampled by a flop clocked by domain B, and the signal transitions near B's clock edge (which it will, eventually, since the domains are asynchronous — no fixed timing relationship), the flop can go metastable — its output hovers between 0 and 1 for an unpredictable time before settling to either value. If that metastable output is used directly (fed to logic), it can cause errors (logic sees an ambiguous value). So a naive crossing (just wire and sample) is unsafe — metastability will eventually corrupt. So CDC bridges exist to handle metastability. So you can't just wire across.

The single-bit-synchroniser solution: for a single bit, a multi-flop synchroniser (typically two flops in series in the destination clock) gives the metastability time to settle: the first flop may go metastable when it samples the async signal, but it settles (to some value) within a clock period, so the second flop samples a stable value (giving a clean, if one-cycle-delayed, output). So the synchroniser resolves the metastability for a single bit. So control signals cross via synchronisers. So single bits are handled.

The multi-bit-coherence solution: for a multi-bit bus, synchronising each bit independently fails — because the bits could transition at slightly different times, so when sampled across the boundary, some bits might capture the old value and others the new — giving an incoherent combination (a value that never actually existed). E.g. crossing 0x07→0x08 (binary 0111→1000, all bits change), independent sampling could give 0x0F or 0x00 (garbage). So multi-bit data can't use per-bit synchronisers — it needs an async FIFO (write in domain A, read in domain B, with the FIFO's Gray-coded pointers crossed safely) or a req-ack handshake (signal "data ready" via a synchronised single bit, ensuring the data bus is stable before the destination reads it). So multi-bit data crosses coherently. So buses are handled specially. So CDC bridges exist because: asynchronous clock domains are a physical reality that must be crossed (the why); a naive crossing causes metastability (single bits) and incoherence (multi-bit) — correctness failures (the danger); so single-bit control crosses via multi-flop synchronisers (settle metastability) and multi-bit data crosses via async FIFOs / handshakes (coherent whole value) (the solution); at the cost of added latency (the synchroniser/FIFO cycles — the price). So CDC bridges are the required discipline for safely crossing AHB between asynchronous clocks. So this chapter is the safe-crossing method.

3. Mental Model

Model a CDC bridge as two people speaking different-rhythm languages needing a careful interpreter — you can't just shout words across (they'd catch them mid-syllable, garbled — metastability); for a simple yes/no signal, the interpreter waits for it to be clearly settled before relaying it (a synchroniser); and for a complex message (a multi-word phrase), the interpreter doesn't relay it word-by-word as each arrives (the words could mismatch — incoherent), but waits until the whole phrase is complete and stable, then hands it over as a unit (an async FIFO / handshake) — and all this careful relaying takes extra time (latency).

Two people (the two clock domains) speak at different, unsynchronized rhythms (asynchronous clocks) and need to communicate through a careful interpreter (the CDC bridge). You can't just shout words across directly — the listener, on their own rhythm, might catch a word mid-syllable (sampling a signal mid-transition), hearing something garbled and ambiguous (metastability — an unresolved, hovering value). So the interpreter is careful. For a simple yes/no signal (a single control bit), the interpreter waits until it's clearly settled — listens, confirms it's a clean yes or no (not a half-formed sound), then relays it (a multi-flop synchroniser — let the metastability settle before using the value). For a complex message — a multi-word phrase (a multi-bit data bus) — the interpreter does not relay it word-by-word as each arrives, because the words could mismatch (some old, some new — an incoherent phrase that was never actually said). Instead, the interpreter waits until the whole phrase is complete and stable, then hands it over as a coherent unit (an async FIFO or req-ack handshake — capture the whole stable value). And all this careful relaying — waiting for settling, assembling whole phrases — takes extra time (the CDC latency). So the interpreter never relays garbled or half-assembled messages; it waits for clarity and coherence, at the cost of some delay.

This captures the CDC bridge: the two different-rhythm speakers = the two asynchronous clock domains; shouting words across directly = naively sampling a signal across domains; catching a word mid-syllable, garbled = metastability; waiting for a yes/no to settle before relaying = the multi-flop synchroniser for single-bit control; not relaying a phrase word-by-word (mismatch) = not raw-sampling a multi-bit bus (incoherence); waiting for the whole stable phrase = the async FIFO / handshake for coherent data; the careful relaying taking extra time = the CDC latency. Wait for clarity (synchronise), assemble whole phrases (coherent data), accept the delay.

Watch a single-bit control signal synchronised across domains:

The model's lesson: wait for clarity, assemble whole phrases, accept the delay. In the waveform, the synchroniser lets the first flop's metastability settle before the second flop samples — giving domain B a clean value, safely, with a cycle of added latency.

4. Real Hardware Perspective

In hardware, a CDC bridge uses two-flop synchronisers for single-bit control, an async FIFO (with Gray-coded pointers) or a handshake for data, and is verified with CDC analysis tools — because CDC bugs are notoriously hard to find by simulation alone.

The two-flop synchroniser: the standard single-bit CDC primitive is a two-flop synchroniser — two flip-flops in series, clocked by the destination clock. The first flop samples the asynchronous signal (and may go metastable); by the next edge, it has settled (the mean-time-between-failure of metastability persisting beyond one cycle is astronomically long for typical settings); the second flop captures the settled value. So the destination gets a clean value, one-to-two cycles delayed. So in hardware, control bits cross via two-flop (or deeper, for higher reliability) synchronisers. So that's the single-bit primitive.

The async FIFO / handshake for data: for the multi-bit data (HADDR, HWDATA, HRDATA), an async FIFO is common: domain A writes the data into the FIFO (on A's clock), domain B reads it (on B's clock); the FIFO's read/write pointers cross the domains safely using Gray coding (only one bit changes per increment, so even if sampled across the boundary, the pointer is coherent — at most one bit is ambiguous, giving an adjacent valid value). So the FIFO decouples the domains and crosses the data coherently. Alternatively, a req-ack handshake: domain A drives the data and asserts a req (single bit, synchronised to B); when B sees req (synchronised), it reads the stable data (held by A) and asserts ack (synchronised back to A); A then proceeds. The handshake ensures the data is stable (held by A) while B reads it. So in hardware, data crosses via an async FIFO (Gray-pointer) or a req-ack handshake. So those are the multi-bit primitives.

The CDC verification: CDC bugs are insidious — they're timing/probability dependent (metastability is rare and random), so they don't reliably show up in simulation (which uses idealized timing). So CDC is verified with dedicated CDC analysis tools (static structural checks: every cross-domain signal goes through a proper synchroniser; multi-bit crossings use a FIFO/handshake; no unsynchronised paths) plus metastability-injection simulation. So in hardware, CDC is a verification discipline, not just a design one. So in hardware, a CDC bridge is built from two-flop synchronisers (single-bit control), async FIFOs / req-ack handshakes (multi-bit data, Gray-coded pointers), straddling the two domains — and verified with CDC analysis tools (because CDC bugs hide from normal simulation). So the hardware reality: synchronisers + FIFO/handshake + CDC verification. So building a correct CDC bridge requires the right primitives and the verification.

5. System Architecture Perspective

At the system level, CDC bridges are essential in any multi-clock SoC — and the CDC discipline is one of the highest-risk areas of chip design (CDC bugs are subtle, hard to find, and cause field failures), so it's treated with rigor.

The multi-clock necessity: modern SoCs are inherently multi-clock — different subsystems run at different frequencies for performance (fast CPU) and power (slow peripherals, DVFS domains) reasons, and external interfaces (USB, Ethernet, DDR, etc.) have their own clocks. So clock-domain crossings are unavoidable — and AHB (or any bus) crossing between domains needs a CDC bridge. So at the system level, CDC bridges are a standard, necessary component of multi-clock SoCs. So every multi-clock SoC has them. So CDC is ubiquitous.

The highest-risk-area point: CDC is one of the most dangerous areas of chip design because its bugs are uniquely hard: metastability is probabilistic and rare (it depends on the exact, random phase relationship at the crossing), so a CDC bug might pass all simulation and most silicon testing, then fail intermittently in the field (a rare metastable event corrupting data, causing a hang or error once in a while). And it's not fixable in software (it's a hardware timing issue). So CDC bugs are expensive (field failures, possible respins). So CDC is treated with extreme rigor — dedicated CDC tools, design rules (every crossing reviewed), formal/structural verification. So at the system level, CDC is a high-risk, high-rigor discipline. So it's taken very seriously. So CDC demands care.

The discipline as standard practice: because CDC is high-risk, the discipline (synchronise single-bit control, move multi-bit data via FIFO/handshake, verify with CDC tools) is standard, mandatory practice in any multi-clock design. There are established CDC primitives (two-flop synchroniser, async FIFO, handshake) and methodologies (CDC verification flows). The AHB CDC bridge applies this standard discipline to the bus crossing. So at the system level, CDC bridges are essential in multi-clock SoCs (unavoidable, ubiquitous), CDC is one of the highest-risk areas of chip design (probabilistic, simulation-hiding bugs → field failures → treated with extreme rigor and dedicated tools), and the CDC discipline (synchronisers, FIFOs/handshakes, verification) is standard mandatory practice — the AHB CDC bridge being one application. So CDC is where the bus meets the physical reality of multiple clocks and the rigorous discipline required to cross them safely. Understanding it — the metastability danger, the synchronise-control/coherent-data rules, the verification need — is essential for any multi-clock design, and CDC competence is a highly-valued skill (given the risk). So the CDC bridge is the capstone of Module 15: the bus's physical correctness across clock domains, requiring the full CDC discipline. So it completes the reset-and-clocking foundations. So the bus is physically robust across resets and clocks.

6. Engineering Tradeoffs

CDC bridges embody the synchronise-control, coherent-data, accept-latency discipline.

• Synchroniser (safe) vs direct sampling. A multi-flop synchroniser resolves metastability (safe) at the cost of latency (and area); direct sampling is "simpler" but unsafe (metastability corrupts). Always synchronise — no tradeoff (direct is wrong).
• Async FIFO / handshake (coherent) vs per-bit synchronisers. A FIFO/handshake crosses multi-bit data coherently (whole value stable) at the cost of the FIFO/handshake logic and latency; per-bit synchronisers fail (incoherent values). Use FIFO/handshake for multi-bit — no tradeoff (per-bit is wrong).
• Deeper synchroniser (more reliable) vs latency. A deeper synchroniser (3+ flops) gives higher metastability MTBF (more reliable) at more latency; two flops is the common default (sufficient for typical clocks). Deepen for very high reliability / fast clocks.
• CDC latency vs safety. The crossing adds latency (synchroniser + FIFO/handshake cycles) — an unavoidable cost of safe crossing. Accept it (account for it in timing/latency budgets); it's the price of correctness.

The throughline: a CDC bridge crosses AHB between asynchronous clock domains safely, with logic in each domain — synchronising single-bit control through a multi-flop synchroniser (let metastability settle), moving multi-bit data through an async FIFO or req-ack handshake (never raw-sampling a bus, which gives incoherent values), and accepting the added latency (synchroniser + FIFO/handshake cycles). The danger is metastability (a flop sampling mid-transition, settling unpredictably) and multi-bit incoherence (bits captured on different edges). In hardware: two-flop synchronisers, async FIFOs (Gray-coded pointers) / handshakes, verified with CDC analysis tools (CDC bugs hide from simulation). It's essential in multi-clock SoCs and one of the highest-risk, highest-rigor areas of chip design.

7. Industry Example

Bridge AHB from a fast CPU domain to a slow peripheral domain on an async clock.

An SoC has a CPU/bus domain (200 MHz) and a peripheral domain (50 MHz, asynchronous — separate PLL); the CPU accesses peripherals across a CDC bridge.

• The async boundary. The CPU (200 MHz) issues an AHB transfer to a peripheral (50 MHz). The two clocks are asynchronous (unrelated PLLs) — so the crossing needs a CDC bridge, not just a synchronous bridge.
• Control synchronisation. The bridge synchronises the control/handshake signals — e.g. a "transfer request" from the CPU domain crosses to the peripheral domain through a two-flop synchroniser (letting any metastability settle). Similarly, the peripheral's "done" signal synchronises back to the CPU domain.
• Data via handshake. The bridge moves the data (address, write-data, read-data) coherently — e.g. via a req-ack handshake: the CPU domain drives the address/write-data and holds it stable, asserts req (synchronised to the peripheral domain); the peripheral domain, on seeing the synchronised req, reads the stable data and runs the peripheral access; on completion, it returns read-data and asserts ack (synchronised back to the CPU domain), with the read-data held stable. So the multi-bit data is never sampled while transitioning — it's held stable across the handshake.
• No raw-sampling. Crucially, the bridge does not just put the multi-bit address/data buses through per-bit synchronisers and sample them across the boundary — that would risk incoherent values. The handshake (or an async FIFO) ensures coherence.
• Added latency. The crossing adds latency — the synchroniser delays (a couple of cycles each way) plus the handshake round-trip. So a peripheral access through the CDC bridge is slower than a same-domain access (on top of the bridge/APB penalty, chapter 14.7). This latency is accepted (peripherals are latency-tolerant) and budgeted.
• CDC verification. The bridge is verified with CDC analysis tools — confirming every cross-domain signal goes through a proper synchroniser, the multi-bit data uses the handshake (not raw-sampling), and there are no unsynchronised paths. Because CDC bugs hide from normal simulation, this structural verification is essential.

The example shows the CDC bridge in action: crossing the asynchronous CPU↔peripheral boundary by synchronising control (two-flop synchronisers), moving data coherently (req-ack handshake with stable data, not raw-sampling), accepting the added latency, and verifying with CDC tools. This is how AHB safely crosses asynchronous clock domains. This is CDC in practice.

8. Common Mistakes

9. Interview Insight

CDC bridges is a high-value interview topic — the metastability danger, the synchronise-control/coherent-data rules (especially never-raw-sample-a-bus), and the verification need are the signals.

The answer that lands gives the danger and the rules: "When an AHB master in one clock domain needs to reach a slave in a different, asynchronous clock domain — unrelated clocks, no fixed phase — you can't just wire the signals across, because of metastability: when a signal generated in one domain is sampled by a flop clocked by the other, and it changes near that clock edge, the flop can go metastable, its output hovering between 0 and 1 and settling unpredictably. So you use a CDC bridge with three rules. First, synchronise single-bit control: control and handshake signals cross through a multi-flop synchroniser, typically two flops in the destination clock — the first flop may go metastable, but it settles before the second flop samples it, giving a clean value one or two cycles later. Second, and critically, move multi-bit data coherently: you must never directly sample a multi-bit bus across the domains, even with per-bit synchronisers, because the bits can be captured on different edges — some old, some new — giving an incoherent value that was never valid. For example, a counter going from 0x07 to 0x08 flips all the bits, and a cross-domain sample could catch 0x0F. So multi-bit data goes through an async FIFO, where only Gray-coded pointers cross, or a req-ack handshake, where the source holds the data stable while the destination reads it. Third, accept the added latency from the synchronisers and FIFO/handshake. And you verify all this with CDC analysis tools, because CDC bugs are probabilistic and hide from normal simulation — they cause rare, intermittent field failures otherwise." The metastability danger, the synchronise-control/never-raw-sample-a-bus rules, and the verification need are the senior signals.

10. Practice Challenge

Reason from CDC bridges.

1. The danger. Explain metastability and why direct cross-domain sampling is unsafe.
2. Single-bit control. Explain how a two-flop synchroniser handles a control signal.
3. Read the waveform. From Figure 2, explain how the synchroniser lets metastability settle before the clean value is used.
4. Multi-bit data. Explain why per-bit synchronisers fail for a bus and what to use instead.
5. Verification. Explain why CDC bugs hide from simulation and how they're caught.

11. Key Takeaways

• A CDC bridge crosses AHB between asynchronous clock domains safely — with logic in each domain, applying the CDC discipline (the danger is metastability and multi-bit incoherence).
• Synchronise single-bit control — through a multi-flop synchroniser (2+ flops in the destination clock), letting metastability settle (clean value, +1-2 cycles).
• Move multi-bit data coherently — NEVER raw-sample a multi-bit bus (different bits captured on different edges → incoherent value that was never valid; per-bit synchronisers don't fix it). Use an async FIFO (Gray-coded pointers) or a req-ack handshake (source holds data stable).
• Accept the added latency — synchroniser + FIFO/handshake cycles; the price of safe crossing (budget for it).
• Verify with CDC analysis tools — CDC bugs are probabilistic and hide from simulation (causing rare, intermittent field failures); structural CDC verification (every crossing synchronised, no raw bus samples) is essential.
• It's essential and high-risk — every multi-clock SoC needs CDC bridges; CDC is one of the highest-risk, highest-rigor areas of chip design. CDC competence is a highly-valued skill.

12. What Comes Next

This completes Module 15 — Reset and Clocking. You now understand HRESETn's semantics, reset-safe transfers, reset during a transfer, clock gating, low-power implications, and CDC bridges — the reset and clocking foundations that keep AHB transactions whole and the bus physically robust. The next module turns to building AHB in RTL:

• Module 16 — AHB RTL Design (coming next) — implementing AHB masters, slaves, decoders, arbiters, and the bridge in RTL, with the design patterns and pitfalls.

To revisit the clocking pieces this builds on, see Clock Gating Considerations and HRESETn Behavior; for the bridge that often crosses domains, see Peripheral Selection.