AMBA APB · Module 2

The Manager and Subordinate Model

APB roles — the manager that drives one transaction stream and the subordinates it selects — plus the legacy master/slave terms and why the bridge is the APB manager in a real SoC.

Before you can read an APB transfer cycle by cycle, you have to answer a question Module 1 quietly skipped: who starts a transfer, and who answers it? An APB access is not a conversation between equals. One side — the manager — initiates and drives the whole transaction stream; the other side — the subordinate — does nothing until it is selected, then responds. The single idea to carry out of this chapter: APB has exactly one active manager-side transaction stream, and in a real chip the bridge is the thing driving it. Fix the roles first; the lifecycle that follows only makes sense once you know which side moves and which side waits.

1. What problem is being solved?

The problem is assigning roles — naming, unambiguously, which block on the bus initiates an access and which block responds — so that every signal has exactly one driver and every transfer has exactly one origin.

A bus is a shared set of wires. If two blocks could both decide to drive PADDR or PSEL, the bus would be meaningless: contention on the wires and ambiguity about whose transfer is in progress. APB removes that ambiguity by splitting every participant into one of two fixed roles:

Manager — the block that initiates a transfer. It drives PSEL to pick a target, PADDR/PWRITE/PWDATA to describe the access, and PENABLE to mark the access phase. The transaction stream originates here.
Subordinate — a block that responds when, and only when, its PSEL is asserted. It drives PRDATA (read data) and PREADY (completion) back, and is otherwise silent.

The job of this chapter is to make those roles concrete: what the manager owns, what a subordinate owns, and why there is room for only one manager-side stream on the bus at a time.

2. Why the previous mental model is not enough

Module 1 taught you that a peripheral is a register map and that APB carries reads and writes to those registers. That is true — but it is written in the passive voice. It never says who does the reading and writing, or who the register lives inside.

"A register gets written" hides the two facts the rest of this module depends on. First, a write is something a specific block — the manager — actively drives onto the bus; it does not happen on its own. Second, the register sits inside a specific block — the subordinate — that is only paying attention when selected. Until you pin those two roles down, the lifecycle is unreadable, because every phase of it is defined by who drives what:

The lifecycle is the manager's walk, not the bus's. PSEL, PENABLE, address, and data are all driven by the manager through SETUP and ACCESS. The subordinate's only contribution is PREADY and PRDATA. You cannot say "the bus moves from SETUP to ACCESS" without knowing that the manager is the thing moving it.
Selection is the whole protocol's anchor. PSEL is the manager pointing at one subordinate and saying "this transfer is for you." A subordinate that is not selected drives nothing. Miss this and you will imagine multiple peripherals responding at once — which APB never allows.

3. APB transfer mental model

The model: APB is one operator at one control panel, and the bus is the single cable between them.

There is exactly one operator (the manager). The operator walks up to a wall of panels (the subordinates), points at one of them with PSEL, and performs an access on it — present the address and direction, drive the access, read the gauge or flip the switch. The other panels sit untouched; they are wired in, but their PSEL is low, so they ignore everything on the cable. There is no second operator working a different panel at the same time, and no panel reaches over to grab the cable. One operator, one selected panel, one access in flight.

Three refinements make the model precise:

The manager owns the request signals; the subordinate owns the response. Outbound from the manager: PSEL, PADDR, PWRITE, PWDATA, PENABLE. Inbound from the selected subordinate: PRDATA, PREADY. Every wire has exactly one driver, and which side that is never changes.
Exactly one subordinate is selected at a time. Each subordinate has its own PSEL. The address decode asserts exactly one of them per transfer, so exactly one block answers. The rest are electrically present but logically asleep.
One transaction stream, no concurrency on the bus. APB has no second manager contending for the wires and no arbitration on the APB bus itself — there is a single manager-side stream of transfers, one access finishing before the next begins. (Contrast AHB, which is multi-master and arbitrated.)

Figure 1 — the manager and subordinate roles, with every signal's direction made explicit. The single manager on the left drives the request signals rightward onto the bus: PSEL selects exactly one subordinate, while PADDR, PWRITE, PWDATA and PENABLE carry and qualify the access. The selected subordinate on the right drives PRDATA and PREADY leftward back to the manager. The other subordinates have PSEL low and stay silent. Because only one PSEL is asserted, exactly one subordinate answers and there is exactly one active transaction stream on the APB bus.

4. Real SoC / hardware context

In a real chip the manager is almost never the processor itself — it is the bridge. The CPU lives on a fast AHB or AXI backbone and issues a fast-bus access; the bridge catches that access and becomes the APB manager, converting one fast-bus transaction into the APB transaction stream to the selected peripheral.

This dual identity is the key insight. On its fast-bus side, the bridge is a subordinate — it answers the CPU's AHB or AXI access. On its APB side, the bridge is the manager — it drives PSEL, PADDR, PWRITE, PWDATA, and PENABLE to the chosen peripheral and samples PREADY/PRDATA coming back. The CPU never touches APB wires directly; it reaches every slow peripheral through the bridge. So the single manager-side stream on the APB bus always originates in the bridge.

This is also why the lifecycle (the transfer FSM you meet later) physically lives in the bridge: the bridge is the manager, so the bridge is the block that sequences PSEL and PENABLE along the legal path. Subordinates do not run the lifecycle — they only answer the part of it the manager presents to them.

