AMBA AHB · Module 14

Throughput

Defining and computing AHB throughput — data moved per unit time = (bytes/beat × beats) ÷ total cycles × clock frequency. Peak = bus width × clock; real throughput is peak × efficiency (< 1), lowered by address-phase overhead, wait states, and idle cycles. Efficiency = data-carrying cycles ÷ total cycles, raised by bursts, fast slaves, and back-to-back transfers.

This opens Module 14 — Performance, which turns the AHB protocol into numbers: how fast can it move data, and why is a real system slower than the peak? The starting metric is throughput — the data moved per unit time. The formula:

throughput = (bytes/beat × beats) ÷ total_cycles × f_clk

The peak is simply bus width × clock frequency (e.g. a 32-bit bus at 100 MHz → 4 bytes × 100 M = 400 MB/s) — achieved only with no overhead and no wait states. But real throughput = peak × efficiency, where efficiency < 1, lowered by three things: address-phase overhead (the address phase carries no data — a lone beat is only ~50% efficient; bursts amortise it), wait states (each HREADY-low cycle carries no data), and idle cycles (gaps where no transfer is issued). So efficiency = data-carrying cycles ÷ total cycles — and it rises toward 1 with bursts, fast slaves, and back-to-back transfers. This chapter defines throughput, computes the peak, and explains the efficiency gap — the foundation for the rest of the module (which quantifies each efficiency loss).

1. What Is It?

Throughput is the rate of data transfer — bytes (or bits) per second — that the bus achieves. Its components:

The formula: throughput = (bytes/beat × beats) ÷ total_cycles × f_clk.
Peak: bus_width × f_clk — the maximum, with every cycle carrying data (no overhead, no waits).
Real: peak × efficiency, where efficiency = data-carrying cycles ÷ total cycles (< 1).
Efficiency losses: address-phase overhead, wait states, idle cycles.

Figure 1 — the throughput formula and its terms. throughput = (bytes/beat × beats) ÷ total_cycles × f_clk. bytes/beat = the data bus width (32-bit → 4 bytes). total_cycles = address-phase overhead + 1 per beat + wait states. Peak = bus_width × f_clk (e.g. 32-bit @ 100 MHz = 400 MB/s). Real throughput is lower because of address-phase overhead, wait states, and idle cycles.

So throughput is the delivered bandwidth — and it has a clean ceiling (peak = width × frequency) and a gap (the efficiency loss) below it. The peak is set by the physical parameters (how wide the data bus, how fast the clock) — it's the most data the bus could move if every cycle carried a beat. The real throughput is less, because not every cycle carries data: some cycles are the address phase (no data), some are wait states (slave not ready), some are idle (no transfer). So throughput analysis is fundamentally about the peak (width × clock) and the efficiency (what fraction of cycles actually carry data). So throughput is the data rate, bounded by width × clock and reduced by the non-data-carrying cycles.

throughput = (bytes/beat × beats) ÷ cycles × f_clk; peak = width × clock; real = peak × efficiency (data cycles ÷ total)

Throughput in one frame: the data rate = (bytes/beat × beats) ÷ total_cycles × f_clk. The peak is bus_width × f_clk (e.g. 32-bit @ 100 MHz = 400 MB/s) — every cycle carrying a data beat. Real throughput = peak × efficiency, where efficiency = data-carrying cycles ÷ total cycles (< 1). Three things lower efficiency: address-phase overhead (the address phase carries no data — a lone beat is ~50% efficient; bursts amortise it), wait states (each HREADY-low cycle carries no data), and idle cycles (gaps with no transfer). Efficiency rises toward 1 with bursts, fast slaves, and back-to-back transfers. So: peak = width × clock; the gap to real is the cycles that carry no data.

2. Why Does It Exist?

Throughput exists as the key performance metric because bandwidth-bound workloads (moving lots of data — DMA, streaming, memory copies) are limited by how fast the bus moves data, and quantifying it (peak + efficiency) lets engineers predict and optimize that rate.

The bandwidth-bound workloads drive the metric: many real tasks are about moving data — a DMA copying a buffer, streaming samples to memory, a CPU doing a memcpy. For these, the limiting factor is the rate at which the bus moves data — the throughput. So throughput is the metric for bandwidth-bound work. So it exists because data-movement performance matters. So quantifying throughput predicts how fast these tasks run.

