Master, Slave, Decoder & Arbiter

The previous chapter gave you the whole AHB architecture at a glance. This one zooms into the four components — manager, subordinate, decoder, arbiter — and asks, for each, what does it drive, what does it observe, and what is its one job? We will name the signal groups that connect them (address and control, data, response, selection, request and grant) without yet drilling into the bit-level encodings — that is Module 3's work. Think of this chapter as learning the cast's individual responsibilities and the wires between them, so that when the phase chapters animate a transfer, you already know who is holding which signal and why.

1. What Is It?

Each AHB component has a crisp definition in terms of what it drives and what it watches:

• A manager (master) drives the address, the control information (direction, transfer type, size, burst), and write data; it observes the ready signal (am I being made to wait?), the response (did it succeed?), and read data.
• A subordinate (slave) observes the address, control, write data, and its own select; it drives read data and the response, and it signals ready or not-ready to stall the manager.
• The decoder observes the address and drives a one-hot select that tells each subordinate whether this access is for it.
• The arbiter observes the managers' bus requests and drives the grant that names which single manager owns the bus.

The discipline worth building here is to describe each component by its interface direction: who drives, who observes. Bus correctness is almost entirely a matter of "exactly one thing drives each signal at each moment," and you cannot reason about that without knowing each component's driving role. Get the directions straight and the protocol's rules will later read as obvious constraints on who is allowed to drive what, when.

2. Why Does It Exist?

Each component exists because a shared, addressed, pipelined bus has four distinct responsibilities that must live somewhere, and clean design puts each in its own block.

• A bus is pointless without something that wants a transfer and is willing to drive it — that is the manager. It exists to be the source of intent and the driver of the request.
• A transfer is pointless without something that holds the thing being accessed and can respond — that is the subordinate. It exists to own an address region and answer for it, including the power to say "wait" when it is not ready.
• Because one bus reaches many subordinates, something must decide which one this access is for — that is the decoder. It exists to convert the abstract address map into a concrete, per-access selection.
• Because many managers share one bus, something must decide who drives it — that is the arbiter. It exists to guarantee that exactly one manager drives at a time, which is the precondition for the bus working at all.

The reason these are separate blocks, rather than one tangled controller, is the usual engineering virtue: separation of concerns. The arbiter knows nothing about addresses; the decoder knows nothing about priority; a subordinate knows nothing about which manager it is serving. Each does one job, which keeps each small, independently verifiable, and reusable. A subordinate designed once can be dropped into any AHB system because it only cares about its own select and the access on the bus — not about the arbiter's policy or how many managers exist. That modularity is why AHB components compose into an ecosystem.

3. Mental Model

Model the four as a service desk with a queue manager, a receptionist's directory, and the staff.

• The managers are visitors with errands — they want something done and will wait if told to.
• The arbiter is the queue manager at the door: when several visitors arrive, it lets exactly one approach the desk. Its only concern is who goes next, by whatever policy the building sets.
• The decoder is the directory that reads the visitor's request slip and lights up which office should handle it. Its only concern is which office, based on the address on the slip.
• The subordinates are the offices. The lit-up office handles the request and can say "please wait" if it needs time, while the others, not lit, ignore the request entirely.

This model makes two things vivid. First, the separation: the queue manager (arbiter) and the directory (decoder) are completely independent — one picks the visitor, the other picks the office, and they never need to know each other's logic. Second, the stall power of the subordinate: the office can hold the visitor with "please wait," and because the visitor is at the one desk, everyone behind waits too — the stall rule from the mental-model chapter, now located precisely in the subordinate's ability to withhold ready.

4. Real Hardware Perspective

Each component maps to recognizable logic, and seeing the mapping makes the "drives vs observes" discipline concrete.

A manager is, in hardware, a block with an AHB manager interface: outputs for address, control, and write data, and inputs for ready, response, and read data. Its defining behavioural rule — which you will meet at signal level next chapter — is that once it presents an access it must hold its address and control stable while the subordinate stalls it. In hardware terms, the manager registers its outputs and does not change them until it sees ready, because the subordinate is sampling those outputs and would be corrupted if they changed mid-access.

