AMBA AXI · Module 6

AxID

AXI transaction IDs — AWID/ARID tagging, BID/RID pairing, the same-ID ordering rule, different-ID reordering, and how interconnects route responses and remap ID width.

AxID is the small field that makes AXI's concurrency work: a transaction identifier the manager attaches to each request, which the response carries back. It does two jobs at once — it scopes ordering (same-ID transactions complete in order; different-ID ones may reorder) and it lets the interconnect route responses to the right manager. This chapter covers the ID semantics (AWID/BID, ARID/RID), the same-ID/different-ID rule that's the heart of out-of-order traffic, and how interconnects use and remap IDs across ports. The full ordering model (Module 9) and outstanding-transaction depth (Module 8) build directly on what AxID establishes here.

1. The Transaction Tag

AxID is a tag the manager puts on a transaction's address: AWID on a write, ARID on a read. The response carries the matching tag back — BID on the write response, RID on every read-data beat. So a manager that issues several transactions can tell which response belongs to which request by matching the returned ID to the one it sent.

That pairing is what makes outstanding transactions usable: without IDs, a manager couldn't tell whose response is whose when several are in flight, so it would have to wait for each to finish before issuing the next (serializing itself). With IDs, responses can come back tagged and the manager sorts them — the foundation of concurrency.

Figure 1 — AxID pairing. The manager tags a write with AWID and a read with ARID; the subordinate returns the matching BID on the write response and RID on each read-data beat. The ID is how a manager pairs each returned response to the request that produced it — essential once multiple transactions are outstanding.

2. Same-ID Ordering, Different-ID Freedom

The ID's ordering rule is the single most important thing about it:

Same AxID → ordered. Transactions issued with the same ID must complete in the order they were issued. A manager that needs A-before-B gives them the same ID.
Different AxID → may reorder. Transactions with different IDs have no ordering guarantee between them — the subordinate/interconnect may complete them in any order (out-of-order completion).

So the ID is how a manager expresses ordering requirements: shared ID means "keep these in order"; distinct IDs means "these are independent, reorder freely for performance." This is the lever behind out-of-order completion (Chapters 2.4/5.2) — and the reason a high-throughput master uses multiple IDs (to allow reordering) while a strictly-ordered one may use a single constant ID.

Figure 2 — same-ID ordered, different-ID free. Two transactions with the same ID (ID0) must complete in issue order. Two with different IDs (ID0, ID1) may complete in any order — here ID1 finishes first. The manager picks: same ID to enforce order, distinct IDs to allow reordering for throughput.

3. How the Interconnect Uses IDs — Routing and Width Remapping

IDs do double duty: besides ordering, they're how the interconnect routes responses back to the right manager. When several managers share a subordinate, the interconnect must remember which manager issued each transaction so it can return the response there. It does this by extending the ID: on the way to the subordinate, it appends bits identifying the source manager port, producing a wider ID that's unique across managers; on the response, it uses those appended bits to route back, then strips them so the manager sees its original ID.

Figure 3 — interconnect ID width remapping. Two managers both issue ID=2. The interconnect appends source-port bits, so the subordinate sees distinct IDs ({A,2} and {B,2}); responses carry those wider IDs back, and the interconnect routes by the appended bits and strips them, returning the original ID=2 to each manager. This is why the subordinate-side ID is wider than the manager-side ID.

Two consequences: the subordinate-side ID width is larger than the manager-side width (it must hold the appended routing bits), and a subordinate may see more distinct IDs than any single manager uses. Conversely, the ordering rule is scoped to the full ID seen at each point: same-ID-from-the-same-manager stays ordered, but two managers' same-numbered IDs are different full IDs after remapping, so they're (correctly) independent.

4. Read and Write ID Spaces Are Separate

AWID and ARID are independent ID spaces: a write with AWID=3 and a read with ARID=3 are not related by their shared number — the write-ordering rule applies among writes, the read-ordering rule among reads, and the two channels are independent anyway (Chapter 2.4). So sharing a numeric value between a read ID and a write ID implies no ordering between that read and that write.

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — ID semantics in one place.
// Pairing:   BID == the write's AWID;   RID == the read's ARID (every beat).
// Ordering:  same AxID  → complete in issue order
//            diff AxID  → may complete out of order
// Spaces:    AWID and ARID are separate — same number ≠ related
// Routing:   interconnect appends source-port bits (slave-side ID is wider),
//            routes the response back by those bits, strips them for the master.

Figure 4 — the AxID rules at a glance. Same ID enforces issue-order completion; different IDs allow reordering; AWID and ARID are separate spaces; and the interconnect remaps ID width to route responses back. Four facts that together define how IDs route and order traffic.

