AMBA AXI · Module 13

Bandwidth & Throughput

Defining and computing AXI bandwidth — peak (bus width × frequency) vs sustained throughput, the efficiency ratio, what limits it (overhead, outstanding depth, burst length, narrow transfers, contention), and the bandwidth formula.

Module 13 turns to performance, and it starts with the most fundamental metric: bandwidth. There are two numbers that matter — peak (theoretical) bandwidth, set by the bus width and clock, and sustained (effective) throughput, what you actually achieve, which is always lower. The ratio between them is efficiency, and understanding what drags sustained below peak — overhead, insufficient outstanding depth, short bursts, narrow transfers, contention — is the core of AXI performance work. This chapter defines the metrics, gives the bandwidth formula, and catalogs what limits throughput.

1. Peak vs Sustained

Two distinct numbers:

Peak (theoretical) bandwidth = data bus width (bytes) × clock frequency. A 128-bit (16-byte) bus at 1 GHz has a peak of 16 × 10⁹ = 16 GB/s. It's the absolute ceiling — one full-width beat every cycle, forever.
Sustained (effective) throughput = the bandwidth actually achieved over real traffic — always less than peak, because real traffic has idle cycles (bubbles), addressing overhead, and underutilized beats.

The efficiency is sustained ÷ peak — what fraction of the ceiling you reach. A well-designed high-bandwidth path might hit 80–95% efficiency; a poorly-shaped one (short bursts, too few outstanding, narrow transfers) might be 20% or worse. Performance work is largely about raising efficiency — closing the gap between sustained and peak.

Figure 1 — peak vs sustained bandwidth. Peak = bus width × clock frequency (the ceiling: a full-width beat every cycle). Sustained = what's actually achieved, always lower due to idle cycles, overhead, and underused beats. Efficiency = sustained ÷ peak. Performance work is raising efficiency toward 100%.

2. The Bandwidth Formula

Sustained throughput can be computed from the traffic:

Sustained throughput = (data beats transferred per second) × (bytes per beat) × utilization

equivalently, per transaction: bytes/transaction = (AxLEN+1) × 2^AxSIZE (from Chapter 7.1), so throughput = (transactions/sec) × (bytes/transaction). And utilization is the fraction of cycles the data channel actually transfers a beat (both VALID/READY high) — 1.0 is full rate, lower means bubbles.

The two levers in the formula: bytes per beat (the bus width, fixed by the data path) and utilization (how busy you keep the data channel). Since width is usually fixed, sustained throughput is mostly a utilization problem — keep the data channel transferring every cycle and you approach peak; let it idle (waiting on addresses, latency, or contention) and you fall short. So "improve bandwidth" almost always means "improve utilization."

bandwidth-calc — data-channel utilization (busy vs idle cycles)

8 cycles

Figure 2 — bandwidth-calc: utilization is the fraction of cycles the data channel actually transfers. Here some cycles transfer a beat (busy) and some are idle (bubbles); throughput = bytes/beat × beats actually transferred per second. Full utilization (a beat every cycle) reaches peak; idle cycles drop sustained below it. Sustained bandwidth is mostly a utilization problem.

3. What Limits Sustained Throughput

The gap between peak and sustained comes from a handful of causes:

Addressing/handshake overhead — cycles spent on address phases or stalls rather than data. Amortized by long bursts (one address per many beats), worsened by short bursts.
Insufficient outstanding depth — if too few transactions are in flight to cover the latency, the data channel idles between them (latency-bound, Chapter 8.1). The dominant cause on high-latency paths.
Short bursts — each burst pays an address-phase overhead; length-1 bursts can collapse throughput toward the address-channel rate. Longer bursts amortize it.
Narrow transfers — AxSIZE below the bus width uses only some byte lanes per beat, wasting bus bandwidth (Chapter 7.7). Full-width transfers use all lanes.
Backpressure / contention — a slow consumer or a contended shared subordinate inserts bubbles (Chapters 11.6, 12.4).

So the recipe for high sustained throughput is: long, full-width bursts with enough outstanding transactions to hide latency, to a non-contended path. Each limiter is an efficiency leak; closing them is the optimization work of the rest of Module 13.

Figure 3 — what limits sustained throughput. Addressing/handshake overhead, insufficient outstanding depth (latency-bound), short bursts (unamortized address overhead), narrow transfers (wasted lanes), and backpressure/contention each insert inefficiency. High throughput = long, full-width bursts + enough outstanding to hide latency + a non-contended path.

4. Computing It in Practice

A worked approach: take a 128-bit bus (16 B) at 1 GHz → peak 16 GB/s. Suppose a DMA does 16-beat full-width INCR bursts (AxLEN=15, AxSIZE=4) = 16 × 16 = 256 bytes/transaction, with enough outstanding to keep the data channel ~95% utilized. Sustained ≈ 16 GB/s × 0.95 ≈ 15.2 GB/s (95% efficiency). Now suppose instead it does length-1 bursts with only 2 outstanding against a 20-cycle latency: it completes ~2 transactions per 20 cycles × 16 B = far below peak — maybe 10–20% efficiency, latency-bound.

The practical method: (1) compute peak (width × freq); (2) measure or estimate utilization (busy-cycle fraction of the data channel) — or derive the achievable depth from Little's law (throughput = outstanding ÷ latency) and compare to peak; (3) efficiency = sustained ÷ peak, and the shortfall points at the limiter (low depth → latency-bound; short bursts → overhead; narrow → lane waste; bubbles → contention). This decomposition — peak, then utilization, then the specific limiter — is how you diagnose and improve any AXI path's bandwidth.

