AMBA AXI · Module 18

AXI Performance Interview Questions

Reason quantitatively about AXI performance in interviews — bandwidth (width x frequency x efficiency), latency vs. throughput, Little's Law for outstanding depth, where throughput is lost (short bursts, insufficient outstanding, backpressure, narrow transfers), and the structured way to diagnose 'why is this slow?'.

Performance questions test whether you can reason quantitatively about AXI throughput and latency — "what's the peak bandwidth?", "why is this only hitting half?", "how deep should outstanding be?". Unlike conceptual questions, these reward numbers and formulas: bandwidth as width × frequency × efficiency, Little's Law relating outstanding depth to bandwidth and latency, and a clear separation of latency (time for one transaction) from throughput (transactions per unit time). The strongest answers compute, identify the bottleneck, and reason about the fix. This chapter gives the formulas, the latency-vs-throughput distinction, the common throughput losses, and the structured way to answer "why is this slow?".

1. Bandwidth: Width × Frequency × Efficiency

The foundational performance formula: peak bandwidth = data width × clock frequency, and actual bandwidth = peak × efficiency, where efficiency is the fraction of cycles that actually carry a useful beat. For a 128-bit (16-byte) bus at 1 GHz, peak is 16 GB/s; if only 80% of cycles carry data (due to stalls, address overhead, short bursts), actual is ~12.8 GB/s. The interview move is to compute peak first, then reason about what drops efficiency below 100%. Knowing this decomposition — and that real systems live in the efficiency term — is the foundation of every performance answer.

Figure 1 — the bandwidth decomposition. Peak bandwidth = data width × clock frequency (e.g. 16 bytes × 1 GHz = 16 GB/s). Actual bandwidth = peak × efficiency, where efficiency is the fraction of cycles carrying a useful beat. Real systems live in the efficiency term — stalls, address overhead, short bursts, and narrow transfers all drop it below 100%. The interview move: compute peak first, then reason about what reduces efficiency, since that's where throughput is actually lost.

2. Latency vs. Throughput: The Distinction They Probe

The most-probed performance distinction: latency is the time for one transaction (issue to completion); throughput is how many transactions complete per unit time. They're different and often confused: a high-latency system can still have high throughput if enough transactions are in flight to hide the latency. The key insight: AXI hides latency with outstanding transactions — while one transaction's latency is being paid, others are issued and completing, so throughput approaches bandwidth even when per-transaction latency is high. Stating that latency and throughput are decoupled (and how AXI decouples them — outstanding transactions) is the strong answer.

Outstanding transactions hide latency

11 cycles

Figure 2 — latency vs. throughput, and how AXI decouples them. Latency is the time for one transaction (issue to completion); throughput is transactions completed per unit time. They're decoupled: a high-latency system still achieves high throughput if enough transactions are outstanding to hide the latency — while one transaction's latency is paid, others are issued and complete. AXI's outstanding-transaction capability is precisely the mechanism that decouples throughput from latency, so you can have high throughput despite high latency.

3. Little's Law: Sizing Outstanding for Throughput

The quantitative heart of AXI performance: Little's Law — the number of transactions in flight equals throughput × latency. Rearranged for design: to sustain a target throughput across a given latency, you need outstanding depth ≈ bandwidth × latency (the bandwidth-delay product). For example, to keep a bus fully utilized across a 100 ns round-trip at a transaction every cycle, you need ~100 transactions in flight. The interview application: if asked "why isn't this saturating the bus?", a top candidate checks whether the outstanding depth covers the latency — if depth < bandwidth × latency, the master starves and throughput is latency-limited, not bandwidth-limited.

Figure 3 — Little's Law sizes outstanding depth for throughput. In-flight transactions = throughput × latency, so to sustain a target throughput across a given latency you need outstanding depth ≈ bandwidth × latency (the bandwidth-delay product). If the outstanding depth is less than this, the master starves waiting for responses and throughput is latency-limited (not bandwidth-limited) — a common 'why isn't it saturating?' cause. The fix is to increase outstanding depth to cover the round-trip latency.

4. Where Throughput Is Lost, and "Why Is This Slow?"