5. Common Misconceptions

Myths to unlearn

"Different transactions always complete in order." Only same-ID transactions are ordered. Different-ID transactions may complete in any order — that's how out-of-order completion (and much of AXI's performance) works.
"Giving everything one ID is fine." It's correct but serializing: a single ID forces all transactions to complete in order, killing reordering/throughput. High-performance masters use multiple IDs to allow independent transactions to reorder.
"The subordinate sees the same ID the master sent." Often not — an interconnect widens the ID (appends source-port bits) so the subordinate-side ID is larger and unique across managers; the master gets its original ID back on the response.
"AWID and ARID with the same number are related." They're separate ID spaces; a read and a write sharing a numeric ID have no ordering relationship from that. (Read/write ordering is its own topic — Module 9.)
"AxID is just routing." It's both routing (response→correct manager) and ordering (same-ID in order). The ordering role is what makes it central to the transaction model, not just plumbing.

6. Debugging Insight

🔍 Debugging insight — IDs explain both mis-routed responses and ordering bugs

AxID is the first thing to check for two distinct failure classes:

Response paired to the wrong transaction. Match each BID/RID to an outstanding AWID/ARID. A returned ID matching no outstanding transaction, or pairing to the wrong one, is a routing/ID bug — frequently in an interconnect that mis-handled the ID width remapping (wrong append/strip), sending a response to the wrong manager. The data is then attributed to the wrong request.
Ordering violated or unexpectedly serialized. If transactions you meant to be ordered complete out of order, check they actually share an AxID — different IDs are allowed to reorder, so the "bug" may be that you used distinct IDs. Conversely, if independent transactions are needlessly serialized (throughput tanks), check whether they share an ID that's forcing ordering — a common performance bug is a master that issues everything on one ID.
Same number, different space. Don't assume a read and write with the same numeric ID interact — they're separate spaces. And remember the full (remapped) ID is what ordering is scoped to, so two managers' identical numbers are independent after the interconnect widens them.

So: ID-mismatch on a response → routing/remap bug; surprising ordering (too much or too little) → check whether the transactions share an ID, and whether the interconnect remapped it.

7. Verification Insight

✅ Verification insight — IDs are central to scoreboard pairing and ordering checks

A scoreboard is organized around IDs: it tracks outstanding transactions keyed by AxID, pairs each BID/RID back to its request, and enforces the ordering rule — same-ID responses must arrive in issue order, while different-ID responses may arrive in any order (the checker must allow the reordering, not flag it). Getting this right is subtle: a naive scoreboard that expects in-order completion will false-fail on legal different-ID reordering, while one that ignores ordering will miss a real same-ID violation. So the checker keys ordering per-ID.

Coverage must exercise the ID space deliberately: multiple outstanding transactions on the same ID (verify in-order completion), multiple IDs (verify reordering is handled and pairing stays correct), and ID width-remapping through an interconnect (two managers with colliding numeric IDs, verify responses route back correctly and the original ID is restored). The classic bugs caught: a response routed to the wrong manager (remap error), a same-ID reorder (ordering violation), and a BID/RID that matches no outstanding request. Stimulus uses constrained-random IDs across the legal width; the monitor demuxes by the full ID. Mechanics in Module 16, ordering depth in Module 9.

8. Interview Questions

9. Summary

AxID is the transaction tag that does two jobs. Pairing/routing: AWID/ARID tag a request and the matching BID/RID come back, so a manager pairs responses to requests when many are outstanding, and an interconnect routes each response to the issuing manager. Ordering: same-AxID transactions complete in issue order; different-AxID transactions may reorder — so the ID is how a manager chooses ordering (one ID to serialize, many IDs to allow reordering for throughput). Read (ARID) and write (AWID) IDs are separate spaces — a shared number implies nothing.

Interconnects remap ID width, appending source-port bits so the subordinate-side ID is wider and unique across managers, then routing responses back by those bits and restoring the original ID — which is why subordinate IDs are wider and where multi-master mis-routing bugs live. Debug ID problems as either response mis-pairing (routing/remap) or ordering surprises (check whether transactions share an ID); verify with a per-ID-scoped scoreboard that allows different-ID reordering but flags same-ID violations. Next: AxLOCK and AxCACHE — the exclusive-access and memory-attribute encodings.

10. What Comes Next

You understand how IDs route and order traffic; next, the access-attribute signals:

6.4 — AxLOCK & AxCACHE (coming next) — the lock (exclusive) and cache/memory-attribute encodings.
6.5 — AxPROT, AxQOS & AxREGION (coming soon) — protection, QoS, and region signals and their system use.

Previous: 6.2 — AxBURST. For the broader protocol catalog, see the AMBA family overview doc.