The peak as the ceiling is the first half: the peak (width × clock) is the physical maximum — no design can exceed it (you can't move more than one bus-width of data per cycle). So the peak bounds the achievable throughput, set by the bus width and clock frequency — the two physical knobs. So to raise the ceiling, you widen the bus or raise the clock. So the peak exists as the hard upper bound, set by physical parameters. So throughput analysis starts with the peak.

The efficiency as the gap is the second half: real throughput is below peak because not every cycle carries data. The address phase carries control, not data (the AHB pipeline, chapter 5.x). Wait states (HREADY low) carry no data (the slave isn't ready). Idle cycles carry no data (no transfer issued). So the efficiency — the fraction of cycles that do carry data — captures the gap. So real = peak × efficiency. So efficiency exists to quantify the loss below peak. And the reason efficiency matters (and is improvable) is that the losses are reducible: bursts amortise the address-phase overhead (one address phase for many data beats), fast slaves reduce wait states, back-to-back transfers eliminate idle gaps. So efficiency is the optimizable part — you can't beat the peak, but you can approach it by reducing the non-data cycles. So throughput exists as the bandwidth metric because: bandwidth-bound workloads are throughput-limited (the why), the peak (width × clock) is the physical ceiling (the bound), and the efficiency (data cycles ÷ total) is the reducible gap below it (the optimization target). So throughput analysis is: compute the peak (physical), estimate the efficiency (the non-data cycles), and optimize by reducing overhead/waits/idle toward the peak. The rest of Module 14 quantifies each efficiency loss (latency, pipelining, wait states, bursts, arbitration, bridges, bottlenecks) — all in service of understanding and closing the peak-to-real gap. So throughput is the foundational performance metric the module builds on.

3. Mental Model

Model throughput as a delivery truck's effective cargo rate — the peak is the truck's size times how many trips per hour it can make (the physical maximum), but the real rate is lower because of time that moves no cargo: loading paperwork before each trip (address-phase overhead), waiting at a slow loading dock (wait states), and the truck sitting idle between jobs (idle cycles); to approach the peak, you batch many boxes per trip (bursts amortise the paperwork), use fast docks (fewer waits), and keep the truck always busy (no idle).

A delivery truck (the bus) moves cargo (data). Its peak rate is its cargo capacity per trip (the bus width) times how many trips per hour it can physically make (the clock frequency) — the most it could deliver. But the real rate is lower, because some time moves no cargo: there's loading paperwork before each trip (the address phase — setting up the transfer, carrying no data); the truck waits at a slow loading dock (wait states — the slave isn't ready); and the truck sits idle between jobs (idle cycles — no transfer to do). So the effective rate is the cargo actually moved divided by the total time — below the peak. To approach the peak: batch many boxes per trip (bursts — one round of paperwork amortised over many boxes, instead of paperwork per box); use fast docks (fast slaves — fewer waits); and keep the truck always busy (back-to-back transfers — no idle gaps). So the peak is fixed by the truck size and trip rate, and the real rate approaches it as you cut the no-cargo time.

This captures throughput: the truck's cargo capacity = the bus width (bytes/beat); trips per hour = clock frequency; peak = capacity × trips = width × clock; loading paperwork = address-phase overhead; waiting at a slow dock = wait states; the truck idle = idle cycles; batching boxes per trip = bursts; fast docks = fast slaves; keeping the truck busy = back-to-back transfers; effective rate = cargo ÷ total time = efficiency. Peak set by truck size and trip rate; real approaches it by cutting the no-cargo time.

Watch which cycles carry data and which don't:

Data-carrying cycles vs overhead/wait cycles

4 cycles

Figure 2 — data-carrying vs overhead cycles. A single (non-burst) read: cycle 0 is the address phase (no data), cycle 1 is the data phase (1 beat of data). So 1 data beat in 2 cycles = 50% efficiency. Then a wait state appears in a second transfer (cycle 3 HREADY low, no data). The 'data?' row marks which cycles actually carry data — the address phase and the wait state carry none, lowering throughput below peak.

The model's lesson: peak = truck size × trips; real approaches it by cutting the no-cargo time. In the waveform, the address phase and the wait state carry no data — those are the efficiency losses below peak; bursts and faster slaves reduce them.

4. Real Hardware Perspective

In hardware, throughput is set by the data bus width and clock (the peak), and the efficiency is determined by the transfer pattern (single vs burst), the slaves' wait-state behavior, and the master's ability to issue transfers back-to-back.

The peak from width and clock: the data bus width (HRDATA/HWDATA — 32-bit, 64-bit, etc.) sets bytes/beat; the AHB clock (HCLK) sets the cycle rate. The peak is their product: a 64-bit bus at 200 MHz peaks at 8 bytes × 200 M = 1.6 GB/s. So in hardware, the peak is a direct function of the two physical parameters — widening the bus or raising the clock raises the ceiling (at area/timing cost). So the peak is a physical-design choice.

Figure 3 — what lowers efficiency below 1. Address-phase overhead: one address cycle carries no data, so a lone beat is ~50% efficient — bursts amortise it over N beats. Wait states: each HREADY-low cycle carries no data, directly cutting bandwidth — use faster slaves/caching. Idle cycles: gaps with no transfer (stalls, dependencies, arbitration) waste bandwidth — keep transfers back-to-back. Efficiency = data-carrying cycles ÷ total cycles; bursts, fast slaves, and back-to-back transfers push it toward 1.

The address-phase overhead is a per-transaction cost: every transaction has one address phase (carrying no data) before its data phase(s). For a single transfer (1 beat), that's 1 overhead cycle + 1 data cycle = 50% efficiency. For a burst of N beats, it's 1 overhead cycle + N data cycles = N/(N+1) efficiency — approaching 100% for large N. So in hardware, bursts are the primary tool to amortise the address-phase overhead. So burst length directly affects efficiency (chapter 14.5 quantifies this). So use bursts for bandwidth.

The wait states and idle cycles: wait states (chapter 12.4) come from slow slaves (HREADY low) — each is a lost data cycle. Idle cycles come from the master not issuing transfers (stalls, dependencies, waiting for data, re-arbitration). Both lower efficiency. In hardware, wait states are reduced by faster slaves (caching/prefetch for flash, fast SRAM), and idle cycles by keeping the master busy (issuing transfers back-to-back, prefetching, deep request queues). So in hardware, real throughput = (width × clock) × efficiency, where efficiency is set by the burst length (amortising address overhead), the slaves' speed (wait states), and the master's issue pattern (idle cycles). The peak is physical; the efficiency is a design and workload property. So the hardware throughput is the physical ceiling times the achievable efficiency — and the module's later chapters quantify each efficiency term.

5. System Architecture Perspective

At the system level, throughput is the metric that determines whether the bus can sustain a workload's data demands — and the peak-vs-efficiency framing is the lens for both sizing the bus (peak) and optimizing the system (efficiency).

The sustaining the workload: a system's data-moving tasks (DMA streams, frame buffers, network packets, memory copies) each demand a certain throughput (bytes/second). The bus must sustain the aggregate demand of the concurrent tasks. So throughput analysis answers "can the bus keep up?" — comparing the achievable throughput to the workload's demand. If the demand exceeds the achievable, the bus is the bottleneck (the system stalls waiting for data). So at the system level, throughput is the capacity-planning metric — size the bus to meet the workload's bandwidth demand. So it's central to whether the system performs.

The sizing via the peak: the peak (width × clock) is the first sizing lever — if even the peak is below the demand, no efficiency improvement can help; you must widen the bus or raise the clock (or use a matrix for aggregate bandwidth, Module 13). So the peak sets whether the bus is capable of the demand at all. So at the system level, the architect first checks the peak against the demand, then sizes width/clock (or adds matrix concurrency) to ensure the peak exceeds the demand with margin. So peak sizing is the capacity-design step.

The optimizing via efficiency: once the peak is sufficient, the efficiency determines whether the real throughput meets the demand. So the architect optimizes efficiency — using bursts (amortise address overhead), fast slaves (reduce waits), and back-to-back issue (eliminate idle) — to push real throughput toward the peak. So at the system level, efficiency optimization is the tuning step — closing the peak-to-real gap. And the module's later chapters (latency, pipelining, wait states, bursts, arbitration, bridges, bottlenecks) are the toolkit for this optimization. So throughput at the system level is the capacity-and-tuning metric: the peak (width × clock, plus matrix concurrency) sets the capacity ceiling — size it above the workload demand; the efficiency (data cycles ÷ total, raised by bursts/fast-slaves/back-to-back) sets the real throughput — optimize it toward the peak. The whole module is, in effect, the study of throughput and latency — the two metrics that determine if a system meets its performance goals. So throughput is the lens through which AHB performance is sized and tuned. Understanding it (peak + efficiency) is the foundation for the system-performance engineering the rest of the module develops.

6. Engineering Tradeoffs

Throughput embodies the peak-ceiling, efficiency-gap performance model.

Wider bus / faster clock (raise peak) vs cost. Widening the data bus or raising the clock raises the peak throughput, at the cost of area (wider buses) and timing difficulty (faster clock). Raise the peak when the workload demands more than the current ceiling.
Bursts (raise efficiency) vs single transfers. Bursts amortise the address-phase overhead (efficiency → N/(N+1)), raising throughput, at the cost of burst-capable masters/slaves and burst-boundary constraints. Use bursts for bandwidth-bound traffic.
Fast slaves (fewer waits) vs cost. Faster slaves (caching, fast SRAM) reduce wait states (raising efficiency), at the cost of the faster memory/cache. Worth it for throughput-critical slaves.
Back-to-back issue (no idle) vs simple masters. Keeping the master issuing transfers continuously (prefetch, queues) eliminates idle cycles (raising efficiency), at the cost of master complexity. Worth it for bandwidth-bound masters.

The throughline: throughput = (bytes/beat × beats) ÷ total_cycles × f_clk; the peak = bus_width × f_clk is the physical ceiling; real = peak × efficiency, where efficiency = data-carrying cycles ÷ total cycles (< 1). The efficiency gap comes from address-phase overhead (amortised by bursts), wait states (reduced by fast slaves), and idle cycles (eliminated by back-to-back transfers). Sizing the bus means setting the peak (width/clock, plus matrix concurrency) above the workload demand; optimizing means raising efficiency toward the peak. Throughput is the foundational bandwidth metric the rest of Module 14 quantifies.

Peak (width × clock) is a hard ceiling — if peak < demand, no efficiency tuning helps; raise the peak (width/clock/matrix) first

A capacity-planning rule: the peak throughput (bus_width × clock) is a hard physical ceiling — if the peak itself is below the workload's bandwidth demand, no amount of efficiency tuning (bursts, fast slaves, back-to-back transfers) can ever meet the demand; you must raise the peak. It's a common mistake to try optimizing efficiency (adding bursts, caching) when the fundamental problem is that the bus physically can't move enough data even at 100% efficiency. The check is simple: compute the peak (e.g. 32-bit @ 100 MHz = 400 MB/s) and compare it to the demand. If the demand is, say, 600 MB/s, then even a perfect bus (efficiency = 1) maxes at 400 MB/s — short by 200 MB/s. No burst length, no cache, no back-to-back issue can exceed the 400 MB/s ceiling. In that case, you must raise the peak: widen the data bus (64-bit @ 100 MHz = 800 MB/s — now the peak exceeds the demand), raise the clock (32-bit @ 200 MHz = 800 MB/s), or use a bus matrix for aggregate bandwidth across multiple slaves (Module 13 — if the demand can be spread across concurrent paths). Only after the peak exceeds the demand (with margin) does efficiency tuning matter — to close the gap between the peak and the real throughput so the real throughput also meets the demand. So the capacity-planning order is: (1) compute the peak, (2) ensure peak > demand (raise width/clock/matrix if not), (3) then optimize efficiency (bursts/fast-slaves/back-to-back) to bring real throughput up to demand. Trying to tune efficiency when the peak is the limit is wasted effort — you can't tune past a hard ceiling. So always check the peak against the demand first.

7. Industry Example

Compute and analyze throughput for a DMA stream.

A DMA must stream data from a peripheral to SRAM at 300 MB/s, on a 32-bit AHB bus at 100 MHz.

Compute the peak. Peak = 4 bytes × 100 MHz = 400 MB/s. The demand (300 MB/s) is below the peak — so the bus is capable (peak > demand). Good; we don't need to widen the bus.
Single transfers (low efficiency). If the DMA used single (non-burst) transfers, each is 1 address cycle + 1 data cycle = 50% efficiency → real ≈ 200 MB/s. That's below the 300 MB/s demand — insufficient, despite the peak being enough. The single-transfer overhead is the problem.
Bursts (raise efficiency). Switch to bursts — say INCR4 (4-beat). Each burst is 1 address cycle + 4 data cycles = 4/5 = 80% efficiency → real ≈ 320 MB/s. Now above the 300 MB/s demand. The burst amortised the address overhead. (Longer bursts → higher efficiency, e.g. INCR16 ≈ 16/17 ≈ 94%.)
Wait states (check the slave). If the SRAM is fast (zero wait states), the 80% holds. If it inserted wait states, efficiency would drop — so a fast SRAM is needed. The peripheral side (the source) must also keep up.
Idle cycles (keep busy). The DMA must issue bursts back-to-back (no idle gaps between bursts) to sustain the 80%. If it stalled between bursts (re-arbitration, descriptor fetches), efficiency would drop — so the DMA is designed to keep the bus busy.
Result. With bursts, a fast slave, and back-to-back issue, the real throughput (≈320 MB/s) exceeds the 300 MB/s demand. The peak (400 MB/s) gave headroom; the efficiency tuning (bursts) closed the gap.

The example shows throughput analysis end-to-end: compute the peak (400 MB/s, exceeds demand), find single-transfer efficiency insufficient (200 MB/s < 300), apply bursts to raise efficiency (320 MB/s > 300), and ensure fast slaves and back-to-back issue sustain it. The peak provided the ceiling; efficiency tuning (bursts especially) delivered the required throughput. This is how throughput is computed and met in practice.

8. Common Mistakes

Throughput misconceptions

"Throughput equals the peak (width × clock)." No — that's the ceiling. Real throughput = peak × efficiency (< 1), lowered by overhead, waits, and idle cycles.
"A single transfer is ~100% efficient." No — it's ~50% (1 address cycle + 1 data cycle). Bursts raise efficiency toward 100% by amortising the address overhead.
"Efficiency tuning can exceed the peak." No — the peak is a hard ceiling. If peak < demand, you must raise the peak (width/clock/matrix); tuning can't beat it.
"Wait states don't affect throughput much." They directly cut it — each wait state is a lost data cycle. Many wait states can dominate the efficiency loss.
"Idle cycles are negligible." Gaps between transfers (stalls, re-arbitration, dependencies) waste bandwidth; back-to-back issue is needed for high efficiency.
"Throughput and latency are the same." No — throughput is rate (bytes/sec); latency is time per transfer (chapter 14.2). A bus can have high throughput but high latency (deep pipeline), or vice versa.

9. Interview Insight

Throughput is a quantitative interview topic — the formula, the peak-vs-efficiency framing, and the single-vs-burst efficiency numbers are the signals.

Figure 4 — a strong answer in one card: throughput = (bytes/beat × beats) ÷ total_cycles × f_clk; peak = width × f_clk (e.g. 32-bit @ 100 MHz = 400 MB/s); real = peak × efficiency, lowered by address overhead, wait states, idle cycles; efficiency = data cycles ÷ total, raised by bursts/fast-slaves/back-to-back. The senior point: peak = width × freq, and the gap to real is the overhead/wait/idle cycles that carry no data.

The answer that lands gives the formula, the peak, and the efficiency: "AHB throughput is the data rate — bytes per second — computed as bytes per beat times the number of beats, divided by the total cycles, times the clock frequency. The peak is simply the bus width times the clock — for a 32-bit bus at 100 MHz, that's 4 bytes times 100 million, or 400 MB/s — achieved only if every cycle carries a data beat. But real throughput is the peak times an efficiency below one. Efficiency is the fraction of cycles that actually carry data, and it's lowered by three things: address-phase overhead — every transaction has one address-phase cycle that carries no data, so a single transfer is only about 50% efficient; wait states — each cycle the slave holds HREADY low carries no data; and idle cycles — gaps where no transfer is issued. The key tool is bursts: a burst has one address phase amortised over N data beats, so its efficiency is N over N+1, approaching 100% for long bursts. So you raise efficiency with bursts, fast slaves to cut wait states, and back-to-back issue to eliminate idle. The crucial framing for capacity planning is that the peak is a hard ceiling: if the peak is below the demand, no efficiency tuning helps — you must widen the bus, raise the clock, or use a matrix. Only when the peak exceeds the demand does efficiency tuning close the gap." The formula, the peak-vs-efficiency framing, the burst efficiency, and the hard-ceiling point are the senior signals.

🔍 The discriminator: peak = width × clock (hard ceiling); real = peak × efficiency; single ≈ 50%, burst → N/(N+1)

The discriminator on throughput is whether you cleanly separate the peak (a hard physical ceiling) from the efficiency (the reducible gap) — and quantify the efficiency losses. A weak answer says "throughput is how fast data moves." A solid answer gives the formula and the peak (width × clock). But the senior answer makes the peak-vs-efficiency split sharp: the peak = bus_width × clock is a hard ceiling set by physical parameters (you cannot move more than one bus-width per cycle), and the real throughput = peak × efficiency, where efficiency = data-carrying cycles ÷ total cycles. Then it quantifies the efficiency losses: address-phase overhead makes a single transfer ~50% efficient (1 address + 1 data cycle), and a burst of N beats is N/(N+1) efficient (1 address amortised over N data) — approaching 100% for long bursts; wait states and idle cycles each directly subtract data-carrying cycles. The capacity-planning insight that impresses: the peak is a hard ceiling — if peak < demand, no efficiency tuning can ever meet the demand; you must raise the peak (widen the bus, raise the clock, or use a matrix for aggregate bandwidth). Only after peak > demand does efficiency tuning (bursts, fast slaves, back-to-back issue) matter, to bring real throughput up to demand. The flourish is distinguishing throughput (rate) from latency (time per transfer, chapter 14.2) — independent metrics. A candidate who splits peak (hard ceiling, width × clock) from efficiency (data cycles ÷ total), quantifies single ≈ 50% vs burst → N/(N+1), and applies the peak-first capacity-planning order demonstrates real performance-analysis skill — not just "bursts are faster."

10. Practice Challenge

Compute and reason from throughput.

The formula. Write the throughput formula and compute the peak for a 64-bit bus at 150 MHz.
Single vs burst. Compute the efficiency of a single transfer and of an INCR8 burst.
Read the waveform. From Figure 2, identify the data-carrying cycles and the non-data (overhead/wait) cycles.
Peak first. Explain why you check the peak against the demand before optimizing efficiency.
Reduce losses. Name the three efficiency losses and the remedy for each.

11. Key Takeaways

Throughput = (bytes/beat × beats) ÷ total_cycles × f_clk — the data rate (bytes/second) the bus achieves.
Peak = bus_width × f_clk — the hard physical ceiling (e.g. 32-bit @ 100 MHz = 400 MB/s), achieved only if every cycle carries data.
Real = peak × efficiency, where efficiency = data-carrying cycles ÷ total cycles (< 1).
Three efficiency losses: address-phase overhead (single ≈ 50%; bursts → N/(N+1)), wait states (each HREADY-low cycle; fast slaves), idle cycles (gaps; back-to-back issue).
Check the peak first — if peak < demand, no efficiency tuning helps; raise the peak (widen bus, raise clock, or use a matrix). Only then does efficiency tuning close the gap.
Throughput ≠ latency — throughput is rate (bytes/sec); latency is time per transfer (chapter 14.2). Independent metrics; optimize each for its workload.

12. What Comes Next

You now understand throughput — the peak ceiling and the efficiency gap. The next chapters quantify the other performance dimensions:

Latency (next) — decomposing transfer latency across the address and data phases (the time-per-transfer metric, complementary to throughput).
Pipelining Benefit — quantifying the throughput gain from phase overlap.
Wait-State Penalty, Burst Efficiency, Arbitration Overhead, Bridge Penalty, Bottleneck Analysis, Performance Debug — quantifying each efficiency loss and how to debug performance.

To revisit the pipeline that creates the address-phase overhead, see Address & Data Phase; for bursts (the key efficiency tool), see HBURST.