AMBA AXI · Module 8

Why Outstanding Transactions Exist

How AXI's outstanding transactions hide memory latency and lift throughput — the latency-bound problem, how independent channels and IDs let a manager keep many transactions in flight, and the Little's-law relationship between depth, latency, and bandwidth.

Module 8 turns from what a transaction is to how many can be in flight at once — and why that's the single most important lever for AXI performance. An outstanding transaction is one that's been issued but hasn't completed yet. AXI lets a manager have many outstanding at the same time: it can fire off transaction after transaction without waiting for earlier responses. This chapter explains why that capability exists — the latency-bound problem it solves — how AXI's structure enables it, and the simple law (throughput = outstanding ÷ latency) that tells you how deep you need to go to saturate a bus. Everything else in Module 8 (IDs, ordering, dependencies) exists to make outstanding transactions work correctly; this chapter is about why they're needed.

1. What "Outstanding" Means

A transaction is outstanding from the moment its address is accepted until its final response completes it (the B response for a write, the last R beat for a read). A manager that supports multiple outstanding transactions can issue transaction 2's address while transaction 1 is still waiting for its data/response — and transaction 3's, and so on. The number it can have in flight at once is its outstanding depth (its issuing capability; a subordinate has a matching acceptance capability).

The opposite — a manager that issues one transaction and waits for it to fully complete before issuing the next — is said to have an outstanding depth of 1. As we'll see, that's a performance disaster on any real memory system.

Figure 1 — outstanding transactions. A manager issues addresses A1, A2, A3 back-to-back (the address channel accepts them without waiting), and the responses/data D1, D2, D3 return later, overlapped. Multiple transactions are in flight at once — that's the outstanding depth. The address phase of later transactions overlaps the latency of earlier ones.

2. The Problem — Latency Would Bind Throughput

Memory and slaves have latency: many cycles pass between accepting an address and returning the first data (DRAM, a multi-hop interconnect, a clock-crossing bridge all add cycles). Suppose that round-trip latency is L cycles. With an outstanding depth of 1, the manager issues a transaction, waits L cycles for it to complete, then issues the next — so it completes one transaction every L cycles, no matter how much bandwidth the data bus has. The bus sits idle during the wait. Throughput is latency-bound, often a small fraction of what the wires could carry.

With multiple outstanding transactions, the manager fills those idle cycles: while transaction 1 is in flight, it issues 2, 3, 4, …. The responses then stream back one after another, and the bus stays busy. Throughput becomes bandwidth-bound — limited by how fast data can move, not by the latency of any single transaction. This is exactly pipelining applied to bus transactions: overlap the latency of many operations instead of paying it serially.

outstanding-pipeline — addresses pipelined ahead of returning data

8 cycles

Figure 2 — outstanding-pipeline: addresses issued back-to-back (top) while read data for earlier transactions returns (bottom), overlapped. With depth-1 the data channel would be idle during each transaction's latency; with multiple outstanding, the address phases of later transactions fill that time and the data channel stays busy — latency hidden, throughput approaching bandwidth.

3. What AXI Provides to Make It Possible

Outstanding transactions aren't free — the protocol must let a manager issue ahead and still sort out the responses. Three AXI features make it work:

Independent channels. The address channels (AW/AR) handshake separately from the data/response channels. An address is accepted on its own, without waiting for that transaction's data — so the manager can keep issuing addresses while data is still in flight (the foundation laid in the five-channel model).
Transaction IDs (AxID). Each transaction carries an ID, and responses carry the matching ID (BID/RID). This lets the manager (and interconnect) match a returning response to its request even when many are outstanding — and even when responses come back in a different order across IDs (Chapter 8.2).
Decoupled handshakes. Because every channel uses independent VALID/READY, the address phase of a later transaction can complete before the data phase of an earlier one — the protocol never forces a transaction to finish before the next can start.

So outstanding capability is an emergent property of AXI's structure: separate channels let you issue ahead, IDs let you reconcile the results, and the handshakes keep it all decoupled. (Ordering rules then govern what's guaranteed about completion order — Chapter 8.3.)

Figure 3 — what enables outstanding transactions. Independent address vs data/response channels let the manager issue addresses ahead; AxID tags let returning responses (BID/RID) be matched to their requests; decoupled VALID/READY handshakes keep phases independent. Together they let many transactions be in flight and still be sorted out correctly.

4. How Deep — Little's Law

How many outstanding transactions do you need? The relationship is Little's law:

Throughput = Outstanding ÷ Latency, so to reach a target throughput, Outstanding ≥ Throughput × Latency.

In words: the number of transactions you must keep in flight to saturate the data path equals the bandwidth-latency product. If a memory round-trip is 20 cycles and you want to complete one transaction per cycle, you need ~20 outstanding transactions to cover the latency; with only 4 in flight you'd complete at most 4 every 20 cycles — 20% utilization. Deeper pipelines (more latency) and wider/faster buses (more throughput target) both demand more outstanding depth to stay bandwidth-bound.

This is why outstanding depth is a first-class design parameter: a manager's issuing capability and a slave/interconnect's acceptance capability must be large enough to cover the system's latency, or the bus runs latency-bound no matter how fast the wires are.

Figure 4 — Little's law for bus pipelining. The outstanding depth needed to keep the data path busy equals throughput × latency (the bandwidth-latency product). Too few outstanding → latency-bound (idle bus); enough → bandwidth-bound (busy bus). Higher latency or higher target throughput both require greater depth.

