AMBA AXI · Module 8

Same-ID Ordering Rules

AXI's same-ID ordering guarantee — transactions sharing an AxID complete in issue order — what it does and does not cover (different IDs, read-vs-write), and why same-ID across multiple slaves can serialize and hurt performance.

Chapter 8.2 leaned on a guarantee repeatedly: same ID means in order. Now we state it precisely, because it's the rule that makes outstanding transactions predictable — and the boundaries of what it does and doesn't promise are exactly where ordering bugs and performance traps live. The rule is narrow on purpose: it orders transactions sharing an ID, and nothing else. It says nothing about different IDs (they may reorder — Chapter 8.4) and nothing about reads versus writes (a separate concern). And it has a sharp performance edge: same-ID transactions spread across multiple slaves can force the interconnect to serialize. This chapter pins down the guarantee and its limits.

1. The Rule

The same-ID ordering rule, stated for each direction:

Reads: read transactions issued with the same ARID return their data in the order the addresses were issued. Read data for an earlier same-ID read arrives before a later same-ID read's data.
Writes: write transactions issued with the same AWID complete — their B responses return — in the order the addresses were issued.

That's the whole guarantee: for a given ID, completion order equals issue order. A subordinate or interconnect may have the later transaction's result ready first, but it must hold it back and deliver the earlier same-ID one first. This is what lets a manager that needs ordering simply reuse one ID and trust the sequence.

Figure 1 — same-ID ordering. The manager issues three reads all tagged ARID=3. Even if the subordinate could produce the third read's data first, it must return RID=3 data in issue order — read 0, then read 1, then read 2. For a given ID, completion order equals issue order.

2. A Same-ID Read Stream on the Wire

Three same-ID reads return their data strictly in issue order, regardless of which the subordinate finished first:

same-id-order — three ARID=3 reads return in issue order

7 cycles

Figure 2 — same-id-order: three reads all with ARID=3. The RID on the read-data channel returns data D0, D1, D2 in issue order — read 0's data, then read 1's, then read 2's. The subordinate must not let a later same-ID read's data overtake an earlier one's; for the same ID, the data sequence mirrors the issue sequence.

3. What the Rule Does Not Cover

The guarantee is deliberately narrow. Two things it explicitly does not promise:

Different IDs are not ordered. Transactions with different AxIDs have no ordering relationship — the system may complete them in any order (Chapter 8.4). The rule only orders within one ID.
Reads and writes are not ordered relative to each other. ARID and AWID live in separate ID spaces; a read and a write — even with the same numeric ID value — have no ordering guarantee between them. If a manager needs a write to land before a dependent read (or vice versa), it must enforce that itself, typically by waiting for the first transaction's response before issuing the second. AXI's IDs order reads among reads and writes among writes, never reads against writes.

Missing either limit is a classic bug source: assuming different-ID transactions stay ordered, or assuming a same-valued read and write are ordered. Neither holds.

Figure 3 — the rule's scope. Guaranteed: same-ARID reads in order, same-AWID writes in order. NOT guaranteed: ordering between different IDs (may reorder), and ordering between reads and writes (separate ID spaces — must be enforced by the manager). The guarantee is strictly within one ID and one direction.

4. Same ID Across Multiple Slaves — The Serialization Trap

Here's the performance edge. The interconnect must preserve same-ID ordering even when same-ID transactions target different slaves. But different slaves have different latencies and respond independently — so to guarantee that same-ID response 0 (from a slow slave) precedes same-ID response 1 (from a fast slave), the interconnect must hold back the fast slave's response until the slow one is done. Effectively, same-ID traffic to multiple slaves serializes at the rate of the slowest, and the interconnect needs buffering/blocking to enforce it.

The consequence: reusing one ID across transactions that hit different slaves can badly hurt throughput (head-of-line blocking across slaves). Many systems therefore follow a guideline — keep one ID to one slave, or use distinct IDs for transactions that can target different slaves — so the ordering constraint never forces cross-slave serialization. This is the practical reason ID assignment must consider not just ordering need but where transactions go.

Figure 4 — same-ID across slaves serializes. Two same-ID transactions go to a slow slave (resp 0) and a fast slave (resp 1). To preserve issue order, the interconnect must hold the fast slave's resp 1 until the slow slave's resp 0 returns — serializing at the slow slave's rate. Distinct IDs (or one-ID-per-slave) avoid this.

5. Common Misconceptions

Myths to unlearn

