Bridge FSM (RTL)

Every slave so far has been single-resource: a simple slave (16.1), a register bank (16.2), a memory (16.3). Their control collapsed to combinational logic plus a capture — no real state machine. This chapter builds the capstone: a slave whose control cannot collapse, because one upstream transfer expands into a multi-cycle downstream transaction — the bridge-style slave, which needs a real control FSM. The canonical example is an AHB-to-APB bridge (an AHB slave on its upstream side that drives an APB peripheral bus downstream), and we'll use it as the vehicle — but the focus here is the RTL control-FSM pattern, not the protocol details of APB. (The full AHB-to-APB bridge — APB's two-phase SETUP/ACCESS protocol, PSEL/PENABLE/PREADY, multi-peripheral fan-out — is a separate subject; this chapter is the reusable control-FSM skeleton.) The pattern, generically: IDLE → on a captured real transfer, SETUP (drive the downstream command — address/control/write-data) → ACCESS (the downstream transaction executes, one or more cycles) → COMPLETE (capture the downstream result, drive HREADYOUT high for one cycle). Throughout SETUP/ACCESS, the FSM holds the upstream master (HREADYOUT low — wait states), because the upstream transfer can't finish until the downstream one does. The key insight: this FSM reuses every block from 16.4–16.9 (capture, HREADYOUT, write/read commit, HRESP), sequenced into a multi-cycle controller. This chapter builds that capstone control FSM.

1. What Is It?

The bridge FSM is a slave control state machine that maps one upstream transfer onto a multi-cycle downstream transaction, holding the upstream side until it completes. Its parts:

• Why a real FSM — a simple slave collapses to combinational logic; a bridge can't, because one upstream transfer becomes a multi-cycle downstream sequence needing sequencing.
• IDLE → SETUP → ACCESS → COMPLETE — capture a real transfer, drive the downstream command, run the downstream transaction (multi-cycle), then complete the upstream transfer.
• Hold the upstream side — throughout SETUP/ACCESS, drive HREADYOUT low (wait states), since the upstream transfer can't finish until downstream does.
• Reuses every block — capture (16.7), HREADYOUT generation (16.4), write/read commit gated to completion (16.8/16.9), HRESP mapping (16.6).

So the bridge FSM is the rate-matching controller between a fast upstream bus and a slow/multi-cycle downstream resource. The simple slaves (16.1–16.3) responded in one cycle (or a few waits) because their resource (registers, SRAM) was directly accessible — their "FSM" collapsed to a capture plus combinational logic. A bridge is different: its resource is another bus transaction (the downstream APB access), which itself takes multiple cycles (a SETUP phase, an ACCESS phase, a wait for the peripheral). So the bridge cannot respond in one cycle — it must run the downstream transaction to completion, holding the upstream master (wait states) the whole time, then complete. That multi-cycle sequencing is what requires a real FSM — IDLE → SETUP → ACCESS → COMPLETE. And crucially, that FSM is built from the blocks you already have: it captures the upstream transfer (16.7), generates HREADYOUT to hold/release (16.4), commits writes / produces reads on completion (16.8/16.9), and maps the downstream response to HRESP (16.6). So the bridge FSM is the assembly of the slave building blocks into a multi-cycle controller. So it's the capstone slave. So it's where the blocks come together.

2. Why Does It Exist?

The bridge FSM exists because some slaves front a multi-cycle downstream resource (another bus, a slow peripheral) — so a single upstream transfer expands into a multi-cycle sequence that must be sequenced by a real state machine, holding the upstream master throughout.

The multi-cycle downstream resource is the root: a bridge doesn't hold the data itself (like a register or SRAM) — it forwards the access to a downstream resource (an APB peripheral bus, a slow external interface). That downstream access is itself a multi-cycle transaction — e.g. APB's two-phase SETUP/ACCESS, plus wait cycles for the peripheral. So a single upstream AHB transfer triggers a multi-cycle downstream sequence. So the bridge can't respond in one cycle (unlike 16.1–16.3) — it must drive and track the downstream transaction across cycles. So the bridge FSM exists to sequence the multi-cycle downstream access. So it needs states. So multi-cycle resources need an FSM.

