AMBA AHB · Module 20

Case Study: CPU to SRAM

A worked case study tracing a CPU load and store through an AHB system to on-chip SRAM — the baseline AHB transaction. The CPU is the AHB master (drives the address phase); the AHB interconnect's address decoder maps the address to the SRAM's HSEL and routes HREADY and read data back; the SRAM is the AHB slave (captures the address, responds in the data phase). For an on-chip single-cycle SRAM this is the fastest path — zero wait states, a load completing one cycle after its address phase — and the pipeline lets a load's data phase overlap the next access's address phase, so loads and stores stream back-to-back. The SRAM uses the captured address (not the live HADDR) in the data phase.

Module 20 puts the protocol to work on real systems — tracing actual transactions end-to-end through an AHB fabric. We start with the simplest and most fundamental path: a CPU load/store to on-chip SRAM. This is the baseline AHB transaction — the one everything else builds on. The cast: the CPU is the AHB master (it issues a load or store by driving the address phase); the AHB interconnect contains the address decoder (it maps HADDR to the SRAM's HSEL, and routes the SRAM's HREADYOUT back as the shared HREADY and its read data onto HRDATA); and the SRAM is the AHB slave (it captures the address phase and responds in the data phase — returning read data for a load, accepting write data for a store, driving HREADYOUT). For an on-chip single-cycle SRAM, this is the fastest path — zero wait states, a load completing one cycle after its address phase — and the pipeline lets a load's data phase overlap the next access's address phase, so loads and stores stream back-to-back with no idle cycle. The one thing the SRAM (like any slave) must get right: use the captured address from the address phase in the data phase — not the live HADDR, which has already advanced to the next transfer. This chapter traces a load and a store, cycle by cycle.

1. What Is It?

This case study traces a CPU load/store to SRAM — the baseline AHB transaction. The path:

CPU (master) — issues a load/store by driving the address phase (HADDR/HTRANS/HWRITE); captures read data / drives write data in the data phase.
Interconnect (decoder) — maps HADDR to the SRAM's one-hot HSEL; routes HREADY and HRDATA back to the CPU (the read-data mux on the decoded select).
SRAM (slave) — captures the address phase; in the data phase, returns read data (load) or writes (store), driving HREADYOUT (high for zero-wait).
The result — for single-cycle SRAM, zero wait states; the pipeline streams back-to-back loads/stores.

Figure 1 — the CPU-to-SRAM path over AHB. The CPU (AHB master) issues a load or store by driving the address phase. The AHB interconnect contains the address decoder: it maps HADDR to the SRAM's one-hot HSEL, and routes the SRAM's HREADYOUT back as the shared HREADY and its read data onto HRDATA (the read-data mux on the decoded select). The SRAM (AHB slave) captures the address phase and, in the data phase, returns read data for a load or accepts write data for a store, driving HREADYOUT high for a zero-wait SRAM or low to insert wait states for a slower memory. Forward (blue): address and control flow from the CPU through the decoder to the SRAM. Backward (green): read data and HREADY flow from the SRAM through the interconnect back to the CPU. For an on-chip single-cycle SRAM this is the fastest path — often zero wait states — and the pipeline means the address phase and data phase are one cycle apart.

So the CPU-to-SRAM path is the bare AHB transaction — master drives the address, decoder selects the slave, slave responds a cycle later — made concrete. The value of tracing it is seeing the whole protocol in its simplest form: the pipeline (address phase then data phase), the decode (HADDR → HSEL), the slave response (HRDATA/HREADY), and the capture discipline (the SRAM uses the registered address). And because the SRAM is fast (single-cycle), there are no wait states to complicate the picture — so the pipeline shows cleanly: a stream of loads and stores, each one cycle of address phase, each completing one cycle later, overlapping. So this case study is the baseline. So it shows the protocol's core, concretely.

CPU → SRAM is the baseline AHB transaction: CPU (master) drives the address phase, the interconnect decoder maps HADDR → HSEL and routes HREADY/HRDATA back, the SRAM (slave) captures the address and responds a cycle later. Single-cycle SRAM = zero wait states; the pipeline streams loads/stores back-to-back. The SRAM uses the CAPTURED address in the data phase

