Parallel Slave Access

Chapter 13.3 introduced the matrix and its per-slave arbitration; this chapter zooms in on the payoff: parallel slave access — the matrix letting masters reach different slaves at the same time. The mechanism is physically independent paths: the CPU's layer routes to one slave port while the DMA's layer routes to another, and because those paths don't share any resource, the two transfers run fully in parallel — each path carries its own address phase, data phase, and response, end to end, simultaneously. The result is throughput multiplication: up to N transfers per cycle when N slaves are being accessed by different masters, versus one on a shared bus. This is the concrete realization of the matrix's bandwidth advantage. The essential caveat (from 13.3) carries through: the parallelism holds only for accesses to different slaves — masters targeting the same slave still serialize at that slave's arbiter. This chapter details how the parallel paths work, the bandwidth gain, and where the parallelism applies (and doesn't).

1. What Is It?

Parallel slave access is the matrix's ability to carry multiple transfers simultaneously — one per slave being accessed — because each master-to-slave path is independent. The mechanism:

• Independent paths — each master's layer routes to its target slave through a path that shares no resource with other (different-slave) paths.
• End-to-end concurrency — each path carries its full transfer (address phase, data phase, response) at the same time as the others.
• Throughput multiplication — N concurrent transfers (N different slaves accessed) → up to N× the bandwidth of a single shared bus.

So parallel slave access is the matrix's defining benefit made concrete: not just "masters can both eventually use the bus," but "masters' transfers to different slaves happen at the same time, with no serialization between them." Each transfer proceeds on its own path as if it had the bus to itself — because, for that slave, it does. So the matrix behaves like N independent buses (one per slave), each carrying a transfer concurrently. This is why the matrix has higher bandwidth: it's not faster per-transfer, it carries more transfers at once. So parallel slave access is the simultaneous, independent flow of transfers to different slaves — the matrix's bandwidth in action.

2. Why Does It Exist?

Parallel slave access exists because slaves are independent resources — accessing one doesn't conflict with accessing another — and the matrix's independent paths expose that independence, letting transfers to different slaves proceed without serializing on a shared resource.

The slaves are independent is the physical truth the matrix exploits: SRAM, flash, and a peripheral are separate pieces of hardware. Reading SRAM and reading flash are independent operations — they don't conflict (different memories, different ports). So in principle, they could happen at the same time. The only thing that prevented it on a shared bus was the shared bus itself (one bus, one transfer at a time). So the potential for parallelism was always there (independent slaves) — it was the shared bus that serialized it. So parallel slave access exists because the slaves are genuinely independent, and something just needs to not serialize their access.

The independent paths expose the parallelism: the matrix provides a separate path from each master to each slave (chapter 13.3). So when the CPU accesses SRAM and the DMA accesses flash, they use different paths to different slave ports — sharing no resource (no shared bus, no shared arbiter, since arbitration is per-slave). With no shared resource, there's nothing to serialize them — they proceed concurrently. So the matrix's independent paths remove the artificial serialization the shared bus imposed, letting the slaves' natural independence manifest as concurrent access. So parallel slave access exists because the matrix's independent paths expose the slaves' inherent independence. So the matrix unlocks parallelism that was always physically possible.

The reason this matters (the why-we-want-it) is bandwidth: a system with multiple active masters (CPU computing, DMA moving data, an accelerator working) generates multiple concurrent streams of bus traffic. If those streams target different slaves (as they often do — CPU on flash, DMA on a peripheral, accelerator on SRAM), parallel slave access lets them all flow at once, delivering the aggregate bandwidth the system needs. Without it (shared bus), the streams serialize, and the bus becomes the bottleneck — the system can't use its masters' full concurrency. So parallel slave access exists because real multi-master systems need aggregate bandwidth across concurrent streams, which only parallel access to independent slaves provides. So parallel slave access exists because slaves are inherently independent (the potential), the matrix's independent paths expose that independence (the mechanism), and multi-master systems need the resulting aggregate bandwidth (the motivation). It's the matrix delivering on its promise — and its benefit is proportional to how well the traffic spreads across slaves (the more different slaves accessed concurrently, the more parallelism), which is why a hot slave (all masters on one) negates it (chapter 13.3).

3. Mental Model

