AMBA AXI · Module 1

Manager, Subordinate & Interconnect

The three AXI roles — manager, subordinate, and interconnect — what each does, how traffic flows between them, and why a role belongs to an interface, not a block.

The mental model in the last chapter assumed two parties — a requester and a completer — with something between them. This chapter names them properly: the manager that initiates a transaction, the subordinate that completes it, and the interconnect that routes traffic between many of each. These three roles are the cast of every AXI sentence you will ever read, and getting them right — especially the fact that a role belongs to an interface, not to a block — prevents a whole category of confusion in design reviews, debugging, and interviews. We stay conceptual: roles and traffic flow, not channel signals.

1. Three Roles, One Traffic Pattern

Every AXI transaction is a conversation with a fixed shape: one side asks, the other side answers, and a fabric in the middle carries the message to the right place and back. AXI gives those parts names:

The manager initiates transactions — it issues the read or write request. It is the active party.
The subordinate completes transactions — it receives a request addressed to it and returns the data and/or response. It is the reactive party.
The interconnect sits between them and routes each transaction from the manager that issued it to the subordinate it targets, and the response back again.

That asymmetry is the heart of the model: a manager can start a transaction; a subordinate can only respond to one. A subordinate never spontaneously reaches out — it answers what arrives. Keep that direction of initiative straight and most AXI topology questions answer themselves.

2. The Manager — The Requester

A manager is any block that originates AXI transactions: it decides to read or write, drives the address and control for the request, and consumes the data or response that comes back. CPUs, DMA engines, GPUs, and accelerators are the classic managers — the blocks that go and get data or go and put it.

The defining property is initiative: the manager is the one with intent. It chooses the address, the direction, and the timing of issuing a transaction. Everything downstream — routing, arbitration, the subordinate's response — is set in motion by a manager deciding to act.

3. The Subordinate — The Completer

A subordinate is any block that responds to transactions addressed to it: a memory controller, an on-chip SRAM, a register block, a peripheral. It watches its interface for a request, performs the access, and returns the data (for a read) and/or a completion (for a write). It owns a region of the address map — the range of addresses that belong to it — and answers only for that range.

The defining property is reactivity: a subordinate has no initiative of its own. It cannot start a transaction; it can only complete one that a manager started and the interconnect delivered. A memory controller does not decide to send you data — it sends data because a manager read from it.

Figure 1 — the three roles. A manager initiates a transaction; the interconnect routes it to the addressed subordinate and routes the response back; the subordinate completes the transaction it was handed. Initiative flows one way — only the manager can start a transaction.

4. The Interconnect — The Fabric

The interconnect is the piece beginners under-appreciate, because in a one-manager-one-subordinate diagram it looks like a wire. In a real SoC it is the most architecturally significant block on the bus, and it has three jobs:

Route. It decodes the address of each transaction to decide which subordinate owns it, and steers the request to that subordinate — and steers the response back to the manager that issued it. The address map lives here.
Arbitrate. When two managers want the same subordinate at the same time, the interconnect arbitrates — it decides who goes first and in what order, fairly enough that no manager starves.
Convert. Managers and subordinates may differ in data width, clock domain, or even protocol generation. The interconnect converts between them — width up/down-sizing, clock-domain crossing, protocol bridging — so mismatched blocks can still talk.

So the interconnect is where routing policy, fairness, and adaptation live. The detailed mechanics — crossbars, decoders, arbiters, address maps, clock/reset domains — are an entire later module (Module 12); here, the model you need is "a smart fabric that decodes, arbitrates, and converts," not a wire.

5. How Traffic Flows

Put the roles in motion and a transaction is a four-leg trip: the manager issues a request, the interconnect decodes and routes it to the right subordinate, the subordinate completes it, and the interconnect returns the result to the originating manager.

Figure 2 — traffic flow for one transaction, time downward. The manager issues a request; the interconnect decodes the address and routes it to the owning subordinate; the subordinate performs the access and returns data/completion; the interconnect routes the result back to the manager that issued it.

The crucial detail is that the interconnect tracks who asked, so the response returns to the right manager even when several have transactions in flight at once. That bookkeeping is exactly what lets many managers share subordinates without their traffic getting crossed.

The whole pattern in four conceptual lines — notice initiative only ever starts at the manager:

Azvya Education Pvt. Ltd.VLSI Mentor

Snippet

// Conceptual — the three roles as a flow, not an implementation.
manager.issue(req);                       // only a manager starts a transaction
target = interconnect.route(req.addr);    // decode address -> owning subordinate
resp   = target.complete(req);            // the subordinate only responds
interconnect.return_to(manager, resp);    // routed back to whoever asked

Read it top to bottom and the asymmetry is visible: a subordinate never appears on the left of a call that starts anything — it only complete()s what it is handed. That single rule is what "a role belongs to an interface" (next section) builds on.

6. The Interconnect's Real Job — Many to Many

The single-transaction picture undersells the interconnect, because its reason to exist is many managers and many subordinates at once. Real SoCs have several managers (CPU, DMA, GPU) and several subordinates (DRAM, SRAM, peripherals), and the interconnect is the N-by-M fabric that lets any manager reach any subordinate it is allowed to — with disjoint pairs talking in parallel.

Figure 3 — the interconnect as an N-by-M fabric. Several managers reach several subordinates through one interconnect; it decodes each request to the right target and arbitrates contention, so a CPU→DRAM transfer and a DMA→peripheral transfer can proceed at the same time. This concurrent routing is the interconnect's whole purpose.

