AMBA AHB · Module 20

Case Study: CPU to Peripheral via Bridge

A worked case study tracing a CPU peripheral-register access through a bridge — the same AHB transaction shape as the SRAM path, but stretched. To the CPU, the bridge is just another AHB slave: the decoder maps the peripheral's address to the bridge's HSEL, the CPU drives the address phase as usual. But the bridge, on its AHB side a slave that captures the access, runs the slower downstream peripheral-bus transaction and holds HREADY low across the whole downstream access — so the CPU waits. Where the SRAM responded with zero wait states, the bridge inserts many wait states for the same logical read — the bridge latency penalty. The design lesson: keep high-frequency traffic off the bridge, put only slow peripherals behind it. The downstream protocol's own details are a separate subject.

The second case study takes the same CPU access from the SRAM baseline — but sends it to a peripheral behind a bridge. The shape is identical (a CPU read/write over AHB); what changes is the latency. To the CPU, the bridge is just another AHB slave: the decoder maps the peripheral's address to the bridge's HSEL, and the CPU drives the address phase exactly as before. But the bridge, on its AHB side a slave that captures the access, then runs the slower downstream peripheral-bus transaction — and holds HREADY low across the whole downstream access, so the CPU waits. Where the SRAM responded with zero wait states, the bridge inserts many wait states for the same logical read — the bridge latency penalty. The CPU simply holds its address stable and waits, exactly as it would for any slow slave inserting wait states. The design lesson: peripheral accesses through a bridge are correct but slow, which is why you keep high-frequency traffic off the bridge and put only slow, low-bandwidth peripherals behind it. (The downstream protocol's own details are a separate subject — here, the bridge is simply the slow AHB slave that stretches HREADY.) This chapter traces the access and contrasts it with the SRAM path.

1. What Is It?

This case study traces a CPU peripheral-register access through a bridge — the same AHB shape as SRAM, stretched. The path:

CPU (master) — drives the address phase exactly as for SRAM (HADDR/HTRANS/HWRITE). It doesn't know there's a bridge.
Decoder — maps the peripheral's address to the bridge's HSEL. To the CPU, the bridge is just an AHB slave in that region.
Bridge (slow AHB slave) — captures the access; runs the slower downstream transaction; holds HREADY low across the whole downstream access; completes with HREADY high + the data.
The contrast — where SRAM was zero-wait, the bridge inserts many wait states (the latency penalty). Same shape, much slower.

Figure 1 — the CPU-to-peripheral path through the bridge. The CPU (AHB master) drives the address phase as usual. The AHB interconnect's decoder maps the peripheral's address to the bridge's HSEL — to the CPU, the bridge looks like just another AHB slave. The bridge, on its AHB side a slave that captures the access, runs the slower downstream peripheral-bus transaction, holding HREADY low across the whole downstream access so the CPU waits. The peripheral register sits on the slow downstream bus. Forward: the address flows from CPU to decoder to bridge, then the bridge drives the downstream transaction to the peripheral; back: the data and a stretched HREADY come through the bridge to the CPU. Unlike the SRAM path, the bridge inserts wait states for the whole downstream transaction — much slower (the bridge penalty). The downstream protocol is a separate subject; here the bridge is just the slow AHB slave that stretches HREADY.

So this case study shows the same transaction facing a slow slave — and the power of the AHB wait-state mechanism: the CPU's access works unchanged, the bridge just holds HREADY low until the slow downstream completes. The value of tracing it is seeing that the protocol absorbs the latency transparently — the CPU doesn't need to know the slave is slow or that there's a bridge; it just waits on HREADY. And it makes the bridge penalty concrete: the same logical read that took one cycle to SRAM takes many cycles through the bridge. So this case study is the slow-path counterpart to the SRAM baseline. So it shows wait states and the bridge penalty, concretely.

CPU → peripheral via bridge = the SRAM transaction, stretched. To the CPU, the bridge is just another AHB slave (decoder → bridge HSEL). The bridge captures the access, runs the slow downstream transaction, and holds HREADY low the whole time — so the CPU waits. Same shape as SRAM, but MANY wait states (the bridge penalty). Keep high-frequency traffic off the bridge

The CPU-to-peripheral case study in one frame: the same AHB transaction as the SRAM baseline — stretched by a slow slave (the bridge). The path: the CPU (the AHB master) drives the address phase exactly as for SRAM — it drives the peripheral register's address on HADDR, HWRITE, HTRANS; it has no idea there's a bridge. The decoder maps that address to the bridge's HSEL (the bridge occupies the peripheral region of the address map) — so to the CPU, the bridge is just another AHB slave. The bridge — on its AHB side a slave — captures the access (the address-phase control), then runs the slower downstream peripheral-bus transaction (IDLE → SETUP → ACCESS → DONE, as covered in the bridge subject), and holds HREADY low across the whole downstream access — so the CPU waits, holding its address stable. When the downstream peripheral completes (returns the register value for a read, accepts the write), the bridge drives HREADY high for one cycle with the data on HRDATA, and the CPU captures it. The contrast with SRAM: where the single-cycle SRAM responded with zero wait states (data one cycle after the address), the bridge inserts many wait states (the whole downstream transaction's worth) for the same logical read — the bridge latency penalty. The key insight: the CPU's behavior is unchanged — it drives the same address phase and waits on HREADY, exactly as it would for any slow slave; the AHB wait-state mechanism absorbs the latency transparently. The design lesson: peripheral accesses through a bridge are correct but slow, so you keep high-frequency traffic (CPU code/data) on fast memory (SRAM/cache) and put only slow, low-bandwidth peripherals (UART, timer, GPIO) behind the bridge. The scope note: the downstream protocol's own details (its handshake, its timing) are a separate subject — here, the bridge is simply the slow AHB slave that stretches HREADY.