Figure 2 — the bridge as the single APB manager. A fast-bus read or write request from the AHB or AXI backbone enters the bridge on the left. The bridge converts that one access into the APB transaction stream — driving PSEL, PADDR, PWRITE, PWDATA and PENABLE — to the selected subordinate on the right. The subordinate returns PRDATA and PREADY, which the bridge collects and forwards back up to the fast bus as the original access's read data and response. The CPU never drives APB directly; the bridge alone originates the APB stream, so there is exactly one manager-side stream on the bus.

5. Engineering tradeoff table

Fixing the roles this rigidly — one manager, passive subordinates, a single stream — is a deliberate choice. Each line trades capability APB does not need for simplicity it does.

Role decision	What it gives up	What it buys	Why it is correct for APB
Single manager-side stream	Multiple initiators on the APB bus	No arbiter on APB at all	Control traffic is sparse; one stream is plenty
Subordinates are passive	Peripheral-initiated transfers on APB	Trivial peripheral logic — decode, mux, ready	A register only ever needs to answer a poke
`PSEL` selects exactly one	Broadcast / multi-target access	One unambiguous responder per transfer	Every transfer targets one register in one block
Manager owns all request signals	Shared driving of address/data	One driver per wire — no contention logic	Removes bus-contention design and verification
Bridge is the manager	A peripheral talking APB to APB	One conversion point from the fast world	The slow world only ever needs to be reached

The throughline: APB pushes all the initiative onto one block (the bridge-as-manager) and keeps every subordinate dumb and reactive. That asymmetry is what lets a peripheral's APB interface shrink to almost nothing — the same minimalism the whole bus is built for.

6. Common RTL / architecture / waveform mistakes

Misconceptions to unlearn

"The CPU is the APB manager." Usually no. The CPU initiates on the fast bus; the bridge converts that into the APB transaction stream and is the actual APB manager. The CPU never drives APB wires directly.
"A subordinate can start a transfer." No. Subordinates are purely reactive — they drive PRDATA and PREADY only after the manager selects them with PSEL. There is no peripheral-initiated APB transfer.
"Several subordinates respond to one transfer." No. Exactly one PSEL is asserted per transfer, so exactly one subordinate answers. The rest are silent regardless of what is on PADDR.
"APB is multi-master, so it needs an arbiter." No. The APB bus carries one manager-side stream and has no arbitration on it. Any arbitration that exists belongs to the fast bus above the bridge, not to APB.
"Master/slave and manager/subordinate are different protocols." No. They are the same two roles under old and new AMBA terminology. Signal directions and behaviour are identical.
"A subordinate drives the bus whenever it has data." No. A subordinate may only drive PRDATA/PREADY while selected. Driving when PSEL is low would corrupt another transfer.

7. Interview framing

This is the question that checks whether you think about a bus as roles and direction or just as a bag of signal names. Interviewers ask "who drives PSEL?" or "in an SoC, what is the APB manager?" precisely because the wrong answer (the CPU, or "the peripheral") reveals a missing model.

The strong answer states the asymmetry first: the manager initiates and drives the whole request side — PSEL, PADDR, PWRITE, PWDATA, PENABLE — and the subordinate only responds, with PRDATA and PREADY, when its PSEL is asserted. Then deliver the two depth points: in a real chip the bridge is the APB manager (it turns a fast-bus access into the APB stream, so the CPU never drives APB directly), and there is exactly one manager-side transaction stream with no concurrency on the APB bus (any arbitration lives above the bridge). Mention that master/slave is the legacy name for manager/subordinate. What the interviewer is really probing is whether you can name who moves and who waits — because everything in the lifecycle is defined by that split.

8. Q&A

9. Practice

Label the directions. From memory, list every APB signal and mark whether the manager or the subordinate drives it. Confirm each wire has exactly one driver.
Trace the bridge. Describe one CPU register write as it crosses the bridge: what role the bridge plays on the fast-bus side, what role it plays on the APB side, and which signals it drives onto APB.
Spot the impossible. A teammate's diagram shows two peripherals driving PRDATA at the same time. Using PSEL, explain why that cannot happen in a single legal APB transfer.
Find the manager. For a chip with a CPU, a DMA engine, an AHB-to-APB bridge, and five APB peripherals, name the APB manager and explain why the CPU and DMA are not it.
Translate the terminology. Given an RTL module named apb_slave_uart with an "APB master" port on the bridge, restate both in manager/subordinate terms and confirm the signal directions are unchanged.

10. Key takeaways

APB has two fixed roles: manager and subordinate. The manager initiates and drives the request stream; the subordinate only responds when selected. The asymmetry is the whole point.
The manager owns PSEL, PADDR, PWRITE, PWDATA, PENABLE; the subordinate owns PRDATA, PREADY. Every wire has exactly one driver, fixed for all time.
Exactly one subordinate is selected per transfer. PSEL points at one block; all other subordinates are electrically present but logically silent, so only one block ever answers.
There is exactly one manager-side transaction stream — no concurrency, no arbitration on the APB bus. Any multi-master arbitration lives above the bridge on the fast bus.
In a real SoC the bridge is the APB manager. It is a subordinate on the fast bus and the manager on APB, converting one fast-bus access into the APB stream — the CPU never drives APB directly.
Master/slave is the legacy name for manager/subordinate. Same roles, same directions; only the terminology changed. Fixing these roles is what makes the upcoming lifecycle readable.