5. Common Misconceptions

Myths to unlearn

"AXI is fast because it has wide/fast data buses." Width and clock set the ceiling, but without enough outstanding transactions a high-latency system runs far below that ceiling. Outstanding depth is what lets you reach the bandwidth.
"One transaction at a time is fine if the bus is fast." No — with depth 1 you complete one transaction per latency, leaving the bus idle most of the time regardless of its width. It's latency-bound.
"Outstanding transactions need a special mode." They're inherent to AXI — independent channels and IDs make issuing ahead natural. There's no separate "pipelined mode" to enable.
"More outstanding always means more throughput." Only up to the bandwidth-latency product; beyond the point where the data path is saturated, extra depth adds buffering/complexity without more throughput.
"Outstanding only helps reads." It helps both — a manager can have many writes (or reads) in flight; the same latency-hiding applies to write address/data ahead of B responses.

6. Debugging Insight

🔍 Debugging insight — low throughput on a fast bus usually means too few outstanding

When a bus delivers far less than its theoretical bandwidth, outstanding depth is the first thing to check:

Utilization a fraction of bandwidth, with a high-latency slave? Measure the outstanding depth the manager actually achieves. If it's small (often 1–2) against a 20+ cycle latency, you're latency-bound — the bus idles between transactions. Compare achieved depth to Throughput × Latency.
Manager can issue deep but doesn't? The bottleneck may be the subordinate's or interconnect's acceptance capability — if a slave only accepts 2 outstanding, the manager stalls at 2 regardless of its own capability. Check both issuing and acceptance limits along the path.
Throughput collapses when latency rises (e.g., DRAM page miss, clock crossing added)? The fixed outstanding depth no longer covers the larger latency — the bandwidth-latency product grew past the available depth. The fix is more outstanding (or lower latency), not a wider bus.
Bursty rather than steady throughput? The manager may be draining all responses before issuing the next batch (effectively depth-limited by a synchronization point) instead of continuously issuing ahead.

The diagnostic mantra: low throughput on a fast bus → measure outstanding depth → compare to bandwidth-latency product. Widening the bus won't help a latency-bound system; more in-flight transactions will.

7. Verification Insight

✅ Verification insight — exercise depth, and check correctness under concurrency

Two angles: performance and correctness under concurrency. For performance-style checks, drive the manager to its maximum outstanding depth and confirm the design actually issues ahead (doesn't serialize), measuring achieved depth and bus utilization against the bandwidth-latency product — a DUT that silently caps depth at 1–2 is a common performance bug. For correctness, the key is that many in-flight transactions must still complete correctly: every issued transaction eventually gets exactly one matching response (right BID/RID, right data), none are lost or duplicated, and the design's outstanding tracking doesn't overflow or mis-match when filled to capacity.

Coverage should sweep outstanding depths from 1 up to (and beyond) the design's stated capability, mixes of reads and writes in flight together, responses returning with varied timing/latency, and the full-capacity case (issue exactly the maximum, then one more — it must back-pressure, not drop). The highest-value tests fill the pipeline completely and verify both throughput (it stays bandwidth-bound) and integrity (every response matches its request). Ordering guarantees and ID-based matching get their own treatment in Chapters 8.2–8.3; here the focus is that depth is achievable and that concurrency doesn't corrupt completion.

8. Interview Questions

9. Summary

Outstanding transactions are AXI's central performance mechanism. A transaction is outstanding from address acceptance until its response completes, and AXI lets a manager hold many in flight at once. The reason is latency: with depth 1 a manager completes one transaction per round-trip latency, leaving a fast bus mostly idle (latency-bound); by issuing many transactions ahead, it fills those cycles so data streams back continuously and throughput approaches the bus bandwidth (bandwidth-bound) — bus pipelining. The capability is enabled by AXI's structure: independent channels (issue address ahead of data), transaction IDs (match responses to requests), and decoupled handshakes (phases independent). And Little's law sizes it: the depth needed to saturate the path is the bandwidth-latency product (Outstanding ≥ Throughput × Latency).

The practical upshot: when a fast bus underperforms, the cause is almost always too few outstanding transactions (at the manager, slave, or interconnect) relative to the latency — and the fix is more concurrency, not a wider bus. Outstanding depth is therefore a first-class design and verification parameter. The rest of Module 8 makes outstanding transactions correct: next, transaction IDs — how AxID tags transactions so their responses can be matched and reordered.

10. What Comes Next

You've got the why; next, the mechanism that keeps concurrency correct:

8.2 — Transaction IDs (coming next) — how AxID tags transactions so many can be in flight and their responses matched and reordered.
8.3 — Same-ID Ordering Rules (coming soon) — the guarantee that same-ID transactions complete in order.

Previous: 7.8 — Strobe Behavior in Bursts. Related: 6.3 — AxID for the ID signal, and Independent Channels for the structural basis. For the broader protocol catalog, see the AMBA family overview doc.

Continue learning

Standards & specifications

Governing standard: Arm AMBA AXI Protocol Specification (IHI 0022)(opens Arm in a new tab)
Defines the AXI channels, handshake and ordering rules. RTL structure, interconnect topology and verification strategy are design choices this specification does not mandate.

This page also covers RTL structure, verification approach and debugging technique. Those are engineering practice built on the standard, not requirements the standard itself imposes.

Where this fits

Part of the AMBA AXI curriculum.