AMBA AHB · Module 13

Multiple Masters

How several masters coexist on an AHB interconnect — the routing-and-arbitration problem of many masters sharing slaves: deciding which master reaches which slave, and routing each response back. A shared bus serializes masters via an arbiter; a bus matrix gives each master its own path and arbitrates per slave for concurrent access.

This opens Module 13 — AHB Bus Matrix & Interconnect, which scales AHB from one master (AHB-Lite, Module 12) up to a full multi-master fabric. The starting point is the multi-master problem: when several masters — a CPU, a DMA engine, a debug access port, perhaps a second core — share the same set of slaves (memories, peripherals), the interconnect must coordinate that sharing. Two questions must be answered for every transfer: which master gets to access a given slave (and when), and how does each slave's response get routed back to the right master. So multiple masters turn the bus from a simple point-to-point link into a routing-and-arbitration problem. There are two structural answers, which the module develops: a shared bus with an arbiter (masters take turns — serialized access) or a bus matrix (each master has its own path, arbitration happens per slave — concurrent access). This chapter frames the multi-master problem and the two solutions, setting up the matrix that the rest of the module details.

1. What Is It?

Multiple masters means several independent bus initiators share the interconnect and its slaves. Each master issues its own transfers; the interconnect must coordinate them. The core requirements:

Arbitration — decide which master accesses a given slave when more than one wants it.
Routing — connect each master's transfer to the addressed slave, and route the response (read data, HREADY, HRESP) back to the initiating master.
Identity — distinguish the masters (so responses go to the right one, and ordering is maintained).

Figure 1 — several masters share the interconnect. A CPU, a DMA engine, and a debug port each issue transfers; the interconnect must arbitrate (which master accesses a slave), route (connect master to addressed slave), and return each response to the right master. On a shared bus an arbiter serializes the masters; in a bus matrix each master can reach a different slave concurrently. The multi-master problem is coordinating shared access to slaves.

So "multiple masters" is the situation where the bus is shared among several initiators — and it fundamentally changes the interconnect's job. With one master (AHB-Lite), the interconnect just decodes and returns responses (no arbitration needed — the one master always owns the bus). With multiple masters, the interconnect must additionally arbitrate (resolve competition for slaves) and route by master identity (return each response to its initiator). So the multi-master interconnect is a routing-and-arbitration fabric, not just a decoder. This chapter establishes that problem; the two solutions (shared bus, matrix) and their mechanics fill the module. So multiple masters is the defining scenario that makes the interconnect a fabric.

Multiple masters = a routing + arbitration problem: which master reaches which slave, and route each response back

Multiple masters in one frame: several initiators (CPU, DMA, debug, …) share the interconnect and its slaves, so the interconnect must coordinate — arbitrate (which master accesses a slave when several want it), route (connect each master to the addressed slave and return the response to the right master), and track identity (so responses go to their initiator). Two structural solutions: a shared bus with an arbiter (masters take turns — access is serialized, simple/cheap) or a bus matrix (each master has its own path, arbitration is per slave — masters reach different slaves concurrently, more parallelism/bandwidth). Multiple masters turn the simple bus into a routing-and-arbitration fabric — the subject of this module.

2. Why Does It Exist?

Multiple masters exist because real systems need more than one thing initiating bus traffic — a CPU plus a DMA plus debug, or multiple cores — and once there is more than one initiator on shared slaves, coordination (arbitration + routing) becomes mandatory.

The need for multiple initiators is the root: a system often has several agents that must autonomously access memory and peripherals. The CPU executes code. A DMA engine moves data (peripheral ↔ memory) without the CPU, freeing the CPU for computation — essential for efficient I/O. A debug access port reads/writes memory for debugging, independently of the CPU. Multiple cores each execute. So real systems have several initiators by necessity — each is a "master" issuing its own transfers. So multiple masters exist because systems need concurrent, independent initiators (offloading, multi-core, debug). So the multi-master scenario is driven by real system needs, not a protocol whim.