2. Why Does It Exist?

This case study exists because peripheral access is a fundamental, ubiquitous path (every system has slow peripherals reached through a bridge) — and because it demonstrates the AHB wait-state mechanism absorbing latency transparently (the CPU's access works unchanged against a slow slave) — and it makes the bridge penalty concrete (the same access, many times slower).

The peripheral access is ubiquitous is the root: every real system has slow peripherals — UARTs, timers, GPIO — reached through a bridge (to keep them off the fast bus). So CPU-to-peripheral is a fundamental, common path. So understanding it is necessary. So this case study exists to ground the peripheral path. So peripherals are everywhere. So trace this path.

The wait states absorb latency transparently is the lesson: the power of the AHB wait-state mechanism is that the CPU's access works unchanged against a slow slave — the CPU just waits on HREADY. So this case study demonstrates the transparency — the master doesn't need to know the slave is slow. So it exists to show the wait-state mechanism in action. So it's the wait-state demo. So watch HREADY stretch.

The the bridge penalty made concrete is the contrast: the same logical access that took one cycle to SRAM takes many cycles through the bridge. So this case study makes the penalty concrete — quantifying the cost of crossing a bridge. So it exists to show the penalty. So it's the cost lesson. So keep traffic off the bridge. So this case study exists because: peripheral access is ubiquitous (the root); wait states absorb latency transparently (the CPU's access works unchanged — the lesson); and the bridge penalty is made concrete (the same access, many times slower — the contrast). So the CPU-to-peripheral case study is the slow-path counterpart — demonstrating the wait-state mechanism and the bridge penalty on a fundamental path. So this chapter grounds peripheral access. So watch the wait states, and note the penalty.

3. Mental Model