Model parallel slave access as a bank with multiple teller windows versus a single window — with one window (a shared bus), customers wanting different services (deposit, withdrawal, currency exchange) still queue at the one window and are served one at a time; with multiple windows (parallel paths to different slaves), a customer depositing at window 1 and a customer exchanging currency at window 2 are served simultaneously, because the windows are independent — only two customers wanting the same specific window (the same slave) have to queue.

A bank starts with a single teller window (a shared bus): every customer (master), no matter what service (which slave) they want, queues at the one window and is served one at a time. Even if one wants a simple deposit and another wants currency exchange — independent services — they still wait in the single line. The window is the bottleneck. Now the bank opens multiple windows (parallel paths to different slaves): now a customer doing a deposit at window 1 and a customer doing a currency exchange at window 2 are served at the same time — the windows operate independently, so independent services proceed concurrently. The bank serves more customers per hour (more bandwidth). The only time customers must queue is when two of them want the same specific window (the same slave) — then that window's line (the per-slave arbiter) sequences them. So the multi-window upgrade lets independent services run in parallel, bottlenecking only on a specific contended window. The throughput gain is proportional to how spread out the customers' needs are across the windows — if everyone wants the one currency-exchange window, the extra windows don't help (a hot slave).

This captures parallel slave access: the single window = the shared bus; multiple windows = the matrix's independent paths; different services at different windows simultaneously = different-slave transfers running concurrently; more customers per hour = higher bandwidth; queuing only at the same specific window = same-slave serialization at that slave's arbiter; everyone wanting one window = a hot slave negating the gain. Independent windows serve independent customers in parallel — that's parallel slave access.

Watch two transfers run concurrently on different slaves:

The model's lesson: independent windows serve independent customers in parallel. In the waveform, the CPU→SRAM and DMA→flash transfers run fully concurrently — two transfers in the time of one.

4. Real Hardware Perspective

In hardware, parallel slave access means each slave port has its own set of AHB signals driven by whichever master is granted it, and these per-slave-port transfers proceed independently — so the matrix is effectively replicated transfer logic per slave port, all running at once.

The per-slave-port transfer logic: each slave port in the matrix has a complete AHB interface — address/control inputs (muxed from the granted master), write data in, and read-data/HREADY/HRESP out. So each slave port is, in effect, a full AHB slave interface, driven by the master currently accessing it. Because each slave port has its own such interface, each can be running a transfer independently — slave port 0 (SRAM) runs the CPU's transfer while slave port 1 (flash) runs the DMA's, with no shared signals between them. So in hardware, parallel access is independent per-slave-port transfer logic, all active simultaneously. So the matrix replicates the transfer interface per slave.

