AMBA AXI · Module 17

ID Mismatch

Diagnose AXI responses delivered to the wrong transaction — a BID/RID that doesn't match the outstanding AWID/ARID, broken same-ID ordering, or an interconnect ID-remapping bug. Why a mismatched ID corrupts the manager's outstanding tracking even when the data is correct, and how to trace it through the ID-tag mechanism.

A wrong response code (17.5) is the bus reporting a problem; a wrong response ID is the bus delivering a correct response to the wrong transaction. AXI uses ID tags (AWID/BID, ARID/RID) to associate each response with its request, which is what allows multiple outstanding and out-of-order transactions (Module 8). When the ID is wrong — a BID/RID that doesn't match any outstanding AWID/ARID, or that matches the wrong one — the manager attributes the response to the wrong request, corrupting its outstanding tracking even though the data and response code may be perfectly correct. This is among the most insidious bugs: nothing is malformed, no error is raised, but transactions get crossed. This chapter diagnoses the ID-mismatch family — unmatched IDs, broken same-ID ordering, and interconnect remapping bugs — and the ID-tag mechanism you trace through.

1. What IDs Do and How a Mismatch Corrupts Tracking

Every AXI transaction carries an ID: the request (AWID/ARID) and its response (BID/RID) share the same ID, and the manager uses it to match each returning response to the outstanding request it issued. This tag is what enables multiple outstanding and out-of-order completion: responses can come back in any order across IDs, and the manager sorts them out by ID. A mismatch — a response whose ID doesn't correspond to the right outstanding request — breaks this matching: the manager either can't find an outstanding request for the ID (orphan response) or matches it to the wrong request (crossed transactions), corrupting its tracking even when the payload is correct.

Figure 1 — IDs match responses to requests, and a mismatch breaks the matching. Each request (AWID/ARID) and its response (BID/RID) share an ID; the manager matches returning responses to outstanding requests by that tag, which is what allows out-of-order completion across IDs. A mismatched response ID either has no matching outstanding request (orphan) or matches the wrong one (crossed transactions) — corrupting the manager's outstanding tracking even though the data and response code may be correct.

2. The Crossed-Response Signature

The clearest mismatch: a response comes back with an ID that doesn't match the request it's actually answering. The manager, matching by ID, delivers the response to the wrong outstanding transaction — so transaction A's data is attributed to transaction B and vice versa. The sequence shows two outstanding reads with different IDs whose R responses come back with swapped IDs.

Figure 2 — crossed responses from swapped IDs. The manager issues two outstanding reads: ARID=1 (to address A) and ARID=2 (to address B). The responses return with the IDs swapped — RID=2 carries A's data, RID=1 carries B's data. The manager matches by ID, so it attributes A's data to the ARID=2 transaction (which wanted B) and B's data to the ARID=1 transaction (which wanted A) — both transactions get the wrong data, with no error raised. The bug is the ID routing, not the data.

3. Broken Same-ID Ordering and the Orphan Response

Two more mismatch modes. Broken same-ID ordering: AXI requires responses for the same ID to return in request order (Module 8); if two same-ID transactions complete out of order, the manager matches the first response to the first outstanding same-ID request — attributing the second's data to the first. Orphan response: a BID/RID arrives that matches no outstanding request (an ID never issued, or a duplicate response), so the manager has nowhere to put it — a protocol violation that often indicates a duplicated or fabricated response.

Figure 3 — broken same-ID ordering and the orphan response. Same-ID ordering: two transactions with ID=1 must complete in issue order; if the responses return out of order, the manager (matching the oldest outstanding ID=1 request to the first response) attributes the second transaction's data to the first. Orphan response: a response ID matches no outstanding request — never issued, or a duplicate — leaving the manager nowhere to deliver it. Both corrupt tracking: one crosses same-ID transactions, the other injects a response with no home.

4. The Interconnect ID-Remapping Bug

In an interconnect, manager IDs are remapped: the fabric appends source-port bits to make IDs unique across managers (Module 8/12), routes responses by the appended bits, and strips them before returning to the original manager. Each step is a place an ID mismatch can originate: appending wrong bits, routing by the wrong field, or failing to strip (returning a wider ID than the manager sent) or stripping wrong (returning the wrong original ID). So an ID mismatch in a multi-master system is frequently an interconnect remapping bug, not a slave or manager bug — and tracing it means following the ID transformation through the fabric.