The common throughput losses — what drops efficiency below 100% — are a fixed checklist: short bursts (address-phase overhead per burst amortized over too few beats), insufficient outstanding (latency-limited starvation, the Little's Law gap), backpressure (a slow consumer stalling the data path), and narrow/unaligned transfers (not using the full bus width per beat). The structured answer to "why is this slow?": compute peak bandwidth, measure actual, find the efficiency gap, then check the list — bursts long enough? outstanding deep enough? backpressure present? full width used? — and identify the dominant bottleneck before proposing a fix. Diagnose, then fix; don't guess.

Figure 4 — the throughput-loss checklist and the 'why is this slow?' method. Losses: short bursts (per-burst address overhead), insufficient outstanding (latency-limited starvation), backpressure (slow consumer stalls), narrow/unaligned transfers (underusing the bus width). Method: compute peak bandwidth, measure actual, find the efficiency gap, check the list, identify the dominant bottleneck, then fix. Diagnose before fixing — propose the fix for the actual bottleneck, not a guess.

5. Common Misconceptions

Myths to unlearn

"High latency means low throughput." They're decoupled — a high-latency system can have high throughput if enough transactions are outstanding to hide the latency. AXI's outstanding capability is precisely what lets throughput approach bandwidth despite per-transaction latency.
"Peak bandwidth is what you get." No — actual = peak × efficiency, and real systems live in the efficiency term (often well below 100% due to short bursts, stalls, narrow transfers). Always compute peak, then reason about the efficiency loss.
"More outstanding always helps." Only up to bandwidth × latency (Little's Law) — beyond the bandwidth-delay product, more depth just adds area and latency without improving throughput (you're already saturating). Below it, you're latency-limited and depth helps; above it, you're bandwidth-limited and it doesn't.
"A slow bus is a bandwidth problem." Often it's latency-limited (insufficient outstanding) or efficiency-limited (short bursts, backpressure, narrow transfers), not a raw bandwidth shortfall. Diagnose the actual bottleneck — computing peak vs. actual and checking the loss list — before concluding "need more bandwidth."
"Longer bursts are always better." Longer bursts amortize address overhead (good for efficiency), but the 4 KB rule caps burst span, and very long bursts can hurt fairness/latency for other masters. There's a balance; "maximize burst length" isn't unconditional.
"Latency and throughput are the same metric." They're distinct: latency is time for one transaction, throughput is how many per unit time. Conflating them is the most common performance error — a system can be optimized for one at the expense of the other.

6. Debugging Insight

🔍 Debugging insight — 'why is this slow?' is a quantitative diagnosis, not a guess

Answer a performance prompt by computing and diagnosing, not guessing:

Compute peak bandwidth. Width × frequency. This is the ceiling; everything else is efficiency below it. State it first.
Find the efficiency gap. Actual ÷ peak. If you're at 50%, half your cycles aren't carrying useful data — that gap is the problem to explain.
Check outstanding vs. Little's Law. Is depth ≥ bandwidth × latency? If not, you're latency-limited — the master starves waiting for responses, and more outstanding depth is the fix. This is the most common saturation failure.
Check burst length. Are bursts long enough to amortize the per-burst address overhead? Short bursts waste cycles on address phases — longer bursts (within the 4 KB rule) improve efficiency.
Check for backpressure. Is a slow consumer stalling the data path (READY frequently low)? Backpressure caps throughput at the consumer's rate regardless of bus bandwidth.
Check transfer width. Are beats using the full bus width, or narrow/unaligned (wasting lanes)? Narrow transfers waste a fraction of every beat.

The method: compute peak → measure actual → find the gap → check the list (outstanding/burst/backpressure/width) → identify the dominant bottleneck → fix that one. A weak answer guesses "add bandwidth"; a strong answer computes the gap, diagnoses which loss dominates (usually outstanding-vs-latency or short bursts), and fixes the actual bottleneck.

7. Verification Insight

✅ Interview insight — compute first, separate latency from throughput, and diagnose the bottleneck quantitatively

Performance questions reward quantitative reasoning, and the discipline is to compute and diagnose rather than assert. Three pillars. (1) Bandwidth = width × frequency × efficiency — compute peak first (width × frequency, the ceiling), then reason about efficiency (the useful-beat fraction), because real systems live in the efficiency term; an answer that starts with the formula and a number is immediately stronger than a qualitative one. (2) Latency and throughput are decoupled — latency is time-for-one, throughput is how-many-per-time, and AXI hides latency with outstanding transactions, so a high-latency system can still saturate the bus; conflating them is the most common performance error, and stating the decoupling (and the mechanism — outstanding) signals real understanding. (3) Little's Law sizes the system — outstanding depth ≈ bandwidth × latency (the bandwidth-delay product) is the quantitative tool: it answers "how deep should outstanding be?" and diagnoses "why isn't it saturating?" (depth < BW × latency → latency-limited starvation). For "why is this slow?", run the method: compute peak, measure actual, find the efficiency gap, then check the fixed loss list — short bursts (address overhead), insufficient outstanding (Little's Law gap), backpressure (slow consumer), narrow/unaligned transfers (underused width) — identify the dominant bottleneck, and fix that. The failure mode is the qualitative guess ("add more bandwidth") without computing the gap or diagnosing the actual loss — which usually misdiagnoses, since the bottleneck is more often latency-limited (outstanding) or efficiency-limited (bursts/backpressure) than raw bandwidth. The connection to the job is direct: performance tuning a real AXI system is exactly this — compute peak, measure actual, find where efficiency is lost, size outstanding to the bandwidth-delay product, lengthen bursts, relieve backpressure — so the interview reasoning and the engineering work are identical, and the candidate who reasons quantitatively in the interview is demonstrating the architectural judgment the job requires. The through-line of Module 18 holds: the skill is articulating reasoning (here, quantitative performance reasoning) crisply, and the strongest performance answers compute the numbers, separate latency from throughput, apply Little's Law, and diagnose the bottleneck before proposing a fix. Next, the final interview chapter tackles the tricky misconceptions candidates repeat — the myths that, stated confidently, end interviews.

8. Interview Questions

9. Summary

Performance questions reward quantitative reasoning: compute first, then diagnose. Bandwidth = data width × clock frequency × efficiency — compute peak (the ceiling) first, then reason about efficiency (the useful-beat fraction), where real systems lose throughput. Latency (time for one transaction) and throughput (transactions per unit time) are decoupled: AXI hides latency with outstanding transactions, so a high-latency system still saturates the bus if enough transactions are in flight — conflating the two is the most common performance error. Little's Law (in-flight = throughput × latency) is the quantitative heart: outstanding depth ≈ bandwidth × latency (the bandwidth-delay product) both sizes outstanding for a target and diagnoses latency-limited starvation (depth < BW × latency → the master stalls, throughput is latency-limited not bandwidth-limited).

Throughput is lost to a fixed checklist — short bursts (address overhead), insufficient outstanding (Little's Law gap), backpressure (slow consumer), narrow/unaligned transfers (underused width) — and "why is this slow?" is answered by the method: compute peak → measure actual → find the efficiency gap → check the list → identify the dominant bottleneck → fix that one. The failure mode is the qualitative guess ("add bandwidth"), which usually misdiagnoses, since the bottleneck is more often latency- or efficiency-limited than bandwidth-limited. The connection to the job is direct: real performance tuning is this exact measure-compute-diagnose-fix loop, so reasoning quantitatively in the interview demonstrates the architectural judgment the job requires. The through-line of Module 18 holds — articulate the reasoning (here, quantitative) crisply. Next, the final interview chapter tackles the tricky misconceptions candidates repeat — the confidently-stated myths that end interviews.

10. What Comes Next

You can now reason quantitatively about performance; the final interview chapter clears the myths:

18.8 — Tricky Misconceptions (coming next) — the myths candidates confidently repeat (like "VALID waits for READY") and the correct understanding, so you never end an interview on a wrong-but-confident answer.

Previous: 18.6 — Verification Interview Questions. Related: 13.1 — Bandwidth & Throughput, 13.2 — Latency Analysis, and 13.3 — Outstanding Depth Tuning for the Little's Law sizing.