The master-side independence: each master's layer drives its own transfer — its address/control go to whichever slave port it's accessing, and it receives that slave's response back. Because the masters drive different slave ports, their transfers don't interfere. Each master experiences the bus as if it owns it (for the slave it's accessing) — full pipeline, wait states, etc. — concurrently with the other masters. So in hardware, each master runs an independent transfer on its layer. So masters and slaves both see independent, concurrent transfers.

The bandwidth realization: the aggregate bandwidth is the sum of the concurrent paths' bandwidths — N slave ports each carrying a transfer = N× a single bus's throughput (in the ideal, fully-spread case). In practice it's less than N× (not all slaves are always busy, and same-slave contention serializes), but the matrix can approach N× when traffic spreads well. So the hardware delivers aggregate bandwidth proportional to the number of concurrently-busy slave ports. So in hardware, parallel slave access is replicated per-slave-port transfer logic (each a full AHB interface) and per-master layers, all running independently and concurrently — delivering aggregate bandwidth up to N× a shared bus, realized to the degree traffic spreads across slaves. The detailed routing (which master to which slave port) and arbitration (same-slave contention) are chapters 13.5–13.6.

5. System Architecture Perspective

At the system level, parallel slave access is the mechanism that makes a multi-master system's aggregate bandwidth real — and it's why memory/slave organization (spreading data across slaves) is a key performance-design decision.

The aggregate bandwidth realized: a multi-master system's potential bandwidth is the sum of its masters' demands (CPU + DMA + accelerator each wanting bandwidth). Parallel slave access is how that potential is realized — by letting the masters' streams flow concurrently to different slaves, the matrix delivers their combined bandwidth, not just one stream's. So the system actually gets the throughput its multiple masters demand. Without parallel access (shared bus), the masters' combined demand is throttled to one bus's bandwidth — a bottleneck. So at the system level, parallel slave access is what converts multi-master demand into delivered aggregate bandwidth. This is the performance payoff of the whole matrix.

The slave organization as a performance lever: since parallel access only helps for different-slave traffic, the organization of data across slaves directly determines how much parallelism is realized (chapter 13.3's hot-slave point). If the system's masters naturally access different slaves (CPU code in flash, DMA buffer in a dedicated SRAM, accelerator data in another), parallelism is high. If they contend for one slave (one shared memory), parallelism is low. So placing data to spread access across slaves — e.g. giving the DMA its own buffer memory, banking a shared memory into independently-accessed banks — is a performance-design decision that maximizes the matrix's benefit. So at the system level, parallel slave access makes slave/memory organization a first-class performance concern — the matrix provides the capability, but the data layout determines how much is used. This is why high-performance systems carefully partition memory across independently-accessible slaves/banks.

The scaling and limits view: parallel access scales bandwidth up to the number of slaves (N concurrent transfers), but real limits apply — the master count (you can't have more concurrent transfers than masters), the traffic spread (hot slaves serialize), and physical constraints (a single-ported memory can serve one access at a time regardless). So the matrix's bandwidth is bounded by min(masters, busy slaves) and reduced by contention. Beyond AHB matrix scale (very high concurrency, many outstanding transactions), AXI's deeper concurrency (multiple outstanding per master, out-of-order) extends further. So at the system level, parallel slave access realizes multi-master aggregate bandwidth (the payoff), makes slave/memory organization a key performance lever (spread data to maximize parallelism), and scales up to min(masters, slaves) concurrent transfers (bounded by traffic spread and physical ports). It's the concrete mechanism behind "the matrix gives more bandwidth," and designing for it (spreading access across slaves) is how systems extract that bandwidth. So parallel slave access is where the matrix's architecture meets the system's data layout to deliver performance.

6. Engineering Tradeoffs

Parallel slave access embodies the independent-paths, spread-for-bandwidth design.

• Parallel access (matrix) vs serial (shared bus). Parallel access delivers aggregate bandwidth (up to N× for N busy slaves) via independent paths, at the matrix's hardware cost. A shared bus serializes (one transfer at a time), cheaper but bandwidth-limited. Choose the matrix when aggregate bandwidth is needed.
• Spread data across slaves vs concentrate. Spreading masters' data across different slaves maximizes parallel access (high bandwidth) at the cost of more memory partitioning/management. Concentrating data in one slave is simpler but creates a hot slave (serialized, no parallelism). Spread for performance.
• More slave ports vs fewer. More slaves (ports) raise the ceiling on concurrent transfers (more parallelism potential) at more matrix cost; fewer slaves lower it. Match the slave count to the needed concurrency.
• Realized vs ideal bandwidth. Ideal is N× (all slaves busy, different masters); realized is less (idle slaves, same-slave contention, single-ported limits). The gap is closed by spreading traffic and banking hot memories.

The throughline: parallel slave access is the matrix carrying multiple transfers simultaneously — one per slave being accessed — because each master-to-slave path is physically independent, so each transfer runs end-to-end concurrently. It delivers aggregate bandwidth up to N× a shared bus (N busy slaves), realizing the matrix's promise. The gain is proportional to how well traffic spreads across slaves — different-slave access is concurrent, same-slave serializes — making slave/memory organization a key performance lever. It scales up to min(masters, slaves) concurrent transfers, bounded by contention and physical ports.

7. Industry Example

Trace parallel slave access delivering bandwidth.

A system has a CPU, a DMA, and a crypto accelerator, with code-flash, a CPU-data SRAM, a DMA-buffer SRAM, and a crypto SRAM — deliberately separate slaves.

• Three concurrent streams. The CPU fetches code from flash, the DMA moves data into the DMA-buffer SRAM, and the crypto accelerator reads/writes the crypto SRAM — all three at once, because they target different slaves. Three transfers in flight per cycle: ~3× a shared bus's bandwidth.
• Independent paths. Each stream flows on its own matrix path to its own slave port. The CPU's flash accesses don't touch the DMA's SRAM path or the crypto path. No serialization between them.
• Deliberate data layout. The separate slaves (CPU-data SRAM, DMA-buffer SRAM, crypto SRAM) are a design choice — the architect gave each master its own memory so their accesses spread across slaves, maximizing parallelism. This is co-design of the matrix with the memory map.
• A shared-slave moment. If the CPU needs to read the DMA's buffer (e.g. to process the DMA'd data), it accesses the DMA-buffer SRAM — now the CPU and DMA may contend for that slave, and its arbiter serializes them for that traffic (the crypto stream continues in parallel). So contention is localized to the shared slave; the rest stays parallel.
• Banking a hot memory. If a single memory were heavily shared (e.g. all masters using one large SRAM), the architect would bank it — split it into independently-arbitrated banks and interleave addresses — so the masters hit different banks, restoring parallelism.
• Realized bandwidth. The system achieves close to its aggregate demand because the data layout spreads access across slaves — the matrix's parallel access is actually used, not wasted on a hot slave.

The example shows parallel slave access delivering real bandwidth: three concurrent streams to three different slaves, enabled by a deliberate spread-across-slaves data layout — with contention localized to any shared slave and banking available for hot memories. This is how systems extract the matrix's parallel bandwidth.

8. Common Mistakes

9. Interview Insight

Parallel slave access is a performance-focused interview topic — the independent-paths mechanism, the throughput multiplication, and the spread-the-traffic design rule are the signals.

The answer that lands gives the mechanism and the design rule: "Parallel slave access is the matrix carrying multiple transfers at the same time — one per slave being accessed. The mechanism is independent paths: when the CPU accesses SRAM and the DMA accesses flash, they use different paths to different slave ports, sharing no resource, so both transfers run fully in parallel — each path carries its own address phase, data phase, and response, end to end, simultaneously. The matrix behaves like N independent buses, one per slave. So the throughput is up to N transfers per cycle for N busy slaves, versus one on a shared bus — the matrix's bandwidth multiplication. The crucial point is that this only applies to different-slave traffic: masters targeting the same slave still serialize at that slave's arbiter. So the bandwidth gain is proportional to how well the masters' accesses spread across slaves. That makes it a design rule: to actually get the matrix's bandwidth, you organize memory so concurrent masters hit different slaves — give the DMA its own buffer memory, bank a shared memory into independent banks. Just instantiating a matrix isn't enough; a hot shared slave gives you shared-bus performance despite the matrix." The independent-paths mechanism, the throughput multiplication, and the spread-the-traffic design rule are the senior signals.

10. Practice Challenge

Reason from parallel slave access.

1. The mechanism. Explain how independent paths let two transfers to different slaves run concurrently.
2. Throughput vs latency. Explain why the matrix multiplies throughput but not per-transfer speed.
3. Read the waveform. From Figure 2, identify the two concurrent transfers and their overlapping phases.
4. Spread the traffic. Explain why the bandwidth gain depends on data layout and how to maximize it.
5. Limits. State what bounds the number of concurrent transfers.

11. Key Takeaways

• Parallel slave access is the matrix carrying multiple transfers simultaneously — one per slave being accessed — because each master-to-slave path is physically independent.
• Each path runs its transfer end-to-end concurrently (address phase, data phase, response) — the matrix behaves like N independent buses, one per slave.
• Throughput multiplies up to N× (N busy slaves accessed by different masters) vs one transfer on a shared bus — the matrix's bandwidth in action. It's aggregate bandwidth (more transfers at once), not faster per-transfer.
• The gain is proportional to traffic spread — only different-slave access is concurrent; same-slave serializes at that slave's arbiter (a hot slave negates it).
• Data layout is the performance lever — organize memory/slaves so concurrent masters hit different slaves (give the DMA its own buffer, bank hot memories). Instantiating a matrix isn't enough.
• Concurrency is bounded by min(masters, busy slaves), reduced by contention and single-ported slaves; beyond the AHB matrix's reach, AXI extends concurrency.

12. What Comes Next

You now understand parallel slave access — the matrix's bandwidth delivered through independent paths. The next chapters detail the machinery that enables it:

• Decoder + Arbiter Combination (next) — how decoders and arbiters compose in the fabric to route and arbitrate.
• Interconnect Routing — how transfers route from master port to slave port.
• HREADY Aggregation, Bus Matrix Performance — response aggregation and the topology-to-bandwidth relationship.

To revisit the matrix structure this builds on, see The Bus Matrix Concept; for the hot-slave caveat, revisit its discussion there.