The the upstream must be held drives the wait states: since the upstream transfer can't complete until the downstream one does, the bridge must hold the upstream master — insert wait states (HREADYOUT low) — for the entire duration of the downstream sequence. So the FSM's states (SETUP, ACCESS) each drive HREADYOUT low (holding), and only COMPLETE drives it high (releasing). So the FSM exists to manage the holding — coordinating the upstream HREADYOUT with the downstream progress. So it's a rate-matching role. So holding requires sequencing. So the FSM bridges the rate gap.

The assembly of the building blocks is the deeper why: the bridge is where the individual slave outputs (16.4–16.9) must work together across multiple cycles — capture the transfer (16.7), hold/release via HREADYOUT (16.4), commit the write / produce the read on completion (16.8/16.9), map the response (16.6) — all sequenced. A simple slave does these in one cycle (collapsed); a bridge does them across the multi-cycle sequence (an FSM). So the bridge FSM exists as the integration point — assembling the blocks into a coherent multi-cycle controller. So it's the capstone. So the bridge FSM exists because: some slaves front a multi-cycle downstream resource (a single upstream transfer expands into a multi-cycle sequence — the why); the upstream master must be held throughout (wait states across SETUP/ACCESS — the rate-matching); and the building blocks must be sequenced together across cycles (the assembly — capture, HREADYOUT, commit, HRESP). So the bridge FSM is the multi-cycle slave controller that maps a fast upstream transfer onto a slow downstream transaction — the capstone that integrates every slave block into a real state machine. So this chapter is where the slave RTL comes together. So bridges need the FSM.

3. Mental Model

Model the bridge FSM as a hotel concierge taking your one request, then carrying out a multi-step errand on your behalf while you wait at the desk. You ask for theater tickets (one upstream transfer). The concierge can't hand them over instantly — they have to call the box office (SETUP), wait while the box office checks availability and processes it (ACCESS, several minutes), and only then hand you the tickets (COMPLETE). Throughout, they keep you politely waiting at the desk ("one moment, please" — HREADYOUT low), and only say "here you are" once the whole errand is done.

A hotel concierge desk (the bridge) between you, the guest (the upstream master) and the outside world (the downstream resource). You make one request — "theater tickets, please" (a single upstream transfer). A simple clerk handling something on-hand (like a room key — a register/SRAM) would hand it over instantly. But the concierge's request isn't on-hand — it requires a multi-step errand with an outside party (the box office — a downstream bus transaction). So the concierge can't respond in one beat. Instead: first they pick up the phone and place the order — "box office, I need two tickets for tonight" (SETUP — driving the downstream command: which show, how many). Then they wait on the line while the box office checks availability and processes the payment — which takes several minutes (ACCESS — the downstream transaction executing, multi-cycle; sometimes the box office says "hold please" — downstream wait states, the self-loop). Throughout all of this, the concierge keeps you politely waiting at the desk — "one moment, please, I'm on it" — not dismissing you, not saying "done" yet (holding the upstream master with HREADYOUT low — wait states). Only when the box office confirms and the tickets are secured does the concierge turn to you and say "here you are" — handing over the tickets (COMPLETE — capturing the downstream result, driving HREADYOUT high for one beat to release you). And if the box office says "sold out" (a downstream error), the concierge relays "I'm sorry, that's not available" (mapping the downstream response to HRESP = ERROR). So the concierge takes one request, runs a multi-step errand with the outside party, holds you waiting the whole time, and completes only when the errand is done — relaying the outcome.

This captures the bridge FSM: your single request = one upstream AHB transfer; the concierge = the bridge control FSM; the on-hand clerk = a simple slave (collapsed, instant); the multi-step errand with the box office = the multi-cycle downstream transaction; placing the order on the phone = SETUP (driving the downstream command); waiting on the line while it processes = ACCESS (the downstream transaction executing, multi-cycle); "hold please" from the box office = downstream wait states (the ACCESS self-loop); keeping you waiting at the desk = holding the upstream master (HREADYOUT low) throughout; "here you are" once done = COMPLETE (HREADYOUT high for one cycle, releasing); relaying "sold out" = mapping the downstream response to HRESP. Take one request, run the multi-step errand, hold the guest waiting, complete and relay only when done.

Watch one upstream transfer span the multi-cycle downstream sequence, holding the master:

The model's lesson: take one request, run the multi-step errand, hold the guest waiting, and complete only when done. In the waveform, the single upstream transfer is stretched across the downstream sequence — HREADYOUT low through SETUP/ACCESS (holding), high only on COMPLETE (releasing).

4. Real Hardware Perspective

