AMBA AXI · Module 12

Mux/Demux & ID-Based Routing

How the AXI interconnect routes the forward path by address (demux) and the response path back by ID (mux) — ID extension with source bits, response demultiplexing to the right manager, ID-width budgeting, and order preservation.

The interconnect has two routing directions to get right: the forward path (a manager's request → the correct subordinate) and the response path (a subordinate's response → the correct manager). These use different keys: the forward path routes by address (decode → demux), and the response path routes by ID (mux back to the originating manager). The mechanism that makes response routing work with multiple managers is ID extension — appending source bits so responses can be demultiplexed home. This chapter ties together the demux/mux structure, ID-based return routing, ID-width budgeting, and order preservation (building on Chapters 8.2 and 8.5).

1. Forward by Address, Back by ID

The two directions route on two different keys:

Forward (request) — demux by address: a manager's request enters the interconnect, the decoder (Chapter 12.3) maps AxADDR to a subordinate port, and the request is demultiplexed to that port. One manager fans out to many possible subordinates; the address selects which.
Response — mux by ID: subordinates return responses (BID/RID carrying the transaction's ID); the interconnect multiplexes responses from many subordinates back to the managers, using the ID to route each response to the originating manager. Many subordinates fan in to many managers; the ID selects which manager.

So routing is asymmetric in key: address forward, ID backward. The address says where a request goes; the ID says where a response came from (and thus must return to). Both must be correct for a transaction to complete end-to-end.

Figure 1 — forward demux by address, response mux by ID. A manager's request is demultiplexed to the subordinate its AxADDR decodes to (forward path, address key). Responses from subordinates are multiplexed back to the originating manager using the transaction ID (response path, ID key). Address routes requests out; ID routes responses home.

2. The Round Trip

A transaction's full path through the interconnect, both directions:

Figure 2 — the round trip. The manager issues a request; the interconnect decodes the address and demuxes it to the target subordinate (extending the ID with source bits); the subordinate responds with the extended ID; the interconnect uses those bits to mux the response back to the originating manager, stripping the extension so the manager sees its original ID. Address out, ID home.

3. ID Extension — How Responses Find Home

The response mux works because of ID extension (Chapter 8.2). When a manager's transaction enters the interconnect, the interconnect appends source-identifying bits to its AxID — encoding which manager/port it came from. The subordinate sees this wider ID and echoes it on the response (BID/RID). On the way back, the interconnect reads those source bits to demultiplex the response to the correct originating manager, then strips them so the manager sees its original ID.

This is what lets multiple managers reuse the same ID value (e.g., two masters both using ARID=0) without collision: the appended source bits keep them distinct internally, and they're the routing key for the response mux. So ID extension is the mechanism behind response routing — without it, the interconnect couldn't tell whose response is whose when managers share ID values. The original ID is preserved end-to-end (extended going in, stripped coming out), so each manager's view of its own IDs is unchanged.

Figure 3 — ID extension enables response routing. The interconnect appends source bits to each manager's AxID (so two managers' ARID=0 become distinct {src0,0} and {src1,0} at the subordinate); the subordinate echoes the extended ID on its response; the interconnect routes by the source bits back to the right manager and strips them. The source bits are the response mux's routing key.

4. ID-Width Budgeting and Order Preservation

Two consequences of ID extension:

ID-width budgeting. Because the interconnect appends source bits, the ID width grows toward the subordinate — the subordinate (and the path to it) must carry the full extended width: roughly subordinate_ID_width ≥ manager_ID_width + ceil(log2(number_of_managers/ports)). If the subordinate's ID width is too narrow to hold the manager ID plus source bits, the extra bits are lost, and responses misroute to the wrong manager (a silent multi-master data-corruption bug, Chapter 8.5). So ID width must be budgeted across the interconnect hierarchy at integration time.

Order preservation. The response mux must preserve same-ID ordering (Chapter 8.3): responses with the same (full) ID must return to the manager in issue order, while different-ID responses may interleave. So the mux isn't a simple combinational select — it must respect per-ID ordering as it merges responses, including across subordinates (which can force the serialization of Chapter 8.5). The demux/mux logic is where the interconnect's ordering guarantees are physically enforced.

Figure 4 — ID-width budgeting and ordering. The interconnect's appended source bits make the subordinate-side ID wider than the manager-side; the subordinate ID width must be ≥ manager width + source bits, or responses misroute. The response mux must also preserve same-ID order (in issue order) while letting different IDs interleave — enforcing the ordering guarantees in the routing path.

5. Common Misconceptions

Myths to unlearn