"All my transactions complete in issue order." Only those sharing an ID do. Different-ID transactions may complete in any order; relying on global issue order is a bug.
"A read and a write with the same ID value are ordered." No — reads (ARID) and writes (AWID) are separate ID spaces with no mutual ordering. Read-vs-write ordering must be enforced by the manager (wait for the response).
"Same ID just affects how responses are labeled." It's a hard completion-order constraint — the system must deliver same-ID results in issue order, holding back later ones if needed.
"Same ID is always free." Across multiple slaves it can serialize (the interconnect holds faster responses to preserve order) — a real throughput cost. One ID per slave (or distinct IDs) avoids it.
"Ordering is the slave's job only." The interconnect is equally responsible — it must preserve same-ID order even across slaves, which is what creates the serialization behavior.

6. Debugging Insight

🔍 Debugging insight — false-ordering assumptions and same-ID serialization

Same-ID rule bugs come in two flavors — assuming ordering that isn't guaranteed, and paying for ordering you didn't intend:

A read returns stale data after a write that should have updated it? Likely a read-vs-write ordering assumption — the read and write aren't ordered by ID (separate spaces), so the read was serviced before the write landed. The manager must wait for the write's B response before issuing the dependent read (or use the appropriate ordering mechanism). This is not something same-ID can fix — they're different ID spaces.
Transactions complete out of the order you expected? Check whether they actually share an ID. If they have different IDs, reordering is legal — the "expected" order was never guaranteed. Give them the same ID if ordering is truly needed.
Throughput tanks when one ID spans multiple slaves? The serialization trap — the interconnect is holding fast-slave responses to preserve same-ID order behind a slow slave. Split the traffic across distinct IDs (or keep one ID per slave) so independent slaves aren't serialized.
Head-of-line blocking within one slave? Same ID forces in-order completion, so a slow access stalls later same-ID ones (the over-shared-ID stall from 8.2). Distinct IDs for independent accesses fix it.

Triage: stale-after-write → read/write ordering (not an ID issue); surprise reorder → different IDs (no guarantee); cross-slave slowdown → same-ID serialization. Match the symptom to whether ordering was assumed or over-imposed.

7. Verification Insight

✅ Verification insight — prove same-ID order holds and the limits are respected

The central assertion: for every ID, completion order equals issue order — same-ARID reads return data in issue order, same-AWID writes return B responses in issue order. A scoreboard that tracks per-ID issue sequences and checks the completion sequence catches any violation, including a subordinate that lets a ready later transaction overtake an earlier same-ID one. Equally important is asserting the non-guarantees are not silently relied on: different-ID transactions may reorder (drive a reordering model and confirm the DUT tolerates it), and reads/writes are independent (verify the design enforces any needed read-vs-write ordering itself, e.g., by waiting on responses — don't assume the bus orders them).

Coverage must include: multiple same-ID streams; same-ID transactions to different slaves (assert ordering is preserved — and characterize the serialization, since that's expected behavior, not a bug); reads and writes with the same numeric ID value (assert no ordering is imposed between them); and the worst case where a later same-ID transaction's result is ready first (the DUT must hold it). The most valuable directed tests force a fast result behind a slow same-ID one and confirm in-order delivery, and force a read/write hazard to confirm the bus does not order them. Different-ID out-of-order completion gets its own treatment in Chapter 8.4.

8. Interview Questions

9. Summary

The same-ID ordering rule is AXI's core ordering guarantee, and it's narrow by design: for a given AxID, completion order equals issue order — same-ARID reads return data in issue order, same-AWID writes return B responses in issue order, with the system holding back any ready-early later transaction to preserve it. The limits are as important as the rule: different IDs are not ordered (they may reorder — 8.4), and reads and writes are not ordered relative to each other (separate ID spaces — the manager must enforce any read/write dependency by waiting on responses). And there's a performance edge: same-ID transactions across multiple slaves force the interconnect to serialize (holding fast responses behind slow ones), so one-ID-per-slave or distinct IDs avoid cross-slave head-of-line blocking.

The discipline this yields: use one ID to order same-direction accesses (accepting in-order, possibly serialized completion), distinct IDs for independent accesses (throughput via reordering), and explicit response-waits for read/write dependencies (which IDs can't express). Bugs are either assumed ordering that wasn't guaranteed (data hazards) or over-imposed ordering that wasn't needed (lost throughput). Next: the flip side — different-ID and out-of-order completion — the reordering this rule deliberately permits, and the hazards it introduces.

10. What Comes Next

You've got the ordering guarantee; next, the reordering it permits:

8.4 — Different-ID & Out-of-Order Completion (coming next) — how different-ID transactions reorder, the throughput it buys, and the hazards to manage.

Previous: 8.2 — Transaction IDs. Related: 6.3 — AxID for ID mechanics, and 8.1 — Why Outstanding Transactions Exist for the concurrency this orders. For the broader protocol catalog, see the AMBA family overview doc.