Model the CPU-to-peripheral-via-bridge path as ordering from a kitchen versus grabbing a snack from the counter. Grabbing a pre-made snack from the counter (the SRAM access) is instant — you reach over and it's there. Ordering a cooked dish (the peripheral access) goes through a waiter (the bridge): you give the same order the same way (drive the same address phase), but the waiter takes it to the kitchen, the kitchen cooks it (the slow downstream transaction), and the waiter makes you wait at your table the whole time (holds HREADY low) — you don't get up, you just wait. When the dish is ready, the waiter brings it back (HREADY high, data returned). You ordered exactly the same way you'd grab a snack; the difference is purely that the kitchen is slow and the waiter makes you wait. And because the kitchen is slow, you don't order your fast snacks through the waiter — you keep those at the counter.

A restaurant with two ways to get food. Grabbing a pre-made snack from the counter (the SRAM access) is instant — you reach over and it's there (zero wait states, data a cycle later). Ordering a cooked dish (the peripheral access) goes through a waiter (the bridge): you give the same order the same way (drive the same address phase — the CPU doesn't order differently for a peripheral), but the waiter takes it to the kitchen, the kitchen cooks it (the slow downstream transaction), and the waiter makes you wait at your table the whole time (holds HREADY low) — you don't get up, you just wait (the CPU holds its address and waits on HREADY). When the dish is ready, the waiter brings it back (HREADY high, data returned). You ordered exactly the same way you'd grab a snack — the only difference is the kitchen is slow and the waiter makes you wait. And because the kitchen is slow, you don't order your fast snacks through the waiter — you keep those at the counter (keep high-frequency traffic on fast memory, not through the bridge).

This captures the path: grabbing a snack from the counter = the zero-wait SRAM access; ordering a dish through the waiter = the peripheral access through the bridge; giving the order the same way = the CPU driving the same address phase (it doesn't know there's a bridge); the waiter taking it to the slow kitchen = the bridge running the slow downstream transaction; making you wait at your table the whole time = holding HREADY low (the CPU waits, address held); the waiter bringing the dish back = the bridge completing with HREADY high and the data; keeping fast snacks at the counter = keeping high-frequency traffic off the bridge. Order the same way (same address phase), wait while the slow kitchen cooks (HREADY low), get it when ready (HREADY high) — and keep fast traffic off the waiter.

Here is the peripheral read traced, with its wait states:

A peripheral read through the bridge — many wait states (vs SRAM's zero)

5 cycles

Figure 2 — a CPU peripheral-register read through the bridge. Cycle 1: the CPU drives the peripheral register address (HWRITE low, HTRANS NONSEQ); the decoder asserts the bridge's HSEL — to the CPU this is just a slave. Cycles 2-4: the bridge has captured the access and is running the slow downstream transaction, so it holds HREADY low — these are wait states, and the CPU holds its address stable and waits. Cycle 5: the downstream peripheral returns the register value; the bridge drives HREADY high with the data on HRDATA, and the CPU captures it. The same read that took one cycle to SRAM takes several through the bridge — the latency penalty — but the CPU's behaviour is unchanged: it just waits on HREADY.

The model's lesson: order the same way (same address phase), wait while the slow kitchen cooks (HREADY low), get it when ready (HREADY high) — and keep fast traffic off the bridge. In the figure, the CPU's access is identical to the SRAM case in its address phase — the only difference is the bridge holds HREADY low for several cycles (the slow downstream), and the CPU waits. The protocol absorbs the latency transparently.

4. Real Hardware Perspective

The substance behind the trace is the wait-state and bridge structure you've learned — so each step maps to a chapter, applied to this path.

The the decode and the wait states: in hardware — the decoder asserts the bridge's HSEL (the bridge is a slave in the peripheral region); the bridge drives HREADY low to insert wait states while the downstream runs, and the CPU (master) holds its address and waits. So the trace applies the decode and wait-state structure (see Address Decoding, Slave Wait States, What HREADY Means). So it's the routing + pacing. So decode to the bridge, then wait.

Figure 3 — a peripheral register read through the bridge, traced. Step 1, address phase: the CPU drives the peripheral register address with HWRITE low; the decoder asserts the bridge's HSEL (to the CPU, the bridge is a slave in that region). Step 2: the bridge captures the access, starts the downstream transaction, and drives HREADY low. Step 3, access: the downstream runs for several cycles while HREADY stays low; the CPU holds its address stable and waits. Step 4, completion: the downstream returns the register value, the bridge drives HREADY high for one cycle with the data on HRDATA, and the CPU captures it. The contrast bar: the SRAM read completed in one cycle (zero wait states), while the bridge read took many cycles of wait states for the same logical read — the latency penalty. Same AHB transaction shape, stretched by the bridge.

The the bridge and the penalty: in hardware — the bridge is an AHB slave running a downstream FSM (covered in the bridge subject); the penalty is the downstream latency the CPU waits through. So the trace applies the bridge and penalty structure (see Bridge FSM RTL, Bridge Penalty, AHB vs APB vs AXI). So in practice, this path is the wait-state mechanism applied to a bridge — the CPU's access unchanged, the bridge stretching HREADY, the penalty the cost. So in practice, know the wait-state/bridge structure and trace it here. So that's the slow path.

5. System Architecture Perspective

At the system level, this path reveals the memory/peripheral hierarchy — fast memory (SRAM/cache) for high-frequency CPU traffic, slow peripherals behind a bridge for low-frequency control — and why that split exists: the bridge penalty makes peripheral access expensive, so you minimize it.

The the hierarchy: a real system separates fast memory (SRAM/cache, on the fast bus, zero-wait) from slow peripherals (behind a bridge, many waits). So the system has a hierarchy — fast path for hot traffic, slow path for peripherals. So at the system level, this path reveals the hierarchy. So know the split. So it's the architecture.

The why the split exists: the bridge penalty makes peripheral access expensive (many cycles). So you don't put high-frequency traffic through the bridge (it would stall the CPU constantly). You put only low-frequency control accesses (configuring a UART, reading a status register) there — where the penalty is tolerable (it happens rarely). So at the system level, the penalty drives the split. So minimize bridge traffic. So it's penalty-driven. So at the system level, this path reveals the memory/peripheral hierarchy (fast memory for hot traffic, slow peripherals behind a bridge) and why the split exists (the bridge penalty makes peripheral access expensive, so you minimize it). So this path is where the system's hierarchy shows — making the wait-state transparency (the access works unchanged) and the bridge penalty (the cost that drives the split) the keys to understanding the fast/slow architecture. So keep hot traffic fast, peripherals behind the bridge, and minimize the crossing. So this path reveals the hierarchy.

6. Engineering Tradeoffs

Tracing the peripheral-via-bridge path surfaces the fast/slow design points.

Behind the bridge vs on the fast bus. Slow peripherals go behind the bridge (off the fast bus, saving its bandwidth); fast memory stays on the fast bus. Put each where it belongs.
Wait-state transparency vs master complexity. The CPU's access works unchanged (just waits on HREADY) — the wait-state mechanism absorbs the latency, no special master logic. That transparency is the point.
The bridge penalty vs minimizing crossings. Each bridge access is many cycles; minimizing bridge traffic (don't poll a peripheral in a tight loop; use interrupts/DMA) avoids the penalty.
Posted writes vs waiting. If the downstream allows posted writes, the bridge can complete the AHB write early (buffer it) so the CPU doesn't wait on writes (covered in the bridge subject).

The throughline: the CPU-to-peripheral path is the SRAM transaction stretched by a slow slave — the CPU drives the same address phase, the decoder selects the bridge (an AHB slave), and the bridge holds HREADY low across the whole downstream transaction. The contrast: zero-wait SRAM vs many-wait bridge — the bridge penalty. The key insight: the CPU's access is unchanged (it just waits on HREADY); the wait-state mechanism absorbs the latency transparently. The design lesson: keep high-frequency traffic off the bridge, put only slow, low-bandwidth peripherals behind it.

The bridge access is the same AHB transaction as SRAM, just stretched: the CPU drives the same address phase and waits on HREADY — the wait-state mechanism absorbs the slow downstream latency transparently. The bridge penalty (many wait states) is why you keep high-frequency traffic off the bridge and only put slow peripherals behind it. To the CPU, the bridge is just another (slow) AHB slave

What this path teaches at the system level: the AHB wait-state mechanism lets a fast master talk to a slow slave transparently — and the cost of doing so (the bridge penalty) is what shapes the system's fast/slow hierarchy. The transparency first: the CPU drives the peripheral access exactly as it drives an SRAM access — same address phase, same signals. It has no special logic for "this is a slow peripheral behind a bridge." The only thing that happens is the bridge holds HREADY low while the slow downstream transaction runs, and the CPU waits, holding its address — exactly the same HREADY-waiting behavior it has for any slave. So the wait-state mechanism absorbs the latency transparently: the master doesn't need to know the slave is slow. That's a powerful property — it lets you mix fast and slow slaves on the same bus without complicating the master. The cost second: the bridge access is many cycles (the whole downstream transaction), where the SRAM access was one — the bridge penalty. This expense is why you build a hierarchy: put the CPU's high-frequency traffic (code, data, stack) in fast memory (SRAM, or a cache backed by it) on the fast bus, and put slow, low-bandwidth peripherals (UART, timer, GPIO) behind the bridge — where the penalty is tolerable because those accesses are rare (you configure a UART once, not every cycle). And you minimize the crossings: don't poll a peripheral status register in a tight loop (each poll pays the penalty) — use interrupts or DMA instead. If the downstream allows posted writes, the bridge can buffer a write and complete the AHB side early, so the CPU doesn't wait on writes (a bridge optimization, covered in the bridge subject). So this path is where the fast/slow split shows: the wait-state transparency makes the split possible (mix slaves freely), and the bridge penalty makes the split necessary (keep hot traffic fast). (See Slave Wait States, Bridge Penalty, and What HREADY Means.)

7. Industry Example

A concrete trace — a CPU configuring a UART behind a bridge.

A microcontroller's CPU sets up a UART (a slow peripheral) that lives behind an AHB-to-peripheral bridge.

The CPU writes a UART config register. It drives the UART register's address on HADDR with HWRITE high, HTRANS NONSEQ — exactly as it would write to SRAM. It has no idea there's a bridge.
The decoder selects the bridge. The address falls in the peripheral region, so the decoder asserts the bridge's HSEL. To the CPU, the bridge is just an AHB slave there.
The bridge captures and runs the downstream write. The bridge captures the access and begins the slow downstream transaction to the UART register. It drives HREADY low — the CPU now waits, holding its address and write data stable.
The CPU waits through the wait states. For several cycles, HREADY stays low while the downstream transaction runs. The CPU is stalled on this one access — far longer than an SRAM write would take. This is the bridge penalty.
The bridge completes the write. When the downstream write lands, the bridge drives HREADY high, completing the AHB write. The CPU moves on.
The lesson plays out. Because this is a config write — done once at setup, not in a hot loop — the penalty is tolerable. But if the firmware were to poll a UART status register in a tight loop, every poll would pay this penalty, stalling the CPU repeatedly — which is why you'd use a UART interrupt instead. And the CPU's code itself runs from fast SRAM, never through the bridge.

The example shows the slow path in action: the CPU's access is unchanged, the bridge holds HREADY low through the slow downstream transaction, and the CPU waits — correct but slow. The penalty is tolerable for rare config accesses but avoided for hot traffic. This is how peripheral access works, and why the hierarchy exists.

8. Common Mistakes

CPU-to-peripheral-via-bridge misconceptions

"The CPU accesses a peripheral differently than memory." No — it drives the same address phase. The bridge (a slave) handles the difference; the CPU just waits on HREADY.
"The bridge completes the AHB access immediately, then does the peripheral write." No — it holds HREADY low until the downstream completes (unless it's a posted write). Completing early would lose data.
"Peripheral access is as fast as SRAM." No — it's many wait states (the bridge penalty) vs SRAM's zero. Much slower.
"The CPU needs special logic for slow slaves." No — the wait-state mechanism is transparent; the CPU just waits on HREADY, same as any slave.
"Polling a peripheral in a tight loop is fine." No — each poll pays the bridge penalty. Use interrupts or DMA.
"Put any slave behind the bridge." No — only slow, low-bandwidth peripherals. Fast, high-frequency memory stays on the fast bus.

9. Interview Insight

This path shows the wait-state mechanism and the bridge penalty — tracing it (same address phase, bridge holds HREADY low, CPU waits) shows you understand how AHB absorbs slow-slave latency transparently.

Figure 4 — the CPU-to-peripheral-via-bridge case study in one card: path — CPU drives the address, the decoder selects the bridge (a slow AHB slave), the bridge runs the downstream transaction and holds HREADY low, the peripheral register is on the slow downstream bus; contrast with SRAM — where SRAM was zero-wait, the bridge holds HREADY low for the whole downstream access, so a register access is many cycles not one (the bridge latency penalty), and the CPU waits with its address held; design — keep high-frequency traffic off the bridge, put only slow low-bandwidth peripherals behind it. Takeaway: peripheral access through a bridge is correct but slow — the bridge is the slow AHB slave that stretches HREADY.

If asked to trace a CPU access to a peripheral over AHB, emphasize that the CPU does the same thing as for memory — it drives the same address phase and waits on HREADY; the bridge is just a slow AHB slave that holds HREADY low while it runs the slow downstream transaction. Contrast the latency: zero-wait SRAM vs many-wait bridge (the bridge penalty). Stress the transparency (the wait-state mechanism absorbs the latency, no special master logic) and the design lesson (keep high-frequency traffic off the bridge). That shows you understand how AHB mixes fast and slow slaves transparently — and why the system's fast/slow hierarchy exists. (The downstream protocol's own details are a separate subject; here, the bridge is the slow AHB slave that stretches HREADY.)

10. Practice Challenge

Practice tracing the slow path.

The trace. Trace a CPU peripheral read through the bridge — same address phase, bridge holds HREADY low, CPU waits, completion.
The contrast. Compare the latency with the SRAM read (zero-wait vs many-wait) — the bridge penalty.
The transparency. Explain why the CPU needs no special logic for a slow peripheral (it just waits on HREADY).
The hierarchy. Explain why high-frequency traffic stays on fast memory and only slow peripherals go behind the bridge.
Minimizing the penalty. List techniques (interrupts, DMA, posted writes, caching) that avoid paying the penalty on hot traffic.

11. Key Takeaways

CPU-to-peripheral via bridge is the SRAM transaction stretched — the CPU drives the same address phase; the decoder selects the bridge (an AHB slave); the bridge holds HREADY low across the whole downstream transaction.
To the CPU, the bridge is just another (slow) AHB slave — it drives the same access and waits on HREADY; no special logic.
The wait-state mechanism absorbs latency transparently — the master doesn't need to know the slave is slow; HREADY uniformly paces it.
The bridge penalty — many wait states vs SRAM's zero for the same logical access. Peripheral access is correct but slow.
The penalty shapes the hierarchy — keep high-frequency traffic on fast memory; put only slow, low-bandwidth peripherals behind the bridge; minimize crossings (interrupts, DMA, posted writes).
The downstream protocol is a separate subject — here, the bridge is simply the slow AHB slave that stretches HREADY.

12. What Comes Next

You can now trace the slow (bridged) path. The next case study adds a second master:

DMA Master on AHB (next) — a DMA engine acting as a second AHB master, introducing arbitration and handover into the real system.
The rest of the module — boot ROM, debug, full MCU fabrics, and low-power access.

To revisit the structure this trace applies, see Slave Wait States, What HREADY Means, Bridge FSM RTL, Bridge Penalty, and Address Decoding. For the bridge as its own subject, see Bridge FSM RTL.