Figure 4 — the practical method. Compute peak (width × frequency); estimate utilization (data-channel busy fraction) or derive achievable depth from Little's law (throughput = outstanding ÷ latency); efficiency = sustained ÷ peak; the shortfall identifies the limiter (low depth, short bursts, narrow, contention). Peak → utilization → limiter is the bandwidth diagnosis flow.

5. Common Misconceptions

Myths to unlearn

"Bandwidth is just bus width × frequency." That's peak — the ceiling. Sustained throughput (what you get) is lower; the gap (efficiency) is where the real work is.
"A wide/fast bus guarantees high throughput." Only the ceiling. Without enough outstanding depth, long bursts, and full-width transfers, sustained stays far below peak (latency-bound).
"Throughput is about the data path width." Width sets bytes/beat, but sustained throughput is mostly a utilization problem — keeping the data channel busy every cycle.
"Short bursts are fine if there are many of them." No — each pays address overhead; short bursts collapse efficiency. Long bursts amortize the overhead.
"Narrow transfers don't hurt much." They waste byte lanes every beat — a 1-byte/beat transfer on a 64-bit bus uses 1/8 of the bandwidth. Use full-width.
"Efficiency near 100% is normal." Only with careful shaping (long full-width bursts + sufficient depth + no contention). Naive traffic is often well below 50%.

6. Debugging Insight

🔍 Debugging insight — diagnose the efficiency shortfall

When sustained throughput is below expectation, decompose to find the limiter:

Compute peak and measure sustained — the efficiency ratio tells you how big the problem is. 90%+ is fine; 20% means a serious limiter.
Data channel idling between transactions (low utilization, high latency)? Insufficient outstanding depth — the dominant cause. Measure achieved depth vs Throughput × Latency (Little's law, 8.1); raise the depth (manager, interconnect, or slave).
Throughput collapses with short transfers? Short bursts — address overhead per burst dominates. Increase burst length (up to 256/16 and the 4 KB limit).
Bus busy but moving less data than expected per beat? Narrow transfers — AxSIZE below bus width wasting lanes (Chapter 7.7). Use full-width.
Throughput drops only under multi-master load? Contention at a shared subordinate (Chapter 12.4) — bubbles from arbitration; distribute traffic or use QoS.
Bubbles in the data stream with one master? Backpressure from a slow consumer, or the manager not issuing ahead (Chapter 11.6).

The triage: low efficiency → which limiter? Idle-between-transactions → depth; collapse-on-short-transfers → burst length; less-per-beat → narrow; multi-master-only → contention; bubbles → backpressure. Each maps to a specific fix.

7. Verification Insight

✅ Verification insight — measure throughput and characterize efficiency

Bandwidth is a performance property, so verification means measuring, not just pass/fail. Build monitors that compute sustained throughput (bytes transferred per unit time) and data-channel utilization (busy-cycle fraction) on each path, and compare against the peak (width × freq) to get efficiency. Assert efficiency meets the design target under representative traffic (e.g., a DMA path must achieve ≥X% of peak). Characterize how efficiency varies with the knobs: burst length (short → low efficiency), outstanding depth (sweep depth, confirm throughput rises until the bandwidth-latency product is met then plateaus, per Little's law), transfer width (narrow → proportionally lower), and contention (multi-master → measure the drop).

Coverage should include: maximum-efficiency traffic (long full-width bursts, full depth — confirm near-peak); each limiter in isolation (short bursts, low depth, narrow, contention — confirm the expected efficiency drop); and realistic mixed workloads (the actual expected efficiency). The highest-value measurement is the depth-vs-throughput sweep — it both validates the Little's-law relationship and finds the depth needed for the target bandwidth (feeding Chapter 13.3's buffer sizing). Because bandwidth bugs are correct-data-but-slow, functional tests miss them entirely — dedicated throughput measurement is the only way to catch a path that works but underperforms, which is exactly the class of bug that ships and disappoints in silicon.

8. Interview Questions

9. Summary

AXI bandwidth has two numbers: peak = bus width × frequency (the ceiling — a full-width beat every cycle) and sustained = what's actually achieved (always lower), with efficiency = sustained ÷ peak. The bandwidth formula — bytes/beat × beats-transferred-per-second (or per transaction, (AxLEN+1) × 2^AxSIZE × transactions/sec) — shows that since bytes/beat (width) is fixed, sustained throughput is mostly a utilization problem: keep the data channel transferring every cycle and you approach peak. The limiters that drag sustained below peak are insufficient outstanding depth (latency-bound — the dominant one, via Little's law), short bursts (unamortized address overhead), narrow transfers (wasted lanes), and backpressure/contention (bubbles).

The diagnosis flow is peak → utilization → limiter: compute the ceiling, measure the busy-cycle fraction (or derive achievable depth from throughput = outstanding ÷ latency), get efficiency, and the shortfall names the limiter. The high-throughput recipe is long, full-width bursts with enough outstanding depth to hide latency on a non-contended path. Critically, bandwidth bugs are correct-data-but-slow — invisible to functional verification — so they demand dedicated measurement (throughput/efficiency monitors, depth sweeps) under realistic latency, or they ship as performance failures. Next: latency analysis — decomposing where the cycles of a transaction actually go.

10. What Comes Next

You've got the bandwidth metrics; next, the other half of performance:

13.2 — Latency Analysis (coming next) — decomposing a transaction's latency into its contributors (address, decode, slave, response, interconnect).
13.3 — Outstanding Depth & Buffering (coming soon) — sizing outstanding depth and buffers to hide latency.

Previous: 12.7 — Clock & Reset in Interconnect. Related: 8.1 — Why Outstanding Transactions Exist for the Little's-law foundation, and 7.1 — Burst Length, Size & Beats for the bytes-per-transaction formula. For the broader protocol catalog, see the AMBA family overview doc.