The CPU-to-SRAM case study in one frame: the baseline AHB transaction, traced end-to-end. The cast: the CPU (the AHB master — issues a load (read) or store (write) by driving the address phase: HADDR = the target address, HWRITE = 0 for a load / 1 for a store, HTRANS = NONSEQ for a single access; then in the data phase it captures the read data (load) or drives the write data on HWDATA (store)); the AHB interconnect (containing the address decoder — it looks at HADDR and asserts the SRAM's HSEL (one-hot, from the address map), and routes the SRAM's HREADYOUT back as the shared HREADY and its read data onto HRDATA via the read-data mux on the decoded select); and the SRAM (the AHB slave — it captures the address-phase control, and in the data phase returns read data (HRDATA) for a load or writes HWDATA to mem[captured address] for a store, driving HREADYOUT high for a zero-wait single-cycle SRAM, or low to insert wait states for a slower memory). The trace: (load) address phase — CPU drives the load address, decoder asserts HSEL; data phase (one cycle later) — SRAM drives HRDATA and HREADY high, CPU captures the value. (store) address phase — CPU drives the store address with HWRITE high; data phase — CPU drives HWDATA, SRAM writes it, drives HREADY high. The result: for a single-cycle SRAM, zero wait states — a load completes one cycle after its address phase; and because the bus is pipelined, the store's address phase overlaps the load's data phase, so back-to-back loads/stores stream with no idle cycle. The key discipline: the SRAM uses the captured address (registered from the address phase) in the data phase — not the live HADDR (which has advanced to the next transfer). The takeaway: this is the bare AHB transaction — master drives the address, decoder selects, slave responds a cycle later, pipeline streams accesses — the foundation every other case study builds on.

2. Why Does It Exist?

This case study exists because the CPU-to-memory path is the most common transaction in any system (every instruction fetch, every load, every store) — so understanding it concretely is foundational — and because, being the simplest path (a fast slave, no bridge, one master), it shows the core protocol cleanly, without the complications that later case studies add.

The the most common transaction is the root: a CPU constantly accesses memory — instruction fetches, loads, stores. So the CPU-to-SRAM path is the most frequent AHB transaction by far. So understanding it is foundational. So this case study exists to ground the most common path. So memory access is everywhere. So trace it first.

The the simplest path shows the core cleanly is the pedagogy: with a fast (single-cycle) slave, no bridge, and one master, there are no wait states, no protocol translation, no arbitration to cloud the picture. So the core protocol — pipeline, decode, slave response, capture — shows cleanly. So this case study exists to show the core without complications. So it's the clean baseline. So start simple.

The the baseline for the rest is the structure: the later case studies add complications — a bridge (CPU-to-peripheral), a second master (DMA), arbitration. So they build on this baseline. So understanding this first is necessary for the rest. So this case study exists as the foundation of the module. So it's the starting point. So this case study exists because: the CPU-to-memory path is the most common transaction (the root); the simplest path shows the core cleanly (no waits/bridge/arbitration — the pedagogy); and it's the baseline for the rest (the later case studies add complications — the structure). So the CPU-to-SRAM case study is the foundation — tracing the most common transaction in its simplest form to show the core protocol concretely. So this chapter grounds the protocol in a real path. So trace the baseline, then build on it.

3. Mental Model

Model the CPU-to-SRAM path as mailing a letter across town and getting a reply, in a city with a fast, local post office. You (the CPU) write the address on an envelope and drop it in the box (drive the address phase). The sorting office (the decoder) reads the address and routes it to the right neighborhood branch (asserts HSEL). The local branch (the SRAM) is fast — it handles your request the next day and sends the reply straight back (responds in the data phase, zero wait states). Because the system is pipelined, you can drop your next letter the same day the previous reply is being delivered — so a stream of letters and replies flows continuously. And the branch always works from the address you wrote on the envelope (the captured address), not from whatever envelope is currently on top of the pile (the live bus). It's the simplest possible round-trip: write the address, get routed, get a fast reply.

