AMBA AXI · Module 8

Different-ID & Out-of-Order Completion

How AXI lets different-ID transactions complete out of order — the throughput it buys, why the manager must accept any completion order, and the address hazards that arise when overlapping accesses use different IDs.

The same-ID rule (Chapter 8.3) is half the ordering model; this chapter is the other half. Transactions with different IDs have no ordering guarantee — the interconnect and subordinates are free to complete them out of order, and they will, because that's where the throughput comes from. A fast access shouldn't wait behind a slow, unrelated one. But this freedom shifts a burden onto the manager: it must accept responses in any order (matching by ID), and it must never assume ordering between different-ID transactions — especially dangerous when they touch the same address. This chapter covers the reordering, the throughput it buys, and the hazards it introduces.

1. Different IDs May Complete Out of Order

AXI guarantees ordering only within an ID. Across different AxIDs, there is no ordering — the system may return responses in whatever order is fastest. So if a manager issues read ID=0 then read ID=1, ID=1's data may come back first if its slave/access is quicker. This is legal and expected; the manager pairs each response to its request by RID/BID, regardless of order.

Figure 1 — out-of-order completion across IDs. The manager issues read ID=0 then read ID=1; the subordinate (or interconnect) returns ID=1's data first because it was ready sooner, then ID=0's. Different IDs have no ordering guarantee, so responses come back in readiness order; the manager matches them by RID.

2. Why Out-of-Order Completion Buys Throughput

Reordering is the point of having multiple IDs. If different-ID transactions had to complete in issue order, a single slow access (a DRAM page miss, a contended slave, a far interconnect hop) would stall every later transaction behind it — head-of-line blocking. By letting independent (different-ID) transactions complete as soon as they're ready, the system extracts parallelism:

A fast slave can answer while a slow one is still working — no waiting.
A memory controller can reorder across banks to maximize row hits.
Responses fill the data channel in readiness order, keeping it busy rather than idle behind a straggler.

This is the same latency-hiding from Chapter 8.1, now expressed through IDs: outstanding depth keeps many in flight; different IDs let them finish in any order so none blocks the others. The same-ID rule then carves out the subset that must stay ordered.

out-of-order — different-ID reads complete in readiness order

6 cycles

Figure 2 — out-of-order: reads issued ID=0 then ID=1, but ID=1's data returns first (its access was ready sooner) and ID=0's follows. The data channel stays busy in readiness order rather than idling behind the slower ID=0. RID labels each beat so the manager routes the data correctly despite the swapped order.

3. The Burden — Managers Must Accept Any Order

Out-of-order completion means a manager cannot assume responses arrive in issue order across IDs. Its response-handling must:

Match strictly by ID — route each RID/BID response to the request that carried that ID, not to "the next expected" transaction.
Tolerate any interleaving — a later-issued ID may complete first, responses may interleave arbitrarily across IDs, and the manager's buffers/tracking must handle that without losing or misrouting data.

A manager that implicitly assumes in-order completion (e.g., pops a FIFO of pending requests on each response regardless of ID) will mismatch data the moment the system reorders — pairing ID=1's data with ID=0's request. This is a common bug in naively-written masters, and it only surfaces when a slave/interconnect actually reorders, which simple testbenches may never do.

Figure 3 — the manager's burden. Because different-ID responses can arrive in any order, the manager must match each response to its request strictly by ID and tolerate arbitrary interleaving. A manager that assumes in-order completion (matching by arrival position instead of ID) mismatches data as soon as the system reorders.

4. The Real Hazard — Overlapping Addresses, Different IDs

The subtlest and most dangerous consequence: if two transactions touch the same (or overlapping) address but use different IDs, AXI imposes no ordering between them, so the result is undefined. Examples of the hazard:

A write (ID=0) and a later read (ID=1) to the same address — the read may be serviced before or after the write lands; it may return old or new data (also compounded by the read/write separation of Chapter 8.3).
Two writes (ID=0, ID=1) to the same address — they may complete in either order, so the final stored value is unpredictable (a write-after-write hazard).
A read (ID=0) and a write (ID=1) to the same address — the read may catch the value before or after the write.

The rule that protects against this: transactions to the same/overlapping address that must be ordered must share an ID (so the same-ID rule orders them) — or be serialized by waiting for the first's response before issuing the second (needed especially across the read/write boundary, which IDs can't order). Using different IDs to overlapping addresses is only safe when the accesses are genuinely independent (no ordering needed) — i.e., they don't actually overlap in a way that matters.

Figure 4 — the same-address hazard and its fix. Two accesses to overlapping addresses with different IDs have no ordering → undefined result (WAW/RAW/WAR hazard). If they must be ordered: give them the same ID (same-ID rule orders same-direction accesses) or serialize via response-wait (required across read/write). Different IDs to overlapping addresses are safe only if truly order-independent.