A subordinate is a block with an AHB subordinate interface: inputs for address, control, write data, and its select; outputs for read data, response, and ready. Its defining power is the ready output: by holding ready low it inserts wait states, stretching the access until it can complete. This is the hardware seat of the "slow slave stalls the bus" rule — the stall is literally a subordinate holding one wire low.

The decoder is combinational logic from address to a one-hot select, and it also typically drives the control of the read-data multiplexor, so the same selection that tells subordinate B "you're it" also tells the mux "route B's read data back."

The arbiter is sequential logic that samples request lines and asserts a grant according to its policy. Crucially, it is also where bus ownership handoff is managed so that one manager's drive cleanly gives way to the next without two driving at once. All four blocks are small relative to the managers and subordinates — the intelligence of an AHB system lives in its endpoints, not in this control logic.

5. System Architecture Perspective

At the system level, the division of labour among these four components is what makes an AHB subsystem composable and configurable — you can change one component's behaviour without rewriting the others.

The arbiter is the system's policy knob. Because all bus ownership decisions live in this one block, an architect tunes fairness and priority there and nowhere else — give the processor higher priority for latency, or round-robin the DMA engines for fairness, by changing the arbiter alone. The managers and subordinates are unaffected. This is why arbitration policy is a system-level decision: it is concentrated in one tunable place by design.

The decoder is the system's address map. Because all "which subordinate" decisions live here, the chip's memory map is realized by this one block's configuration. Re-mapping a peripheral, adding a memory, or carving out a new region is a decoder change — the subordinates themselves do not care where they are mapped, only whether their select is asserted. This separation is what lets the same subordinate IP be reused at different addresses across chips.

The subordinates define the system's capabilities (what memory and peripherals exist) and the managers define its demands (who needs the bus and how often). The system-level sizing question from earlier modules — does the shared bus suffice? — is now precisely "how many managers contend at the arbiter, and how often do subordinates stall with ready?" Both are now located in specific components, so the abstract contention discussion becomes concrete: look at the arbiter's request load and the subordinates' wait-state behaviour. The components are not just architecture; they are the places you measure and tune the system.

6. Engineering Tradeoffs

Most of the interesting tradeoffs in this chapter live in the arbiter and the subordinate, because those are where policy and timing are decided.

• Arbiter policy: priority vs fairness. Fixed priority gives a chosen manager (say the latency-sensitive processor) low, predictable latency, but can starve lower-priority managers under load. Round-robin is fair — everyone eventually goes — but guarantees no single manager low latency. Real arbiters blend them (priority with anti-starvation, or weighted round-robin). The tradeoff is latency-for-one versus fairness-for-all, and it is set in the arbiter alone.
• Burst length vs arbitration latency. Letting a granted manager run a long burst is efficient (the bus stays productively busy), but while it runs, other managers wait longer for the bus. The arbiter's handling of bursts trades throughput against worst-case access latency for the others.
• Subordinate wait states: simplicity vs stalling everyone. A subordinate that needs time inserts wait states by holding ready low. This is the simplest correct way to handle a slow device, but every wait state stalls the whole shared bus. The tradeoff is implementation simplicity versus system-wide impact — and it is exactly why genuinely slow devices are bridged to APB rather than left to stall the AHB.
• Decoder granularity: fine maps vs decoder size. A finely partitioned address map gives clean separation and protection between many subordinates but grows the decoder; a coarse map keeps the decoder tiny but lumps things together. The tradeoff is address-map precision versus decode logic size.

The pattern across these: the arbiter and the subordinate are where AHB's behaviour is shaped. The decoder and the manager are comparatively mechanical (route by address; drive and hold), while policy (arbiter) and timing (subordinate ready) are the levers an architect actually pulls. Knowing which component owns which lever is what lets you tune a system instead of guessing.

7. Industry Example

Put the four components to work in a subsystem with two managers contending and a slow subordinate stalling.