In hardware, the bridge is a state register plus next-state/output logic; SETUP/ACCESS drive the downstream interface and hold HREADYOUT low; COMPLETE captures the downstream result and pulses HREADYOUT high; and the whole thing reuses the capture/commit/HRESP logic across the states.

The state register and transitions: the FSM is a state register (state_q ∈ {IDLE, SETUP, ACCESS, COMPLETE}) with next-state logic: IDLE → SETUP on a captured real transfer; SETUP → ACCESS after driving the command; ACCESS → ACCESS while the downstream side is busy (e.g. downstream PREADY low), ACCESS → COMPLETE when the downstream transaction finishes; COMPLETE → IDLE (or → SETUP for a pipelined next transfer). So in hardware, it's a standard Moore/Mealy FSM. So it's a state machine. So that's the control core.

The HREADYOUT held across the states: the HREADYOUT output is a function of the state — low in SETUP and ACCESS (holding the upstream master — the downstream isn't done), high in COMPLETE (releasing — the transfer finishes), high in IDLE (ready for the next). This is exactly the HREADYOUT generation of 16.4 — driven by the FSM state rather than a simple counter. So in hardware, HREADYOUT is the FSM's hold/release output. So it reuses 16.4. So the pace is FSM-driven.

The reused blocks sequenced across states: the other slave blocks appear within the states. The capture (16.7) happens at IDLE → SETUP (capturing the upstream addr_q/write_q to drive downstream). The write commit (16.8) — here, driving the downstream write data — happens in SETUP/ACCESS (the downstream write executes); the upstream "commit" is the downstream completing. The read production (16.9) — capturing the downstream read data and presenting it on the upstream HRDATA — happens at COMPLETE. The HRESP mapping (16.6) — translating the downstream response (e.g. APB PSLVERR) to the upstream HRESP (OKAY/ERROR, two-cycle) — happens at COMPLETE. So in hardware, the bridge is the slave blocks (16.4–16.9) instantiated and sequenced by the FSM across SETUP/ACCESS/COMPLETE. The FSM is the conductor; the blocks are the players. So in hardware, a bridge is a state machine driving a downstream interface, reusing the capture/HREADYOUT/commit/HRESP logic across its states. So building a bridge is sequencing the blocks you have. So the FSM orchestrates the blocks.

5. System Architecture Perspective

At the system level, the bridge is the rate-matching gateway between a fast high-performance bus and a slow peripheral domain — and its FSM is where the fast/slow boundary is managed, making it both a necessary SoC component and the clearest demonstration that the slave building blocks compose.

The fast/slow gateway: SoCs have a fast bus (AHB — for the CPU, memory, DMA) and a slow peripheral bus (APB — for UARTs, timers, GPIO). The bridge is the gateway between them — it lets the fast bus reach the slow peripherals without slowing the fast bus for everyone (only the bridged accesses pay the slow-peripheral cost). So at the system level, the bridge is the fast-to-slow gateway — a standard SoC component (every microcontroller has one). So it's the peripheral gateway. So bridges connect the domains.

The boundary management: the bridge's FSM is where the rate mismatch is absorbed. The fast bus expects its protocol (AHB pipelining); the slow bus has its protocol (APB phases); the bridge FSM translates — accepting the fast transfer, holding it (wait states) while running the slow transaction, then completing. So the boundary between the fast and slow domains is managed by the bridge FSM — it's the translation/rate-matching point. So at the system level, the bridge FSM is the domain-boundary manager. So it absorbs the mismatch. So the boundary lives in the FSM.

The composition demonstration: the bridge is the proof that the slave building blocks (16.4–16.9) compose into arbitrary slave complexity. A simple slave uses them collapsed (one cycle); a bridge uses them sequenced (multi-cycle FSM); a more complex slave (a cache controller, a DMA-fronting slave) uses them in a richer FSM. So the bridge demonstrates the generality of the building-block approach — the same capture/HREADYOUT/commit/HRESP blocks, assembled by an FSM of any complexity. So at the system level, the bridge is the rate-matching gateway between fast and slow bus domains (a standard SoC component — the peripheral gateway), its FSM is the domain-boundary manager (absorbing the fast/slow rate mismatch — translating and holding), and it's the clearest demonstration that the slave building blocks compose (the same blocks, sequenced by an FSM, scale to arbitrary slave complexity). So the bridge is where the slave RTL culminates — a real, multi-cycle controller built entirely from the foundational blocks, managing the most important boundary in the SoC's bus hierarchy. (The detailed bridge architecture — APB protocol, peripheral fan-out, setup/access timing — is a separate subject; here it's the RTL control-FSM capstone.) So compose the blocks into the bridge FSM, and you've built the hardest slave.

6. Engineering Tradeoffs

The bridge FSM embodies the multi-cycle, hold-the-upstream, compose-the-blocks design.

• Real FSM vs collapsed logic. A bridge needs a real FSM (multi-cycle downstream sequencing); a simple slave collapses to combinational logic. Use an FSM only when the slave is genuinely multi-cycle (a bridge, a cache, a complex peripheral).
• Hold with wait states vs buffer/post. Holding the upstream master (wait states) through the downstream access is simplest and correct for a basic bridge; a posted-write buffer (accept the upstream write, complete it immediately, drain to downstream later) improves upstream throughput at the cost of buffering/ordering complexity. Start with holding; add posting if throughput demands.
• Reuse blocks vs bespoke logic. Reusing the capture/HREADYOUT/commit/HRESP blocks (16.4–16.9) sequenced by the FSM is clean and verified; bespoke per-bridge logic risks re-introducing the subtle bugs. Compose from the verified blocks.
• Minimal states vs explicit per-phase states. A minimal FSM (few states) is compact; explicit per-phase states (one per downstream phase) are clearer and easier to verify. Favor clarity for a capstone block.

The throughline: a bridge FSM is the capstone slave controller — a real state machine (IDLE → SETUP → ACCESS → COMPLETE) that maps one upstream transfer onto a multi-cycle downstream transaction, because the bridge fronts a slow/multi-cycle resource (another bus) rather than holding data directly. Throughout SETUP/ACCESS, it holds the upstream master with wait states (HREADYOUT low — chapter 6.2), since the upstream transfer can't finish until the downstream one does; COMPLETE releases it (HREADYOUT high, one cycle) and maps the downstream result to the upstream HRDATA/HRESP. It reuses every block — capture (16.7), HREADYOUT (16.4), write/read commit gated to completion (16.8/16.9), HRESP (16.6) — sequenced by the FSM. It's the fast/slow gateway of the SoC and the proof that the slave blocks compose into arbitrary complexity. (The full bridge protocol is a separate subject.)

7. Industry Example

Trace a CPU write and read through a bridge to a slow peripheral — the rate-matching in action.

A CPU on AHB accesses a UART on a downstream (APB-style) peripheral bus through a bridge.

• The write (CPU → UART config register). The CPU issues one AHB write to the UART's config address. The bridge: IDLE → SETUP captures the upstream transfer and drives the downstream command (the peripheral address, control, and the write data); HREADYOUT low (hold the CPU). SETUP → ACCESS: the downstream write executes — the peripheral bus asserts its enable and the UART accepts the write, possibly over several cycles (downstream wait states); HREADYOUT stays low. ACCESS → COMPLETE: the downstream write is accepted (downstream PREADY); the bridge drives HREADYOUT high for one cycle — the CPU's write completes. The CPU was held for the whole downstream sequence.
• The read (CPU ← UART status register). The CPU issues one AHB read. IDLE → SETUP: capture, drive the downstream read command; HREADYOUT low. SETUP → ACCESS: the downstream read executes — the UART produces its status; HREADYOUT low until the data is ready. ACCESS → COMPLETE: the downstream read data is valid (downstream PREADY); the bridge captures it and presents it on the upstream HRDATA, driving HREADYOUT high — the CPU samples the status. Critically, the bridge drives HREADYOUT high only when the downstream read data is genuinely ready — not before (which would return garbage).
• A downstream error. If the UART signals a downstream error (e.g. APB PSLVERR), the bridge maps it to the upstream HRESP = ERROR (the two-cycle ERROR — 16.6) at COMPLETE. The CPU takes a bus fault.
• The hold. Throughout both transfers, the CPU is held (HREADYOUT low) for the entire downstream sequence — the bridge rate-matches the fast CPU to the slow UART. Only the bridged accesses pay the cost; the rest of the AHB runs full-speed.
• The reused blocks. The bridge captured (16.7), generated HREADYOUT (16.4) from its state, committed the (downstream) write / presented the (downstream) read on completion (16.8/16.9), and mapped HRESP (16.6) — all sequenced by the FSM.

The example shows the bridge FSM rate-matching a fast CPU to a slow peripheral: one upstream transfer stretched across the multi-cycle downstream sequence, the CPU held throughout, completion only on genuine downstream completion (no early release), and the reused slave blocks sequenced by the FSM. This is the capstone slave at work. (The APB-side protocol detail is a separate subject.) This is where the blocks compose.

8. Common Mistakes

9. Interview Insight

The bridge FSM is a senior RTL interview topic — the multi-cycle-needs-an-FSM insight, the hold-the-upstream discipline, and the reuses-every-block framing are the signals.

The answer that lands gives the multi-cycle insight and the hold discipline: "A bridge is the most complex slave because, unlike a simple slave or a memory that holds the data directly, a bridge fronts a downstream resource — another bus, like APB — and one upstream transfer expands into a multi-cycle downstream transaction. So it can't collapse to combinational logic; it needs a real control FSM. The skeleton is: from idle, capture a real upstream transfer and go to a setup state that drives the downstream command — the address, control, and for a write the write data. Then an access state where the downstream transaction actually executes, which takes one or more cycles. Then a complete state that captures the downstream read data or response and finishes the upstream transfer. The critical discipline is that throughout setup and access, you hold the upstream master by driving HREADYOUT low — inserting wait states — because the single upstream transfer can't complete until the downstream transaction finishes. You only drive HREADYOUT high, completing the upstream transfer, when the downstream side genuinely completes. Releasing early is the classic bug: for a read, you'd return garbage because the downstream data isn't back yet; for a write, you'd break ordering by telling the master it's done before downstream accepted it. And the elegant part is that the bridge reuses every building block — the address capture, the HREADYOUT generation, the write and read commit gated to completion, the HRESP mapping from the downstream response — all sequenced by the FSM. The FSM is the conductor; the blocks are the players. So a bridge is really a rate-matching control FSM between a fast and a slow bus." The multi-cycle-needs-an-FSM insight, the hold-the-upstream discipline (and the early-release bug), and the reuses-every-block framing are the senior signals.

10. Practice Challenge

Build and reason from the bridge FSM.

1. Why an FSM. Explain why a bridge needs a real control FSM while a simple slave/memory doesn't (the multi-cycle downstream expansion).
2. The states. Describe the IDLE → SETUP → ACCESS → COMPLETE skeleton and what happens in each state.
3. Read the waveform. From Figure 2, explain how one upstream transfer spans the downstream sequence, and how HREADYOUT holds then releases.
4. Hold discipline. Explain why the bridge holds the upstream master for the entire downstream sequence, and the early-release bug (reads and writes).
5. Reuse. Explain how the bridge reuses the capture, HREADYOUT, commit, and HRESP blocks, sequenced by the FSM.

11. Key Takeaways

• A bridge needs a real control FSM — one upstream transfer expands into a multi-cycle downstream transaction, which can't collapse to combinational logic (unlike 16.1–16.3).
• The skeleton is IDLE → SETUP → ACCESS → COMPLETE — capture the upstream transfer, drive the downstream command, run the downstream transaction (multi-cycle), then complete.
• Hold the upstream master throughout SETUP/ACCESS (HREADYOUT low — wait states), since the upstream transfer can't finish until downstream does; release (HREADYOUT high, one cycle) only on COMPLETE.
• Complete only on genuine downstream completion — releasing early returns garbage reads (data not back) and breaks ordering/error-reporting on writes. The multi-cycle generalization of the HREADYOUT/commit discipline (16.3/16.4/16.8).
• It reuses every slave block — capture (16.7), HREADYOUT (16.4), write/read commit gated to completion (16.8/16.9), HRESP mapping (16.6) — sequenced by the FSM (the conductor; the blocks are the players).
• It's the fast/slow gateway of the SoC and the proof the slave blocks compose into arbitrary complexity. (The full AHB-to-APB bridge protocol is a separate subject.)

12. What Comes Next

You now can build the capstone multi-cycle slave controller. The final chapter of this module packages the building blocks for reuse:

• Reusable AHB RTL Templates (next) — drop-in, parameterised AHB RTL building blocks (capture, slave, memory, bridge skeletons) you can instantiate and configure.

To revisit the blocks the bridge sequences, see Address / Control Capture, HREADYOUT Generation, Write FSM, and HRESP Generation; for crossing clock domains in a bridge, see CDC Bridges.