The coordination becomes mandatory because the slaves are shared: those multiple masters access the same memories and peripherals. But a slave (and a bus) can serve one access at a time. So when two masters want the same slave (or the same shared bus), there's contention — which must be resolved. That resolution is arbitration. And each slave's response must go back to the master that issued the access — which requires routing by master identity. So the moment there's more than one master on shared slaves, arbitration and routing are required for correctness (no contention, responses to the right master). So coordination is mandatory — it's the price of sharing. So multiple masters necessitate the arbitration-and-routing machinery.

The reason there are two structural solutions (shared bus, matrix) is a cost-vs-parallelism tradeoff. A shared bus puts all masters on one bus with one arbiter — simple and cheap, but serializes the masters (only one uses the bus at a time, even if they want different slaves). A bus matrix gives each master its own path into a switch that arbitrates per slave — more hardware, but allows concurrency (masters accessing different slaves proceed in parallel), raising bandwidth. So the two solutions trade cost for parallelism: shared bus (cheap, serialized) vs matrix (costlier, concurrent). So multiple masters exist as a real need, necessitate coordination, and admit two solutions trading cost against parallelism. So this chapter's scenario — multiple masters — is the foundation of the whole interconnect module: it's why arbitration, routing, and ultimately the bus matrix exist. The rest of the module builds out the matrix solution (the high-parallelism one) in detail. (Module 10 covered arbitration on a shared bus; this module extends to the matrix.)

3. Mental Model

Model multiple masters as several chefs sharing a kitchen's stations — each chef (master) needs to use the ovens, the stovetop, and the prep counters (slaves); if there's one narrow doorway to the whole kitchen (a shared bus), only one chef can be working at a time and the others wait in line (an arbiter serializes them); but if the kitchen is laid out so each chef has their own aisle to reach the stations (a bus matrix), two chefs can use two different stations at once, and they only have to take turns when they want the same station.

A busy kitchen has several chefs (masters) and several stations — ovens, stovetop, prep counters (slaves). Each chef needs to use the stations to do their work. The question is how they share. In one layout, there's a single narrow doorway to the whole kitchen (a shared bus): only one chef can be inside working at a time; the others wait in line, and a maître d' (the arbiter) decides whose turn it is. Even if two chefs want different stations (one the oven, one the prep counter), they can't both work — the single doorway serializes them. In a better layout, the kitchen is designed so each chef has their own aisle to reach the stations (a bus matrix): now two chefs can work at two different stations simultaneously — one at the oven, one at the prep counter — and they only have to take turns when they both want the same station (then a per-station rule decides). So the same chefs and stations, but the layout determines whether they work one at a time (shared doorway) or in parallel (per-chef aisles). And throughout, each chef's finished dish must go back to that chef (routing the response to the right master).

This captures multiple masters: the chefs = the masters; the stations = the slaves; the single narrow doorway = the shared bus; the maître d' = the arbiter (serializing); each chef's own aisle = the bus matrix's per-master paths; two chefs at two stations at once = concurrent access to different slaves; taking turns at the same station = per-slave arbitration; each dish back to its chef = routing the response to the initiating master. Same chefs and stations — the layout (shared doorway vs per-chef aisles) decides serial vs parallel.

Watch two masters under arbitration on a shared bus:

Two masters serialized on a shared bus

4 cycles

Figure 2 — two masters on a shared bus, serialized by an arbiter. The CPU and DMA both want the bus. The arbiter grants the CPU first (owner = CPU): the CPU drives its transfer while the DMA waits. Then the arbiter switches (owner = DMA): the DMA drives while the CPU waits. Only one master uses the shared bus at a time — access is serialized. The 'owner' row shows the arbiter handing the bus between masters; a bus matrix would let them proceed concurrently to different slaves.

The model's lesson: same chefs and stations — the layout decides serial (shared doorway) or parallel (per-chef aisles). In the waveform, the shared bus serializes the CPU and DMA (one at a time); a matrix would let them work concurrently on different slaves.

4. Real Hardware Perspective