5. Common Misconceptions

Myths to unlearn

"Out-of-order completion is a bug or an error condition." It's normal and intended — different IDs are meant to complete in readiness order for throughput. A correct manager expects it.
"Responses come back in the order I issued them." Only within an ID. Across different IDs, responses arrive in readiness order — a later-issued ID can finish first.
"I can match responses to requests by arrival order." No — match strictly by RID/BID. Position-based matching mismatches data the moment the system reorders.
"Different IDs to the same address are fine." Dangerous — they have no ordering, so overlapping accesses give an undefined result (WAW/RAW/WAR hazard). Order them with a shared ID or a response-wait.
"The bus protects me from address hazards." It does not — AXI deliberately leaves different-ID ordering unspecified for performance; hazard avoidance is the manager's responsibility.

6. Debugging Insight

🔍 Debugging insight — reorder-exposed mismatches and address hazards

Out-of-order bugs hide until the system actually reorders, then appear as mismatches or nondeterminism:

Data paired with the wrong request, only against a reordering slave? The manager is matching by position, not ID — it assumed in-order completion. It works against a simple in-order slave and breaks against one that reorders. Fix the response matching to key on RID/BID.
Intermittent wrong/stale data at a specific address? A same-address, different-ID hazard — two overlapping accesses with different IDs raced, and the order (hence result) is undefined. It's intermittent because the winner varies with timing. Put the ordered accesses on a shared ID, or serialize across the read/write boundary with a response-wait.
A multi-write location ends up with the wrong final value sometimes? Write-after-write across different IDs — the two writes completed in an unpredictable order. Same ID forces issue-order completion and a deterministic final value.
Works in simulation, fails in silicon (or vice versa)? The reordering behavior differs — sim may complete in order while real hardware reorders (or vice versa). The latent assumption (in-order across IDs, or a same-address hazard) was always a bug; the environment just exposed it.

Triage: misrouted data → position-vs-ID matching; nondeterministic data at an address → same-address different-ID hazard. Both stem from treating different-ID transactions as if they were ordered.

7. Verification Insight

✅ Verification insight — actively reorder, and hunt same-address hazards

The defining technique here is an actively reordering response model: a subordinate/interconnect VIP that deliberately returns different-ID responses out of issue order (and in varied interleavings), to prove the manager matches by ID and never by position. A DUT that only ever sees an in-order slave is under-verified — the reorder tolerance is exactly the property at risk. Assert that every response is routed to the request with its ID, with arbitrary interleaving, and that no data is lost, duplicated, or mismatched.

Then hunt address hazards: generate transaction streams with overlapping addresses across different IDs and check that the environment flags them (a protocol/coherency monitor should warn that the result is undefined), while confirming that correctly ordered accesses (shared ID, or serialized via response-wait) produce deterministic results. Coverage should include: out-of-order completion at every interleaving depth, same-ID and different-ID streams mixed, overlapping-address accesses across IDs (negative — must be flagged or proven independent), and the read/write-to-same-address case (which IDs cannot order). The highest-value tests are the maximally-reordered response stream (stresses the manager's matching) and the same-address different-ID race (stresses hazard handling). This pairs with the same-ID checks of 8.3 — together they verify the entire ordering model.

8. Interview Questions

9. Summary

Different-ID transactions have no ordering guarantee and may complete out of order — and that's the intended behavior, because it's where AXI's throughput comes from: independent accesses finish in readiness order, fast bypassing slow, keeping the data channel busy instead of head-of-line-blocked. The same-ID rule (8.3) then carves out the subset that must stay ordered. The freedom carries two burdens for the manager: it must match responses strictly by RID/BID and tolerate any interleaving (position-based matching corrupts data the instant the system reorders), and it must avoid address hazards — overlapping accesses with different IDs have an undefined result (WAW/RAW/WAR), so accesses that must be ordered need a shared ID (same direction) or serialization via response-wait (across reads/writes).

The throughline of Module 8's ordering model: AXI guarantees only same-ID, same-direction order and reorders everything else for performance, making hazard avoidance and out-of-order tolerance the manager's job. Bugs are latent until the system actually reorders — position-based matching and same-address different-ID races — so verification must actively reorder responses and hunt same-address hazards. Next: how outstanding depth and IDs play out across the interconnect — where multiple managers, reordering, and ID extension all interact.

10. What Comes Next

You've got both halves of the ordering model; next, how it scales through the interconnect:

8.5 — Interconnect Implications (coming next) — how outstanding depth, IDs, and reordering interact across a multi-manager, multi-subordinate interconnect.

Previous: 8.3 — Same-ID Ordering Rules. Related: 8.2 — Transaction IDs for ID matching, and 8.1 — Why Outstanding Transactions Exist for the latency-hiding this enables. For the broader protocol catalog, see the AMBA family overview doc.