A microcontroller has a processor and a DMA engine (managers), an SRAM and a flash controller (subordinates), plus the arbiter and decoder. The DMA is streaming from SRAM while the processor periodically fetches from flash.

• The arbiter sees both managers request the bus. Suppose policy gives the processor priority for its latency-sensitive fetches but uses anti-starvation so the DMA still makes steady progress. Each access, the arbiter grants one manager and the other waits — bus ownership is decided here, by this policy.
• When the processor is granted and fetches from flash, the decoder reads the address, recognizes the flash region, and asserts flash's select; SRAM sees it is not selected and ignores the access. The same selection steers the multiplexor to route flash's read data back.
• Flash is slow, so the flash subordinate holds ready low for a few cycles — wait states. During those cycles, the processor (the manager) holds its address and control stable, and the DMA, waiting for the bus, is delayed too. One subordinate's ready wire is pacing the whole subsystem.
• Once flash asserts ready with a good response, the access completes, the multiplexor's routed read data reaches the processor, and the arbiter can grant the bus to the DMA next.

Every behaviour here is attributable to a specific component: contention to the arbiter's policy, routing to the decoder/mux, the stall to the flash subordinate's ready, and the steady drive-and-hold to the manager. When you later debug such a subsystem on a waveform, this attribution is exactly how you localize a problem — "is this the arbiter's policy, or a subordinate stalling, or a manager misbehaving?" The components give you the suspects.

8. Common Mistakes

9. Interview Insight

Interviewers probe the components to check that you understand responsibilities and signal directions, not just names.

The answer that signals depth attaches each component to what it drives and the one rule that defines it: "The arbiter grants the bus to one manager — that's contention policy. The decoder selects the subordinate by address — that's the address map. The manager drives address, control, and write data and must hold them stable while stalled. The subordinate responds and can insert wait states by holding ready low — that's how a slow device stalls the whole bus." Volunteering the drive-and-hold rule and the ready stall mechanism shows you think in signal directions, which is exactly the debugging frame interviewers want.

10. Practice Challenge

Describe everything in terms of drives, observes, and the one rule per component.

1. Direction table. For each of the four components, list what it drives and what it observes. Check against Figure 1.
2. Two decisions. Explain, in two sentences, the difference between what the arbiter decides and what the decoder decides, and why conflating them is wrong.
3. Trace a stall. A subordinate holds ready low for three cycles. Describe what the manager must do during those cycles and what happens to a second manager waiting for the bus.
4. Tune the policy. Given a processor plus two DMA engines, propose an arbiter policy that protects processor latency without starving the DMAs, and state the tradeoff.
5. Locate the bug. A low-priority master makes no progress for long stretches. Name the most likely component at fault and the class of fix.

11. Key Takeaways

• Describe each component by what it drives and observes. Manager: drives address/control/write-data, observes ready/response/read-data. Subordinate: observes the access and its select, drives read-data/response, signals ready. Decoder: address in, select out. Arbiter: requests in, grant out.
• Two different decisions: the arbiter picks the manager (bus ownership), the decoder picks the subordinate (by address). Never conflate them.
• The subordinate's ready is the stall mechanism — one wire that, held low, inserts wait states and stalls the whole shared bus. It is the hardware seat of "a slow slave stalls everyone."
• The manager must hold address and control stable while stalled, because the subordinate is sampling them and the access has not completed.
• The arbiter is the policy knob (latency vs fairness, with anti-starvation needed) and the decoder is the address map — each concentrates one system decision in one tunable block.
• Components are composable because each does one job and need not know the others' internals — which is why AHB IP reuses across chips.

12. What Comes Next

You now know each component's job and signal directions. The module now animates a transfer at signal level, starting with what the manager drives first:

• 2.3 — The Address / Control Phase (coming soon) — the signals the manager drives in the address phase, why they precede data, and how the subordinate uses them.
• 2.4 — The Data Phase (coming soon) — how read and write data move, gated by ready.

To revisit the structure these components sit in, see AHB Bus Architecture. For the vocabulary and model behind them, see Manager / Subordinate Terminology and The AHB Mental Model. For the broader protocol map, see the AMBA family overview.