In hardware, supporting multiple masters means the interconnect gains an arbiter (or per-slave arbiters), master-side multiplexing (or per-master paths), and master-identity tracking to route responses — all absent in the single-master (AHB-Lite) case.

The arbitration hardware is the first addition: on a shared bus, a single arbiter samples all masters' requests and grants one at a time (Module 10). In a bus matrix, there's a per-slave arbiter — each slave port has its own arbiter resolving which master accesses that slave. So multi-master adds arbiter logic (one shared, or one per slave). This is the logic AHB-Lite omitted (chapter 12.3) — multi-master brings it back, in one form or another. So in hardware, arbiters reappear.

Figure 3 — shared bus vs bus matrix. Shared bus + arbiter: all masters drive one bus, the arbiter picks one, the others wait — access is serialized (simpler, cheaper). Bus matrix: each master has its own path into a switch that arbitrates per slave, so two masters can access two different slaves at once — concurrent, higher bandwidth. The shared bus can't let the CPU and DMA proceed together even to different slaves; the matrix can.

The routing/muxing hardware is the second: the interconnect must connect each master to the addressed slave and return the response to the initiating master. On a shared bus, the arbiter's grant muxes the active master's address/control onto the bus, and the decode muxes the selected slave's response back (to the one active master). In a matrix, there's a crossbar of paths — each master's transfer is routed (by its address decode) to the right slave port, and each slave's response is routed back to the master currently accessing it. So multi-master adds master-to-slave and slave-to-master routing (a crossbar in the matrix). So in hardware, routing/muxing scales with masters × slaves.

The master-identity tracking is the third: with multiple masters, the interconnect must know which master issued each outstanding transfer, to route the response correctly and maintain per-master ordering. On a shared bus, full AHB carries HMASTER (chapter 10.3) to identify the active master. In a matrix, the port a transfer arrived on identifies the master (each master has a dedicated port), so the response routes back to that port. So multi-master tracks master identity (via HMASTER or port). So in hardware, supporting multiple masters adds arbiters, routing/muxing (a crossbar in the matrix), and identity tracking — the machinery that turns the single-master decode-and-return into a full multi-master fabric. The matrix (detailed in the rest of the module) is the high-parallelism realization, using per-slave arbiters and a crossbar of per-master paths.

5. System Architecture Perspective

At the system level, multiple masters are how a system achieves concurrency and offload — and the choice of interconnect (shared bus vs matrix) directly determines how much parallelism the masters can actually realize, making it a key performance decision.

The concurrency and offload value: multiple masters let a system do several things at once. The classic case is DMA offload: while the CPU computes, the DMA concurrently moves data (filling a buffer from a peripheral, say) — so I/O and computation overlap, raising throughput and freeing the CPU. Multi-core systems run parallel threads, each a master. Debug access happens alongside normal execution. So multiple masters are the mechanism for system-level concurrency — without them, everything funnels through one initiator (the CPU), serializing all activity. So at the system level, multiple masters enable the concurrency that makes systems efficient. This is why systems add masters (DMA, cores) despite the interconnect complexity.

