Interconnect Routing

Chapter 13.5 covered the control functions (decode + arbitrate); this chapter follows a transfer's physical journey through the matrix — interconnect routing, end to end. A transfer routes in two directions. Forward (request, master → slave): the master drives address/control into its port, decode picks the target slave port, the slave's arbiter grants this master, and a forward mux connects the master's address/control/write-data to the slave. Backward (response, slave → master): the slave performs the access and drives its response, and a return mux routes the read data / HREADYOUT / HRESP back to the originating master — which the matrix must remember. Critically, routing respects the AHB pipeline: the forward route happens in the address phase, the return route in the data phase — and a long forward path (in a large matrix) may be registered/pipelined (adding a cycle of latency for better timing), as long as each transfer's address and data phases stay aligned. This chapter traces the forward and backward routing, the remember-the-origin requirement, and the pipeline-alignment rule.

1. What Is It?

Interconnect routing is the end-to-end path a transfer takes through the matrix — forward (request) and backward (response).

• Forward (master → slave): decode (which slave port) → arbiter grant (this master wins the slave) → forward mux (connect master's address/control/write-data to the slave).
• Backward (slave → master): the slave responds → return mux routes HRDATA/HREADYOUT/HRESP back to the originating master (remembered by the matrix).
• Pipeline-aligned: forward routing is address-phase; return routing is data-phase; each transfer's two phases stay aligned across the matrix.

So routing is the physical realization of the control decisions: decode and arbitrate (chapter 13.5) decide the connection; routing makes it — muxing the master's signals to the slave (forward) and the slave's response back to the master (backward). The matrix is, mechanically, a set of muxes steered by the decode/grant: a forward mux at each slave (selecting which master drives it) and a return mux at each master (selecting which slave's response it receives). And it must track the origin — which master issued each in-flight transfer — so the response routes back correctly. So interconnect routing is the bidirectional steering of request (forward) and response (backward) through the matrix's muxes, origin-tracked and pipeline-aligned. It's how a transfer actually traverses the fabric.

2. Why Does It Exist?

Interconnect routing exists because the matrix's decisions (decode, arbitrate) must be physically carried out — the master's signals must actually reach the chosen slave, and the slave's response must actually return to the right master — and doing this across a many-master, many-slave fabric, while respecting the pipeline, requires the forward/backward muxing and origin-tracking.

The decisions need physical realization: decode (chapter 13.5) decides which slave a transfer wants; arbitrate decides which master wins a slave. But those are just decisions — signals must still flow: the master's address/control/write-data must physically get to the slave, and the slave's read-data/response must physically get back to the master. Routing is that physical flow — the muxing that connects the decided master to the decided slave (forward) and back (backward). So routing exists to carry out the control decisions. Decode/arbitrate decide; routing connects. So routing is the execution of the control.

The forward routing carries the request: the forward mux at each slave selects (per the grant) which master's address/control/write-data drives that slave. So the granted master's signals are muxed onto the slave. This is needed because multiple masters could drive each slave (it's shared), so a mux must select the granted one. So forward routing exists to connect the granted master to the slave. So the request flows forward through the per-slave mux.

The backward routing + origin-tracking carries the response: the slave drives its response, but which master should receive it? The one that issued the access. So the matrix must remember which master each in-flight transfer came from (its origin port), and the return mux at each master selects (per that origin) which slave's response that master receives. So backward routing + origin-tracking exists to return each response to its initiator. This is essential with multiple in-flight transfers (concurrent, chapter 13.4) — each response must find its own master. So responses flow backward, origin-tracked. So interconnect routing exists to physically execute the matrix's control: forward muxing connects the granted master to the slave (carrying the request), backward muxing + origin-tracking returns each response to its initiator. And it must respect the pipeline — forward in the address phase (so the slave samples the right master's address-phase signals), backward in the data phase (the response) — keeping each transfer's phases aligned even as it traverses the fabric. The reason a long forward path may be registered is timing: across a large matrix, the forward path (decode + arbitrate + mux + wire) can be too slow for one cycle, so the matrix pipelines it (a register stage), trading a cycle of latency for meeting timing — as long as the address/data alignment is preserved (the register delays the whole transfer consistently). So routing exists, bidirectional and pipeline-aligned, to make the matrix's decisions real.

3. Mental Model

Model interconnect routing as an airport's baggage handling — a bag (transfer) is tagged at check-in for its destination flight (decode picks the slave), routed through the conveyor system to the correct gate (forward routing to the slave), where it's loaded (the access happens); and crucially, the system remembers which passenger and origin each bag belongs to (origin-tracking), so when a bag needs to come back (the response — say, read data), it's routed back to the right carousel for that passenger (backward routing to the originating master) — and the whole thing runs on a timed schedule so bags and passengers stay synchronized (pipeline alignment).

An airport's baggage system handles many bags (transfers) for many passengers (masters) to many flights/gates (slaves). At check-in, each bag is tagged for its destination (decode: the address picks the slave). The conveyor system routes it forward to the correct gate (forward routing through the matrix muxes to the chosen slave), where it's loaded onto the plane (the access happens). Crucially, the system tracks which passenger each bag belongs to (origin-tracking — remembering which master issued the transfer). So when something needs to come back to the passenger — say, a bag is returned, or the passenger's arriving luggage comes in (the response: read data) — the system routes it backward to the right carousel for that passenger (backward routing to the originating master), not to some other passenger. And the whole operation runs on a timed schedule (the pipeline): bags move through stages in sync, so a passenger's outbound and inbound luggage stay coordinated. If a route is long (a big airport), there might be an intermediate sorting station (a pipeline register) that adds a little time but keeps things flowing smoothly. So tag-and-route-forward, remember-the-owner, route-the-response-back, on a synchronized schedule.

This captures routing: tagging the bag for its flight = decode (address → slave); the conveyor routing forward to the gate = forward routing (master → slave mux); loading onto the plane = the slave access; tracking which passenger = origin-tracking; routing the return to the right carousel = backward routing (response → originating master mux); the timed schedule = pipeline alignment; an intermediate sorting station = a pipeline register on a long path. Route the request to the destination, remember the owner, return the response to that owner — synchronized.

Watch a transfer route forward then return, pipeline-aligned:

The model's lesson: route the request to its destination, remember the owner, return the response to that owner — synchronized. In the waveform, the forward route (addr phase) connects M0→S1, and the return route (data phase) sends S1's response back to the remembered origin M0.

4. Real Hardware Perspective

In hardware, routing is the matrix's mux network — a forward mux at each slave port and a return mux at each master port — plus the origin-tracking registers, all steered by the decode/grant signals, with pipeline registers inserted on long paths.

The forward mux per slave selects the master driving that slave: at each slave port, a mux chooses which master's address/control/write-data connects to the slave, controlled by that slave's arbiter grant. So if SRAM's arbiter grants the CPU, SRAM's forward mux selects the CPU's signals. This mux is wide (it muxes the full address/control/write-data bus) and there's one per slave. So in hardware, forward routing is per-slave forward muxes. So the request side is S forward muxes.

The return mux per master + origin-tracking selects the slave's response for that master: at each master port, a mux chooses which slave's response (HRDATA/HREADYOUT/HRESP) connects back to the master, controlled by which slave that master is currently accessing — which the matrix tracks (the master's address-phase decode, registered into the data phase, says which slave's response to expect). So the matrix remembers (registers) each master's target-slave from the address phase to select the right return-mux input in the data phase. So in hardware, backward routing is per-master return muxes steered by registered origin/target info. So the response side is M return muxes + tracking registers.

The pipeline registers on long paths: in a large matrix (many masters × slaves, big crossbar), the forward path (decode → arbiter → wide mux → long wires to the slave) can exceed a clock period. So the matrix registers the path — inserting a pipeline stage — which adds a cycle of latency but meets timing. The crucial constraint: the register must delay the transfer consistently so the address and data phases stay aligned (the slave still sees a coherent address-then-data sequence, just shifted a cycle). So a registered matrix has higher latency (extra cycles) but the same correctness (aligned pipeline). So in hardware, routing is forward muxes (per slave) + return muxes (per master) + origin-tracking registers, steered by decode/grant, with pipeline registers on long paths trading latency for timing — all preserving address/data alignment. The mux network is the matrix's datapath; decode/arbitrate (chapter 13.5) control it. So the hardware is a steered, pipeline-aware mux crossbar.

5. System Architecture Perspective

At the system level, interconnect routing is where the matrix's latency characteristics are set — the routing depth (and any pipeline registers) determine access latency — and it's a key part of the area/timing/latency tradeoff in sizing a matrix.

The routing sets latency: a transfer's latency through the matrix includes the routing — the forward path (decode + arbitrate + mux + wires) and the return path. In a small matrix, this is combinational (no extra cycles) — routing adds no latency beyond the slave's own. In a large matrix with pipeline registers (on long forward/return paths), routing adds cycles — each register stage is +1 cycle of access latency. So the matrix's size and pipelining directly set its added latency. So at the system level, routing depth is a latency knob: more pipelining (for timing/scale) → more latency. A latency-sensitive system must account for the matrix's routing latency (especially if pipelined). So routing is where matrix latency lives.

The area/timing/latency tradeoff: sizing a matrix balances three things, and routing is central to all. Area: the mux network scales with masters × slaves (chapter 13.3) — more ports, bigger crossbar, more area. Timing: a bigger crossbar has longer routing paths (slower) — which may need pipeline registers to meet the clock. Latency: those pipeline registers add cycles. So the tradeoff: a bigger/faster-clock matrix needs more pipelining (area + latency); a smaller/slower matrix can be combinational (less area/latency but lower clock or fewer ports). So at the system level, routing is the locus of the matrix's area/timing/latency tradeoff — the architect sizes the matrix (ports, sparsity, pipelining) to balance these for the system's needs. Sparse matrices (chapter 13.3) help by removing routing paths (less area, shorter paths). So routing structure is a primary design lever.

The correctness-across-scale view: the pipeline-alignment requirement is a correctness invariant the routing must maintain regardless of size or pipelining. No matter how many pipeline stages the routing adds, each transfer's address phase and data phase must stay aligned (the slave sees address then data coherently; the master gets the response for the right transfer). So the routing's pipelining is latency-adding but correctness-preserving — a well-designed matrix can add routing depth without breaking the protocol. So at the system level, interconnect routing sets the matrix's latency (routing depth + pipeline stages), is the center of the area/timing/latency tradeoff (sized by ports/sparsity/pipelining), and must preserve pipeline alignment across any scale (a correctness invariant). So routing is where the matrix's physical characteristics — latency, timing, area — are determined, while its logical correctness (alignment) is held invariant. Designing a matrix is largely designing its routing: how many ports, how sparse, how pipelined — trading area, timing, and latency while keeping the pipeline aligned. So routing is the matrix's physical-design heart, complementing the control (decode/arbitrate) of chapter 13.5.

6. Engineering Tradeoffs

Interconnect routing embodies the steered-mux, pipeline-aligned datapath design.

• Combinational vs registered routing. Combinational routing adds no latency (lowest latency) but limits clock speed / matrix size (long paths); registered (pipelined) routing meets timing at scale (+latency). Small matrices are combinational; large ones pipeline.
• Full vs sparse routing. Full routing (every master to every slave) maximizes connectivity at max mux/area/path-length cost; sparse routing (omit unneeded paths) cuts area and shortens paths (better timing) at reduced connectivity. Sparse where connectivity allows.
• Latency vs timing. Adding pipeline registers to the routing improves timing (higher clock, bigger matrix) at the cost of access latency (+cycles). The architect balances per the system's latency tolerance and clock target.
• Origin-tracking depth. Tracking the origin for in-flight transfers (to route responses back) costs registers proportional to the in-flight depth. AHB's simple pipeline keeps this small; deeper-outstanding protocols (AXI) need more tracking.

The throughline: interconnect routing physically carries out the matrix's control — forward (request): decode picks the slave port, the arbiter grants the master, a forward mux (per slave) connects the master's address/control/write-data to the slave; backward (response): a return mux (per master) routes the slave's response to the originating master, which the matrix remembers (origin-tracking). Forward routing is address-phase, return is data-phase, with each transfer's phases kept aligned. The matrix is a steered mux network (forward muxes per slave, return muxes per master); long paths are registered/pipelined (+latency, better timing). Routing sets the matrix's latency and is the center of the area/timing/latency tradeoff (ports, sparsity, pipelining), while preserving pipeline alignment as a correctness invariant.

7. Industry Example

Trace a transfer routing through a matrix.

A matrix connects a CPU and DMA to SRAM and flash; it's large enough to be pipelined.

• Forward route (CPU → SRAM). The CPU drives a read address into its port. Its decode determines the target is the SRAM port. SRAM's arbiter grants the CPU. The forward mux at SRAM selects the CPU's address/control, connecting it to SRAM. So the request routed forward: CPU port → decode → SRAM arbiter grant → forward mux → SRAM.
• Origin tracked. The matrix remembers that this SRAM access came from the CPU (the origin), registering it from the address phase into the data phase.
• Backward route (SRAM → CPU). SRAM reads the data and drives its response. The return mux at the CPU's port, steered by the remembered origin/target, selects SRAM's response (HRDATA/HREADY/HRESP) and routes it back to the CPU. So the response routed backward to the originating master.
• Pipelined matrix. Because the matrix is large, the forward path is registered — adding one cycle of latency. So the CPU's SRAM access takes one extra cycle versus a combinational matrix. Crucially, the matrix delays the whole transfer coherently: the address phase and data phase both shift by the register's cycle, so SRAM still sees a coherent address-then-data sequence and the CPU gets SRAM's response aligned to its (shifted) transfer. The pipeline alignment is preserved.
• Concurrent route (DMA → flash). Simultaneously, the DMA's transfer routes forward to flash (different slave, different forward mux), and flash's response routes back to the DMA (different return mux) — fully concurrent with the CPU↔SRAM route (chapter 13.4), because they use independent muxes/paths.
• Latency accounted. The system's latency budget accounts for the matrix's routing latency (the +1 pipeline cycle) on top of the slaves' own latencies — important for latency-sensitive accesses.

The example shows routing end-to-end: forward (decode → grant → forward mux to the slave), origin-tracked, backward (return mux to the originating master), with the large matrix's pipeline register adding latency while preserving phase alignment, and concurrent routes for different master/slave pairs. This is how transfers physically traverse the matrix.

8. Common Mistakes

9. Interview Insight

Interconnect routing is a datapath interview topic — the forward/backward muxing, origin-tracking, and pipeline-alignment points are the signals.

The answer that lands traces both directions with the key points: "A transfer routes through the matrix in two directions. Forward — the request — the master drives its address and control into its port, decode determines which slave port it targets, that slave's arbiter grants the master, and a forward mux connects the master's address, control, and write data to the slave. Backward — the response — the slave performs the access and drives its read data, HREADY, and HRESP, and a return mux routes that response back to the originating master. For that to work, the matrix must remember which master issued each in-flight transfer — origin-tracking — so the return mux sends each response to the right master. Mechanically, the matrix is a mux network: a forward mux per slave, selecting which master drives it, and a return mux per master, selecting which slave's response it receives, both steered by the decode and grant. Crucially, routing respects the pipeline: the forward routing happens in the address phase so the slave sees the right master's address-phase signals, and the return routing happens in the data phase. In a large matrix, the forward path can be too long for one cycle, so it's registered, adding a cycle of latency — but the register must delay the whole transfer consistently so the address and data phases stay aligned. So routing executes the control decisions, tracks the origin to return responses, and preserves pipeline alignment even when pipelined." The forward/backward muxing, origin-tracking, and pipeline-alignment points are the senior signals.

10. Practice Challenge

Reason from interconnect routing.

1. Forward and backward. Describe a transfer's forward route (master → slave) and backward route (slave → master).
2. Origin-tracking. Explain why the matrix remembers the originating master and how it's used.
3. Read the waveform. From Figure 2, identify the address-phase forward route and the data-phase return route.
4. Pipeline alignment. Explain why a registered (pipelined) matrix adds latency but stays correct.
5. Tradeoffs. Explain how routing relates to the matrix's area, timing, and latency.

11. Key Takeaways

• Routing executes the control decisions — decode/arbitrate decide the connection; routing physically makes it (muxing the master to the slave forward, and the response back).
• Forward (request): decode picks the slave port → the slave's arbiter grants the master → a forward mux (per slave) connects the master's address/control/write-data to the slave.
• Backward (response): a return mux (per master) routes the slave's HRDATA/HREADYOUT/HRESP to the originating master, which the matrix remembers (origin-tracking) — essential with concurrent transfers.
• The matrix is a steered mux network — forward muxes per slave, return muxes per master, controlled by decode/grant — the matrix's physical datapath.
• Routing respects the pipeline — forward is address-phase, return is data-phase; a long forward path may be registered (+latency, better timing), but must delay the whole transfer consistently to keep address/data phases aligned (a correctness invariant).
• Routing sets latency and drives the area/timing/latency tradeoff — sized by ports, sparsity, and pipelining; bigger/faster matrices pipeline (more latency), sparse matrices cut area and shorten paths.

12. What Comes Next

You now understand how transfers route through the matrix. The next chapters cover response aggregation and overall performance:

• HREADY Aggregation (next) — how per-slave HREADYOUT is muxed into each master's HREADY (the return-path detail that keeps timing aligned).
• Bus Matrix Performance — relating matrix topology to achievable system bandwidth.

To revisit the control this routing executes, see Decoder + Arbiter Combination; for the parallelism it enables, see Parallel Slave Access.