A city postal system with a fast, local post office. You (the CPU) write the address on an envelope and drop it in the box (drive the address phase — HADDR/control). The sorting office (the decoder) reads the address and routes it to the right neighborhood branch (asserts the SRAM's HSEL from the address map). The local branch (the SRAM) is fast — it handles your request and sends the reply straight back the next day (responds in the data phase, one cycle later, zero wait states for a single-cycle SRAM). Because the system is pipelined, you can drop your next letter the same day the previous reply is being delivered (the next access's address phase overlaps the current access's data phase) — so a stream of letters and replies flows continuously (back-to-back loads/stores, no idle cycle). And the branch always works from the address you wrote on the envelope (the captured address) — not from whatever envelope is currently on top of the pile (the live HADDR, which has advanced). It's the simplest possible round-trip: write the address, get routed, get a fast reply.

This captures the CPU-to-SRAM path: writing the address on the envelope and dropping it = the CPU driving the address phase; the sorting office routing to a branch = the decoder asserting HSEL; the fast local branch replying next day = the SRAM responding in the data phase one cycle later (zero wait states); dropping the next letter while the reply is delivered = the pipeline overlapping the next address phase with the current data phase; the branch working from the envelope's address, not the top of the pile = the SRAM using the captured address, not the live HADDR. Write the address (address phase), get routed (decode), get a fast reply (data phase) — and the pipeline keeps the letters streaming.

Here is the load-then-store, traced as the model describes:

CPU load then store to a zero-wait SRAM (pipelined, back-to-back)

4 cycles

Figure 2 — a CPU load then store to SRAM, traced. Cycle 1: the CPU drives the load address A0 (HWRITE low, HTRANS NONSEQ); the decoder asserts the SRAM's HSEL. Cycle 2: the SRAM returns the read data D0 on HRDATA with HREADY high (zero wait states), and the CPU drives the store address A1 (HWRITE high) — the store's address phase overlapping the load's data phase (the pipeline). Cycle 3: the CPU drives the store write data on HWDATA, the SRAM writes mem[A1], HREADY high. The load's data and the store's data both arrive one cycle after their address; the SRAM uses the captured address to steer each. A single-cycle SRAM streams these back-to-back with no idle cycle.

The model's lesson: write the address (address phase), get routed (decode), get a fast reply (data phase) — and the pipeline streams the accesses. In the figure, the load's data (D0) and the store's address (A1) land in the same cycle — the pipeline overlapping them — so the fast SRAM streams the two accesses back-to-back.

4. Real Hardware Perspective

The substance behind the trace is the protocol structure you've learned — so each step maps to a chapter, applied to this concrete path.

The the decode and the pipeline: in hardware — the decoder (combinational on HADDR) asserts the SRAM's HSEL; the pipeline means the SRAM captures the address phase and responds in the data phase. So the trace applies the decode and pipeline structure (see Address Decoding, HSEL, Pipelined Operation). So it's the routing + timing. So decode, then respond a cycle later.

Figure 3 — a CPU load then store traced over AHB. The load: step 1, address phase — the CPU drives the load address on HADDR with HWRITE low and HTRANS NONSEQ; the decoder asserts the SRAM's HSEL. Step 2, data phase one cycle later — the SRAM drives the read data on HRDATA with HREADY high; the CPU captures the loaded value. The store: step 3, address phase — the CPU drives the store address with HWRITE high; the decoder asserts HSEL. Step 4, data phase — the CPU drives the write data on HWDATA and the SRAM writes it, driving HREADY high. Because the bus is pipelined, the store's address phase overlaps the load's data phase, so back-to-back load then store stream with no idle cycle. Read data and write data both live in the data phase, one cycle after their address, and the SRAM uses the captured address to steer each access.

The the SRAM slave and HREADY: in hardware — the SRAM captures the address into a register and uses it in the data phase (the read mux / write enable); it drives HREADYOUT high for a single-cycle SRAM (zero wait), or low for a slower memory. So the trace applies the slave and HREADY structure (see AHB-Lite Slave, Memory Slave, HRDATA Muxing, What HREADY Means). So in practice, the CPU-to-SRAM path is the protocol you've learned applied to the most common transaction — decode, pipeline, slave response, capture, HREADY. So in practice, know the structure and trace it on this path. So that's the foundation.

5. System Architecture Perspective

At the system level, the CPU-to-SRAM path is the critical performance path — it's the most frequent transaction, so its latency (zero wait states for on-chip SRAM) directly sets the CPU's memory performance, and its pipelined streaming is why AHB is fast enough to be the CPU's main bus.

The the critical performance path: the CPU accesses memory constantly — so the latency of the CPU-to-SRAM path is critical. Zero wait states (single-cycle SRAM) means the CPU isn't stalled on memory. So at the system level, this path's latency directly sets CPU performance. So make it fast. So it's performance-critical.

The pipelining is why AHB works as a CPU bus: without pipelining, every memory access would have a dead cycle between address and data — halving throughput. With it, accesses stream back-to-back. So pipelining is why AHB is fast enough to be the CPU's main bus. So at the system level, the pipeline (seen here) is essential. So it streams. So at the system level, the CPU-to-SRAM path is the critical performance path (its zero-wait latency sets CPU memory performance) and its pipelined streaming is why AHB works as the CPU's main bus. So this path is where AHB's performance matters most — making zero wait states and pipelined streaming the keys to fast CPU memory access. So keep this path fast, and let the pipeline stream. So the CPU-to-SRAM path is performance-critical.

6. Engineering Tradeoffs

Tracing the CPU-to-SRAM path surfaces the design points of the most common transaction.

Zero-wait SRAM vs slower memory. A single-cycle SRAM gives zero wait states (fastest); a slower memory inserts waits (HREADYOUT low). For the CPU's hot path, fast SRAM is worth the area.
Captured address vs live HADDR. The SRAM must use the captured address in the data phase; using the live HADDR is the #1 bug. Capture it.
Pipelined streaming vs per-access stall. The pipeline lets accesses stream (no dead cycle); not exploiting it would halve throughput. Stream them.
On-chip SRAM vs off-chip / behind a bridge. On-chip SRAM is the fast path (this chapter); off-chip or behind a bridge (later chapters) is slower (waits, translation). Put hot data on-chip.

The throughline: the CPU-to-SRAM path is the baseline AHB transaction — CPU (master) drives the address, interconnect decoder selects the SRAM (HSEL), SRAM (slave) responds a cycle later (HRDATA/HREADY). For a single-cycle SRAM it's zero wait states, and the pipeline streams loads/stores back-to-back. The key discipline: the SRAM uses the captured address (not live HADDR) in the data phase. At the system level, it's the critical performance path — its zero-wait latency sets CPU performance, and its pipelined streaming is why AHB works as the CPU's main bus.

The CPU-to-SRAM path is the critical performance path: it's the most frequent transaction, so its latency (zero wait states for single-cycle on-chip SRAM) directly sets CPU memory performance, and the pipeline streaming back-to-back accesses is why AHB is fast enough to be the CPU's main bus. Keep hot data in fast on-chip SRAM; the SRAM must use the captured address

Why this baseline path matters so much at the system level: it's the most frequent transaction, so its performance is critical. A CPU accesses memory on almost every cycle — instruction fetches, loads, stores. So the CPU-to-SRAM path is exercised constantly, and its latency directly determines how fast the CPU runs. For an on-chip single-cycle SRAM, the path is zero wait states: the CPU drives the address, and one cycle later (the data phase) the data is there — no stalls. That's why you put the CPU's hot data and code in fast on-chip SRAM (or a cache backed by it): the access latency is minimal. And the pipeline is essential here: because the next access's address phase overlaps the current access's data phase, a stream of loads and stores runs back-to-back with no idle cycle — so the CPU can issue one memory access per cycle in the best case. Without pipelining, every access would have a dead cycle (address, then data, then next address), roughly halving memory throughput — and AHB wouldn't be fast enough to be the CPU's main bus. So the pipeline (which you see cleanly on this zero-wait path) is why AHB works for the CPU. The design implications: (1) keep the CPU's hot data/code in fast (single-cycle, on-chip) SRAM — off-chip memory or memory behind a bridge (later chapters) is much slower (wait states, protocol translation); (2) the SRAM must use the captured address in the data phase (the #1 slave bug is using the live HADDR); (3) exploit the pipeline — stream accesses, don't stall between them. This path is the baseline — simple (one master, fast slave, no bridge) — precisely because it's the performance-critical core that everything else (caches, bridges, DMA) is built around. (See Memory Slave, Pipelined Operation, and What HREADY Means.)

7. Industry Example

A concrete trace — a CPU running code from on-chip SRAM.

A microcontroller's CPU executes a small routine whose code and data live in on-chip SRAM, connected over AHB-Lite.

Instruction fetch (load). The CPU drives the instruction address on HADDR, HWRITE low, HTRANS NONSEQ. The decoder sees the address falls in the SRAM's region and asserts the SRAM's HSEL.
The fetch completes a cycle later. In the data phase, the SRAM — single-cycle — drives the instruction word on HRDATA with HREADY high. The CPU captures the instruction. Zero wait states: the fetch took one cycle of address phase plus the data a cycle later, streaming.
A load instruction executes. The routine does a load from a data address. The CPU drives that address (HWRITE low) in its address phase — which overlaps the data phase of the previous fetch, because the bus is pipelined. A cycle later, the SRAM returns the data word on HRDATA.
A store instruction executes. The routine writes a result. The CPU drives the store address with HWRITE high; a cycle later, in the data phase, it drives the value on HWDATA, and the SRAM writes it to mem[captured address], driving HREADY high.
It all streams. Because every SRAM access is zero-wait and the bus is pipelined, the fetches, loads, and stores stream back-to-back — roughly one access per cycle — so the CPU runs at full speed from SRAM, never stalling on memory.
The capture discipline holds throughout. Every SRAM access uses the address captured in its address phase — never the live HADDR, which by the data phase is already the next access's address. This is what keeps each load returning the right data and each store landing at the right address.

The example shows the baseline path in action: CPU drives the address, decoder selects the SRAM, SRAM responds a cycle later with zero wait states, and the pipeline streams fetches/loads/stores back-to-back. This is the most common transaction, running at full speed. This is the foundation the rest of the module builds on.

8. Common Mistakes

CPU-to-SRAM misconceptions

"Address and data are in the same cycle." No — pipelined: the data is one cycle after the address. (Even on this fast path.)
"The SRAM uses the live HADDR for the access." No — it uses the captured address (registered in the address phase). Using the live HADDR writes/reads the wrong location.
"Zero wait states means address and data together." No — zero wait states means HREADY is high (no stretch); the data still arrives one cycle after the address.
"Each access stalls until the next." No — the pipeline lets the next address phase overlap the current data phase; accesses stream.
"The CPU drives HREADY." No — the SRAM drives HREADYOUT (routed back as HREADY); the CPU waits on it (here, it's always high).
"All memory is this fast." No — on-chip single-cycle SRAM is the fast path; off-chip or behind a bridge memory is slower (waits, translation).

9. Interview Insight

The CPU-to-SRAM path is the baseline — tracing it cleanly (master drives address, decoder selects, slave responds a cycle later, pipeline streams) shows you understand the core protocol concretely.

Figure 4 — the CPU-to-SRAM case study in one card: path — CPU (master) drives the address, the interconnect decoder selects (HSEL), the SRAM (slave) responds a cycle later; fastest path — on-chip single-cycle SRAM is zero wait states, a load completing one cycle after its address phase; pipelined — a load's data phase overlaps the next access's address phase, so loads/stores stream back-to-back; the SRAM uses the captured address (not live HADDR) in the data phase, and a slower memory inserts waits via HREADYOUT low. Takeaway: the bare AHB transaction — master drives the address, decoder selects, slave responds a cycle later, pipeline streams accesses.

If asked to trace a CPU memory access over AHB, walk it cleanly: the CPU drives the address phase (HADDR/HTRANS/HWRITE), the decoder asserts the SRAM's HSEL, and one cycle later — the data phase — the SRAM returns the read data (or accepts the write), driving HREADY high. Stress the pipeline (the next access's address phase overlaps the current data phase, so accesses stream), the zero wait states (single-cycle SRAM), and the capture discipline (the SRAM uses the registered address, not the live HADDR). That clean trace — the baseline AHB transaction — signals you understand the core protocol concretely, and gives you the foundation to trace the harder paths (bridge, DMA) that add complications.

10. Practice Challenge

Practice tracing the baseline path.

The load. Trace a CPU load from SRAM cycle by cycle — address phase, decode, data phase a cycle later.
The store. Trace a store — note HWDATA arrives in the data phase, and the SRAM writes mem[captured address].
The streaming. Show how a load then store overlap (the pipeline) and stream back-to-back on a zero-wait SRAM.
The capture. Explain what breaks if the SRAM uses the live HADDR in the data phase.
The slow case. Show how a slower memory inserts wait states (HREADYOUT low) and how the trace changes.

11. Key Takeaways

The CPU-to-SRAM path is the baseline AHB transaction — CPU (master) drives the address, interconnect decoder selects the SRAM (HSEL), SRAM (slave) responds a cycle later (HRDATA/HREADY).
Single-cycle SRAM = zero wait states — a load completes one cycle after its address phase; HREADY stays high.
The pipeline streams accesses — a load's data phase overlaps the next access's address phase, so loads/stores run back-to-back with no idle cycle.
The SRAM uses the captured address — registered in the address phase, used in the data phase. Using the live HADDR is the #1 slave bug (silent corruption).
It's the critical performance path — the most frequent transaction; its zero-wait latency sets CPU performance, and pipelining is why AHB works as the CPU's main bus.
It's the foundation — the later case studies (bridge, DMA) add complications (waits, translation, arbitration) to this baseline.

12. What Comes Next

You can now trace the baseline path. The next case studies add real-world complications:

CPU to Peripheral via AHB/APB Bridge (next) — the same CPU access, but to a peripheral through a bridge (wait states, the latency penalty).
DMA Master on AHB, and the rest — a second master, arbitration, and full system fabrics.

To revisit the structure this trace applies, see Pipelined Operation, Address Decoding, Memory Slave, HRDATA Muxing, and What HREADY Means.