The interconnect determines realized parallelism: having multiple masters is necessary but not sufficient for concurrency — the interconnect must allow them to proceed in parallel. A shared bus serializes them: even with a CPU and DMA, only one uses the bus at a time, so the concurrency is limited (the DMA's transfers and the CPU's transfers can't overlap on the bus). A bus matrix enables concurrency: the CPU and DMA can access different slaves simultaneously, so their activity truly overlaps. So the interconnect choice gates how much of the masters' potential concurrency is realized. So at the system level, the shared-bus-vs-matrix decision is a performance decision — it determines whether multiple masters yield real parallelism or just take turns. So a system that adds a DMA for offload but puts it on a shared bus may not get the expected speedup (the DMA and CPU serialize); a matrix unlocks the overlap.

The scaling and right-sizing view connects to the family ladder (chapter 12.5/12.7): the interconnect should match the masters' concurrency needs. Few masters, low concurrency → a shared bus may suffice (cheap). Few masters needing real overlap (CPU + DMA) → a bus matrix (concurrency at moderate cost). Many masters, high concurrency → AXI (built for many outstanding, concurrent transactions). So the multi-master interconnect is right-sized to the system's concurrency demands. So at the system level, multiple masters provide concurrency and offload (the why), the interconnect determines how much of that concurrency is realized (shared bus serializes, matrix parallelizes — the performance lever), and the choice is right-sized to the concurrency need (shared bus → matrix → AXI). The bus matrix — the focus of this module — is the AHB-level answer for systems needing genuine multi-master parallelism, and understanding the multi-master problem is the foundation for understanding why the matrix is structured as it is. So multiple masters are the reason the interconnect exists and the driver of its design.

6. Engineering Tradeoffs

Multiple masters embody the concurrency-vs-cost interconnect design.

Multiple masters vs single master. Multiple masters enable concurrency/offload (DMA, multi-core) at the cost of arbitration + routing complexity. A single master (AHB-Lite) is simplest but serializes all activity through one initiator. Add masters when the system needs concurrent initiators.
Shared bus vs bus matrix. A shared bus is simple/cheap but serializes masters (limited concurrency); a matrix gives concurrent access to different slaves (more bandwidth) at higher cost (per-slave arbiters, a crossbar). Match to needed parallelism.
Concurrency potential vs realized concurrency. Adding masters provides potential concurrency; only an interconnect that allows parallel access (a matrix) realizes it. A shared bus wastes the potential (masters serialize). So the interconnect, not just the master count, sets the achievable parallelism.
Identity via HMASTER vs via port. A shared bus identifies the active master with HMASTER; a matrix uses the dedicated port a transfer arrived on. Both route responses correctly; the matrix's per-port identity also enables concurrency.

The throughline: multiple masters (CPU, DMA, debug, cores) share the interconnect and its slaves, turning the bus into a routing-and-arbitration problem — the interconnect must arbitrate (which master accesses a slave), route (master ↔ addressed slave, response back to the initiator), and track master identity. Two solutions trade cost for parallelism: a shared bus + arbiter (serialized, cheap) or a bus matrix (per-slave arbitration, concurrent, more bandwidth). Multiple masters enable system concurrency/offload, but the interconnect choice determines how much of that concurrency is realized — making it a key performance decision. The bus matrix is the high-parallelism AHB answer this module develops.

Adding masters gives concurrency *potential*; only a matrix *realizes* it — a shared bus serializes masters even to different slaves

A performance subtlety that trips up system designers: adding a second master (e.g. a DMA) gives the potential for concurrency, but whether that concurrency is actually realized depends on the interconnect — a shared bus serializes the masters even when they target different slaves, so the expected overlap may not happen. The reasoning: you add a DMA so it can move data while the CPU computes — expecting the DMA's bus traffic and the CPU's bus traffic to overlap. But on a shared bus, the CPU and DMA contend for the one bus: the arbiter grants one at a time, so even if the CPU wants SRAM and the DMA wants a peripheral (different slaves), they can't both use the bus simultaneously — one waits. So the DMA's transfers serialize with the CPU's, and the hoped-for overlap is limited (you get offload of the work, but the bus accesses still take turns). To realize the concurrency — CPU and DMA accessing different slaves at the same time — you need a bus matrix: each master has its own path, arbitration is per slave, so accesses to different slaves proceed in parallel (they only contend when targeting the same slave). So the lesson: master count alone doesn't give concurrency; the interconnect does. When adding masters for performance, check that the interconnect (a matrix, not a shared bus) actually allows the parallel access you're counting on. A common real-world disappointment is adding a DMA on a shared bus and seeing less speedup than expected because the bus serializes it with the CPU. The matrix is what turns multi-master potential into multi-master performance.

7. Industry Example

Trace multiple masters in a system with offload.

A system has a CPU, a DMA engine, and a debug access port, sharing SRAM, flash, and peripherals.

CPU executing. The CPU fetches instructions from flash and accesses data in SRAM — it's a master issuing transfers continuously.
DMA offload. A peripheral (say an ADC) needs its samples moved to SRAM. The DMA engine — a second master — is configured to do this. It issues its own transfers (read the ADC, write SRAM), independently of the CPU. The point of the DMA is to do this while the CPU keeps computing.
On a shared bus (serialized). If the system uses a shared bus, the CPU and DMA contend for it. The arbiter grants one at a time. So when the DMA is moving data, the CPU's bus accesses wait (and vice versa) — even though the DMA wants the ADC/SRAM and the CPU wants flash. The offload helps (the CPU isn't doing the copy), but the bus accesses serialize, limiting the overlap.
On a bus matrix (concurrent). If the system uses a bus matrix, the CPU can access flash while the DMA accesses the ADC and SRAM — simultaneously, because they're different slaves on different matrix paths. They contend only if both target the same slave (e.g. both want SRAM), arbitrated per-slave. So the matrix realizes the concurrency: CPU computation and DMA data movement truly overlap.
Debug access. The debug port (a third master) can read memory for debugging — on a matrix, even concurrently with CPU/DMA activity (to different slaves). Each master's transfers route correctly, and each response returns to its initiator.
Response routing. Throughout, the interconnect routes each slave's response back to the master that issued the access — by HMASTER (shared bus) or by the originating port (matrix) — so the CPU gets its data, the DMA gets its, the debug port gets its.