This is also where the address map becomes concrete: the interconnect's decoder turns an address into which port a request leaves by. Two managers reading two different subordinates never contend; two managers reading the same subordinate are serialised by arbitration. Both behaviours are interconnect policy, not manager or subordinate behaviour.

7. A Role Belongs to an Interface, Not a Block

Here is the idea that trips up the most people and matters the most: manager and subordinate are roles of an interface, not labels stuck on a block. The same block is frequently a manager on one of its AXI ports and a subordinate on another.

The canonical example is a DMA engine. On its control interface it is a subordinate: the CPU writes its configuration registers, so the CPU is the manager and the DMA is the subordinate. On its data interface it is a manager: it issues its own reads and writes to memory to move the data, so the DMA is the manager and the memory is the subordinate. Same block, two roles, two interfaces — simultaneously.

Figure 4 — a role is per-interface. A DMA engine is a subordinate on its control port (the CPU configures it) and a manager on its data port (it drives memory itself). The block has no single role; each of its AXI interfaces does. Bridges and many accelerators are the same.

Bridges, accelerators, and the interconnect's own ports are the same story. So the right question is never "is this block a manager or a subordinate?" — it is "on this interface, which side has the initiative?" Answer that per interface and topology stops being confusing.

8. Common Misconceptions

Myths to unlearn

"A block is either a manager or a subordinate." A role is per-interface. A DMA is a subordinate on its control port and a manager on its data port — at the same time. Always ask which side initiates on this interface.
"The interconnect is just wiring." It decodes addresses, arbitrates contention, and converts width/clock/protocol. It is policy and logic, not a passive bus — the most architecturally important block on the fabric.
"A subordinate can start a transaction." It cannot. Subordinates only respond to transactions a manager initiated; initiative flows one way.
"Manager/subordinate and master/slave are different things." They are exact synonyms — AMBA 5 renamed master→manager and slave→subordinate. You will see both terms constantly; treat them as identical.
"More managers just means more wires." More managers means more contention and arbitration at shared subordinates — a routing and fairness problem the interconnect must solve, not a wiring count.

9. Debugging Insight

🔍 Debugging insight — locate the failure by role and by boundary

When an AXI transaction misbehaves, the role model points you at the culprit fast, because each role can only fail in its own way:

Did the manager actually issue what you think? Initiative starts here — a "missing" transaction is often a manager that never issued it (wrong address, disabled, mis-programmed). Confirm the request left the manager before blaming anything downstream.
Did the interconnect route it correctly? Most real bugs live in the interconnect and its boundaries — a wrong address-map entry routes a request to the wrong subordinate (or to none), and width/clock conversion is where assumptions mismatch. If the manager issued correctly but the wrong subordinate (or no subordinate) responded, suspect decode/routing.
Did the subordinate complete correctly? Only after the first two — a subordinate returning a wrong or error response is a problem inside the target, not on the fabric.

And because the same block can be a manager and a subordinate, always pin down which interface the symptom is on: a DMA "not working" might be a failure to configure it (its subordinate port) or a failure of its memory accesses (its manager port) — completely different hunts. Identify the role, the interface, and the boundary the transaction crossed, and you have localised the bug before opening a waveform.

10. Verification Insight

✅ Verification insight — you verify per role, per interface

Verification environments are built around these roles, and a tidy way to see it: every AXI interface needs the opposite role driving it. To verify a subordinate (say, a memory controller), the testbench supplies a manager model (often called a master/manager agent) that issues stimulus into it; to verify a manager (say, a DMA's data port), the testbench supplies a subordinate model that responds to its requests. A monitor sits passively on the interface and reconstructs transactions regardless of role.

The practical consequences: a block with two interfaces in two roles needs both sides modelled — a manager model on its subordinate port and a subordinate model on its manager port — and the interconnect itself is verified by checking that every request reaches the right subordinate and every response returns to the right manager, under contention. Match the verification component to the role of each interface, and the environment falls out naturally. The detailed agent mechanics come in the verification module.

11. Interview Questions

12. Summary

AXI has three roles and a fixed direction of initiative. A manager initiates transactions; a subordinate completes the ones addressed to it and never initiates; and the interconnect between them decodes addresses to route requests to the right subordinate, arbitrates when managers contend, converts between width/clock/protocol differences, and returns each response to the manager that issued it. In a real SoC the interconnect is an N-by-M fabric that lets disjoint manager→subordinate pairs run in parallel while serialising those that target the same subordinate — making it the most architecturally important block on the bus, not a wire.

The idea to carry forward is that a role belongs to an interface, not a block: a DMA is a subordinate on its control port and a manager on its data port at the same time, so the useful question is always "on this interface, which side has the initiative?" That framing — plus knowing manager/subordinate and master/slave are the same terms — lets you read any AXI topology, scope any bug to a role, interface, and boundary, and build a verification environment whose components match each interface's role.

13. What Comes Next

Module 1 closes by sharpening the altitude these roles operate at, then Module 2 makes the channels concrete:

1.6 — Transaction-Level Thinking (coming next) — reasoning in transactions and beats rather than cycles, the habit the whole track rewards.
2.1 — The Five AXI Channels (coming soon) — where the manager↔subordinate conversation becomes the exact five-channel architecture, by name.

Previous: 1.4 — The AXI Mental Model. For the broader protocol catalog, see the AMBA family overview doc.