Figure 4 — the interconnect ID-remapping path and where it breaks. On the request side, the interconnect appends source-port bits to the manager's ID (making it unique across managers); on the response side, it routes by those appended bits and strips them, returning the original ID. Each transform is a failure point: wrong append, routing by the wrong field, failing to strip (returning a too-wide ID), or stripping to the wrong original ID. An ID mismatch in a multi-master system usually originates here, so trace the ID transformation through the fabric.

5. Common Misconceptions

Myths to unlearn

"If the data is correct, the IDs don't matter." They do — a response with the wrong ID is delivered to the wrong transaction, so even correct data ends up attributed to the wrong request, corrupting the manager's tracking. The ID is how the response finds its home; a wrong ID crosses transactions silently.
"An ID mismatch raises an error response." It doesn't — the response code can be OKAY; the ID is wrong, not the status. There's no protocol error code for "wrong ID," so it's silent: the response is well-formed and successful, just routed to the wrong transaction.
"Different-ID responses must come back in order." No — AXI allows different IDs to complete in any order; that's the whole point of IDs. Only same-ID responses must be in order. Enforcing or expecting cross-ID ordering is a misunderstanding; the bug is same-ID out-of-order or a wrong-ID delivery.
"ID bugs are the slave's fault." Often it's the interconnect — multi-master fabrics remap IDs (append/route/strip source bits), and any step can mis-handle the ID. A mismatch in a multi-master system frequently originates in the fabric's remapping, not the slave or manager.
"An orphan response is harmless if ignored." An orphan (response ID matching no outstanding request) is a serious protocol violation — it usually means a duplicated or fabricated response, which also implies a missing response somewhere (the real one). Ignoring it hides a real fault.
"You can't tell an ID bug from a data bug." You can — an ID bug crosses which transaction gets which response while each response's payload is internally correct; a data bug corrupts the payload itself. The monitor/scoreboard distinguishes them: ID bug = right data, wrong transaction; data bug = wrong data, right transaction.

6. Debugging Insight

🔍 Debugging insight — match every response ID to an outstanding request and trace the ID transform

Diagnose ID mismatches by tracking the ID-to-outstanding-request mapping:

A transaction got the wrong (but internally valid) data. Suspect a crossed response — the response with that transaction's ID actually carried another transaction's data. Check whether the response IDs match the requests they're answering; an ID bug gives right-data-wrong-transaction (vs. a data bug's wrong-data-right-transaction).
A response ID matches no outstanding request (orphan). A fabricated/duplicated response — and it implies a missing real response elsewhere. Check for a duplicate BID/RID and for a transaction that never completed (its response was the one mis-IDed).
Same-ID transactions got crossed. Broken same-ID ordering — two same-ID responses returned out of order, so the manager matched them to the wrong same-ID requests. Confirm same-ID responses are in issue order (they're required to be).
Mismatch only in a multi-master system. Strongly suggests the interconnect remapping — trace the ID transform: are source-port bits appended correctly, is the response routed by the right field, are the bits stripped correctly back to the original ID? A too-wide returned ID = failed strip; a wrong original ID = wrong strip/route.
The monitor reconstructed the wrong transactions. Before blaming the DUT, confirm the monitor's ID matching is correct (16.3) — a monitor that mis-matches IDs produces false ID-mismatch reports. Verify the monitor against known traffic first.
Intermittent, only under interleaving. ID bugs often appear only with multiple outstanding / interleaved transactions (a single outstanding transaction has no ID to confuse) — reproduce with concurrent multi-ID traffic.

The core method: match every response ID to its outstanding request, and when one doesn't match (or matches the wrong one), trace the ID through the transform path — manager → interconnect append/route/strip → slave and back. An ID bug is right response, wrong destination, distinct from a data bug's wrong content.

7. Verification Insight

✅ Verification insight — check ID matching and same-ID ordering in the scoreboard, and stress multi-ID interleaving

ID mismatches are caught by transaction-matching in the scoreboard, because they're invisible at the signal and data level — the bug is which transaction a correct response belongs to. Disciplines: (1) Match every response to an outstanding request by ID — the scoreboard (16.4) maintains per-ID queues of outstanding transactions and verifies each BID/RID matches the head of its ID's queue, flagging an orphan (no outstanding request for that ID) and a crossed response (data attributed to the wrong transaction); this is the same per-ID-queue structure the monitor (16.3) uses, and it's the only mechanism that detects an ID bug since the payload itself is internally valid. (2) Enforce same-ID ordering, allow cross-ID reordering — assert that same-ID responses return in issue order (a protocol requirement) while not enforcing any order across different IDs (a protocol freedom); getting this exactly right matters because enforcing cross-ID order causes false failures and ignoring same-ID order misses real reordering. (3) Verify the data goes with the right transaction — the scoreboard checks not just that the data is internally correct but that it matches the request that ID belongs to (right data, right transaction), which is what catches the crossed-response case where each payload is valid but mis-delivered. (4) Stress multi-ID interleaving — ID bugs only manifest with multiple outstanding and interleaved transactions (a single outstanding transaction has no ID to confuse), so constrained-random (16.6) must spread IDs widely and overlap transactions, and negative tests (16.7) can inject a deliberately-swapped or orphan ID to confirm the scoreboard catches it. (5) For interconnects, verify the ID remap end-to-end — observe the ID at the manager port and at the slave port (passive monitors, 16.8) and confirm the append/route/strip transform preserves the manager's view (the manager gets back exactly the ID it sent, with the right data), catching remapping bugs that a single-point check misses. The crucial framing: an ID mismatch is right response, wrong destination — the data and code are fine, but the transaction binding is broken — so it's detectable only by checking the response-to-request matching, which is precisely why the monitor reconstructs by ID and the scoreboard checks by per-ID queue. The highest-value, easiest-to-miss case is the crossed response under heavy interleaving, because every individual response looks correct and only the transaction-level matching reveals the cross; an environment that checks data but not ID-matching is blind to it. This is the ordering/transaction category of the rule catalog (16.1) made concrete in debugging — the bug is in the relationships between transactions, not in any single one. Next, we tackle the hardest hang of all: a genuine deadlock, traced through the dependency graph.

8. Interview Questions

9. Summary

An ID mismatch delivers a correct response to the wrong transaction — the data and response code are fine, but the ID binding is broken. AXI's ID tags (AWID/BID, ARID/RID) match each response to its request, enabling multiple outstanding and out-of-order completion across IDs; a mismatch breaks the matching, producing an orphan (response ID matches no outstanding request — implying a duplicated/fabricated response and a missing real one) or a crossed response (matched to the wrong request, so right data lands in the wrong transaction). The modes are: crossed/swapped IDs, broken same-ID ordering (same-ID responses must be in issue order; different-ID may reorder freely), and the interconnect remap bug (the fabric appends source-port bits, routes by them, and strips them — any of append/route/strip can mis-handle the ID, and this is the usual origin in multi-master systems).

The defining property is that an ID mismatch is silent — no error code, nothing malformed — so it's detectable only by transaction-matching: the monitor reconstructs by ID and the scoreboard maintains per-ID outstanding queues, checking that every response matches its request (catching orphan/crossed), that same-ID responses are in order, and (for interconnects, via dual-port observation) that the end-to-end ID binding survives the remap. It's a relationship bug — every individual element is correct, only the binding between transactions is wrong — which is why it's invisible to per-signal assertions and per-beat data checks and catchable only by stateful, transaction-level checking. This is the ordering/transaction category of the rule catalog made concrete: the bug is in the relationships between transactions, and only a relationship-checking component sees it. It manifests only under multi-outstanding, interleaved, ID-colliding traffic. Next, the hardest hang: a genuine deadlock, traced through the dependency graph.

10. What Comes Next

You can now trace mis-routed responses; next, the hardest hang of all:

17.7 — Debugging Deadlock (coming next) — finding and breaking AXI deadlocks via the dependency graph, where multiple channels and transactions wait on each other in a cycle that no single signal reveals.

Previous: 17.5 — BRESP / RRESP Errors. Related: 8.3 — Same-ID Ordering and 8.4 — Different-ID Ordering for the ordering rules, and 16.3 — AXI Monitors for the per-ID transaction reconstruction that catches mismatches.