The example shows the multi-master reality: several initiators (CPU, DMA, debug) sharing slaves, with the interconnect arbitrating and routing. And it shows the key performance point — the matrix realizes the concurrency (CPU and DMA overlapping on different slaves) that a shared bus would serialize. This is why systems needing genuine offload/parallelism use a bus matrix.

8. Common Mistakes

Multiple-masters misconceptions

"Adding a master automatically gives concurrency." No — it gives the potential; a shared bus serializes masters (only a matrix realizes concurrent access to different slaves).
"Multiple masters just need an arbiter." An arbiter (shared bus) is one solution, but it serializes them. A matrix adds per-slave arbitration and routing for concurrency.
"The interconnect doesn't need to know which master issued a transfer." It does — to route the response back to the initiator (via HMASTER or the originating port) and maintain ordering.
"Masters always contend." They contend only when targeting the same slave (in a matrix). Accesses to different slaves can proceed concurrently in a matrix.
"A shared bus and a matrix give the same performance with multiple masters." No — the shared bus serializes (one bus), the matrix parallelizes (per-slave). The interconnect determines realized concurrency.
"Multiple masters is just Module 10 arbitration." Module 10 covered shared-bus arbitration; multi-master interconnect adds the matrix (routing + per-slave arbitration for concurrency), which this module develops.

9. Interview Insight

Multiple masters is a foundational interconnect interview topic — the routing-and-arbitration framing and the shared-bus-vs-matrix concurrency distinction are the signals.

Figure 4 — a strong answer in one card: the interconnect coordinates shared access — which master reaches which slave, and route the response back; a shared bus serializes masters via an arbiter, a bus matrix arbitrates per slave for concurrent access; each master has a unique identity for routing/ordering. The senior point: multiple masters = a routing + arbitration problem, solved by an arbiter (shared bus) or per-slave arbitration (matrix).

The answer that lands frames it as routing + arbitration with the concurrency distinction: "When multiple masters — a CPU, a DMA, a debug port, maybe more cores — share the interconnect and its slaves, the interconnect has to coordinate them. For every transfer, it must arbitrate — decide which master accesses a given slave when more than one wants it — and route: connect the master to the addressed slave, and route the response back to the master that issued it, which means tracking master identity. There are two structural solutions. A shared bus puts all masters on one bus with one arbiter; only one master uses the bus at a time, so access is serialized — simple and cheap, but the masters can't overlap even if they want different slaves. A bus matrix gives each master its own path into a switch that arbitrates per slave, so two masters can access two different slaves simultaneously — concurrent, higher bandwidth, at more hardware cost. The key insight is that adding masters only gives the potential for concurrency; the interconnect determines whether it's realized. A shared bus serializes them; a matrix parallelizes access to different slaves. So if you add a DMA for offload, you need a matrix to actually overlap its traffic with the CPU's." The routing-and-arbitration framing, the two solutions, and the concurrency-realization point are the senior signals.