"Both directions route by the same key." No — forward routes by address (decode/demux), backward routes by ID (mux). The address says where a request goes; the ID says which manager a response returns to.
"The ID selects the subordinate." It does not — the address selects the subordinate (decode). The ID handles response return-routing and ordering, not slave selection.
"Two managers can't reuse the same ID value." They can — ID extension appends source bits so their transactions stay distinct internally, and those bits route responses home. The managers' original ID values are preserved.
"The subordinate ID width can equal the manager ID width." Often not — the interconnect appends source bits, so the subordinate width must be wider (manager width + source bits) or responses misroute. ID width must be budgeted.
"The response mux is a simple select." It must preserve same-ID ordering (in issue order) while letting different IDs interleave — the ordering guarantees are enforced in the mux.
"ID extension changes what the manager sees." No — the extension is added going in and stripped coming out, so each manager sees its original ID unchanged.

6. Debugging Insight

🔍 Debugging insight — misrouted responses and ID-width issues

Mux/demux bugs are routing failures in one direction or the other:

Request reaches the wrong subordinate? A forward/address problem — the decoder/demux is wrong (address map error, Chapter 12.3). Check the address decode.
Response goes to the wrong manager (multi-master corruption)? A response/ID problem — ID extension/routing is broken, or the subordinate ID width is too narrow to carry the source bits, so they're lost and the mux can't route home. Check the extended ID width along the path (Chapter 8.5). This only manifests with multiple managers active.
Responses out of order for one manager? The mux isn't preserving same-ID order — same-ID responses interleaved or reordered. Check the per-ID ordering in the response path (Chapter 8.3).
A manager sees a wrong/unexpected ID on its response? The interconnect isn't stripping the source-bit extension correctly, so the manager sees the extended ID instead of its original.
Works with one master, corrupts with two on the same subordinate? Classic ID-collision — two managers' same ID value isn't being kept distinct by extension. Verify the source bits are appended and budgeted.

The triage: wrong-slave → forward/address; wrong-manager → response/ID-extension/width; out-of-order → mux ordering; wrong-ID-seen → strip logic; two-master-only corruption → ID collision/width. Forward bugs are address-side; backward bugs are ID-side.

7. Verification Insight

✅ Verification insight — both routing directions, multi-master ID collisions, ordering

Verify both routing directions and the ID machinery. Forward: every request routes to the address-decoded subordinate (covered with the decoder, Chapter 12.3). Response: every response routes to the originating manager by ID — drive multiple managers and assert each gets its own responses, never another's. ID collision: the highest-value test — multiple managers using overlapping ID values through the interconnect, asserting responses still route home correctly (proves ID extension and width budgeting). ID width: confirm the subordinate-side ID width accommodates the extension (a too-narrow width should be caught as misrouting). Ordering: same-ID responses return in issue order; different-ID may interleave (Chapter 8.3) — drive a reordering subordinate and confirm the mux preserves per-ID order.

Coverage should include: all manager-subordinate pairs (forward routing); multiple managers with distinct and overlapping IDs (response routing + collision); responses returning in varied orders (ordering preservation); and the full-load case (all managers active, IDs colliding, responses interleaved). The highest-value tests are the multi-master ID-collision scenario (the core of response routing — a misroute here silently corrupts data across masters) and the out-of-order response with same-ID ordering check. Because response routing is invisible in single-master testing, multi-master concurrency with ID collisions is the essential stress — it's where the mux/demux and ID-extension logic is actually exercised.

8. Interview Questions

9. Summary

The interconnect routes in two directions with two keys: forward by address (decode AxADDR → demultiplex the request to the target subordinate) and response back by ID (multiplex responses to the originating manager using BID/RID). The response mux works via ID extension (Chapter 8.2): the interconnect appends source bits to each manager's AxID so transactions stay distinct (letting managers reuse ID values), the subordinate echoes the extended ID, and the interconnect routes responses home by those bits and strips them so each manager sees its original ID. Two consequences: the ID width grows toward the subordinate — which must carry manager_width + source_bits or responses misroute (budget it) — and the response mux must preserve same-ID ordering while letting different IDs interleave.

The defining insight is the address-forward / ID-backward asymmetry: address says where a request goes (destination in address space), ID says where a response returns (origin manager), and ID extension bridges them by capturing the origin on the way in. Forward bugs are address-side (wrong slave); backward bugs are ID-side (wrong manager, misrouting, ordering) — and the response/ID bugs only surface with multiple managers and ID collisions, so that's the essential verification stress. Next: putting it all together — a full multiple-managers-and-subordinates topology end-to-end.

10. What Comes Next

You've got the routing mechanism; next, the full multi-master/multi-slave picture:

12.6 — Multiple Managers & Subordinates (coming next) — a complete multi-master, multi-slave topology end-to-end, combining decode, arbitration, and ID routing.
12.7 — Clock & Reset in Interconnect (coming soon) — clock/reset domains and width/protocol converters in the fabric.

Previous: 12.4 — Arbiter & Arbitration. Related: 8.2 — Transaction IDs and 8.5 — Interconnect Implications for the ID-extension foundation. For the broader protocol catalog, see the AMBA family overview doc.