🔍 The discriminator: multiple masters give concurrency *potential*; the interconnect (shared bus vs matrix) decides if it's *realized*

The discriminator on multiple masters is whether you separate the potential for concurrency (from having multiple masters) from the realization of it (from the interconnect) — and frame the problem as routing + arbitration. A weak answer says "multiple masters need an arbiter." A solid answer adds the two requirements (arbitrate which master accesses a slave; route the response back to the initiator by identity) and the two solutions (shared bus serializes via an arbiter; matrix arbitrates per slave). But the senior answer makes the performance distinction sharp: having multiple masters provides only the potential for concurrency — whether that concurrency is realized depends entirely on the interconnect. A shared bus serializes the masters (one bus, one at a time) even when they target different slaves, so the potential overlap is wasted. A bus matrix gives each master its own path and arbitrates per slave, so accesses to different slaves proceed in parallel (contending only on the same slave) — realizing the concurrency. The senior insight is the practical consequence: adding a DMA for offload on a shared bus may disappoint (the DMA serializes with the CPU on the bus); a matrix is what makes the overlap real. The flourish is the routing detail — the interconnect tracks master identity (HMASTER on a shared bus, or the originating port in a matrix) to return each response to its initiator and maintain per-master ordering. A candidate who frames multiple masters as routing + arbitration, and crucially distinguishes concurrency potential (masters) from concurrency realized (matrix vs shared bus), demonstrates they understand interconnect performance, not just "you need an arbiter."

10. Practice Challenge

Reason from multiple masters.

The problem. Describe what the interconnect must do when multiple masters share slaves (arbitrate, route, identity).
Why multiple masters. Give reasons systems have more than one master (offload, multi-core, debug).
Read the waveform. From Figure 2, explain how the shared bus serializes the CPU and DMA.
Potential vs realized. Explain why adding a master gives only the potential for concurrency, and what realizes it.
Response routing. Explain how the interconnect returns each response to the right master (HMASTER vs port).

11. Key Takeaways

Multiple masters (CPU, DMA, debug, cores) share the interconnect and its slaves — turning the bus into a routing-and-arbitration problem.
The interconnect must arbitrate (which master accesses a slave), route (master ↔ addressed slave, response back to the initiator), and track master identity (HMASTER on a shared bus, or the originating port in a matrix).
Two structural solutions: a shared bus + arbiter (masters serialized, one at a time — simple/cheap) or a bus matrix (per-slave arbitration, masters reach different slaves concurrently — more parallelism/bandwidth, more hardware).
Multiple masters enable concurrency/offload (DMA moving data while the CPU computes, multi-core parallelism) — the system-level why.
Adding masters gives concurrency potential; the interconnect realizes it — a shared bus serializes masters (even to different slaves); only a matrix parallelizes access to different slaves. This is a key performance lever.
Right-size the interconnect to the concurrency need — shared bus → bus matrix → AXI — matching realized parallelism to the system's demands.

12. What Comes Next

You now understand the multi-master problem — the routing-and-arbitration challenge and the shared-bus-vs-matrix solutions. The next chapters build out the fabric:

Multiple Slaves (next) — how many slaves attach and are selected (decoding and response routing at scale).
The Bus Matrix Concept — the multi-layer bus matrix and its parallelism, in detail.
Parallel Slave Access, Decoder + Arbiter Combination, Interconnect Routing, HREADY Aggregation, Bus Matrix Performance — the matrix mechanics and performance.

To revisit the arbitration this builds on, see Why Arbitration Exists and HBUSREQ & HGRANT; for the single-master contrast, see Why AHB-Lite Exists.