AMBA AHB · Module 2

AHB Bus Architecture

The concrete architecture of an AHB system — managers, subordinates, the arbiter, the decoder, and the multiplexor on a single shared bus, and how a transfer flows through them.

This opens Module 2 — AHB Architecture, where the conceptual model of Module 1 becomes a concrete structure. You already hold the mental model (a shared, arbitrated, two-phase bus) and the vocabulary (managers, subordinates, arbiter, decoder). This chapter wires them together into the actual architecture of an AHB system and traces how a single transfer flows through it. We are now at the threshold of signal-level detail — the next chapters will name the wires — so this chapter's job is to give you the map those wires live on. Get the architecture clear and every later signal will have an obvious home; skip it and the signals will feel like a flat list with no structure.

1. What Is It?

The AHB bus architecture is the arrangement of five kinds of blocks around one shared bus:

Managers — the blocks that initiate transfers (processor, DMA engine).
Subordinates — the blocks that respond (memories, peripherals, bridges).
The arbiter — the single block that decides which manager owns the shared bus at any moment.
The decoder — the single block that reads the current address and selects which subordinate should respond.
The multiplexor — the logic that routes the selected subordinate's read data and ready/response back to the active manager.

Figure 1 — the full AHB system. Managers feed the arbiter and drive the shared address and control bus; the decoder selects the addressed subordinate; subordinates drive read data and ready back through the multiplexor, which returns the targeted subordinate's response to the active manager. One shared bus, four supporting blocks, many subordinates.

That is the entire architecture. Notice the asymmetry: there are many managers and subordinates, but only one arbiter and one decoder, because there is only one shared bus to arbitrate for and one address to decode at a time. The architecture is the smallest structure that lets several managers share one bus to reach several subordinates correctly — and its smallness is, once again, the source of AHB's low cost.

2. Why Does It Exist?

This architecture exists because a shared bus, once you commit to it, forces a specific set of blocks into being — each one the answer to an unavoidable question.

Start with the decision from Module 1: use one shared bus, because it is cheap and the traffic is moderate. The moment you make that choice, four questions demand answers:

Several managers want the one bus — who gets it? You need an arbiter. Without it, two managers driving the bus at once corrupt each other; arbitration is mandatory the instant sharing is possible.
One bus reaches many subordinates — who responds to this access? You need a decoder that turns the address into a subordinate selection. Without it, no subordinate knows whether the current access is for it.
The selected subordinate must send read data back over the shared lines — whose data appears? You need a multiplexor that routes the chosen subordinate's read data and ready back, so the manager hears from exactly the right responder.
What if the address matches no subordinate? You need a default subordinate (from the terminology chapter) so that access completes cleanly rather than hanging the bus.

So the architecture is not a design someone invented from nothing — it is the forced consequence of sharing one bus among many managers and subordinates. Each block is the minimal mechanism that makes one more aspect of sharing work. This is why the architecture looks essentially the same across every shared-bus protocol: the questions are universal, and the blocks are the universal answers.

Figure 2 — the decoder and multiplexor as the interconnect. The decoder turns the address into a one-hot select so each subordinate knows whether it is the target; the multiplexor uses that same selection to route the chosen subordinate's read data and ready back onto the shared bus. Decode forward, multiplex back — that pairing is the whole routing mechanism.

3. Mental Model

The architecture is best held as a post office with one counter.

There is a single service counter (the shared bus). Several clerks-with-errands (the managers) want to use it, but only one can at a time, so a supervisor (the arbiter) decides whose turn it is. When a clerk is at the counter, they hand over a parcel labelled with a destination (the address and control information). A sorter (the decoder) reads the label and lights up exactly one of the destination bins (selects the subordinate). The destination bin processes the parcel and produces a reply, and a return-routing mechanism (the multiplexor) makes sure that reply comes back to the clerk who is currently at the counter — not to some other clerk.

The model captures the three things that matter:

Serialization at the counter. Only one clerk uses the counter at a time — the shared-bus constraint.
Routing by label. The sorter (decoder) directs each parcel to the right bin by its address — this is how one counter reaches many destinations.
Matched return path. The reply is routed back to the current clerk (multiplexor) — this is how the manager receives exactly its own subordinate's response and not another's.

Figure 3 — a transfer's journey, one step per block. The manager has a transfer; the arbiter grants the bus; the address phase drives address and control; the decoder selects the subordinate; the subordinate responds and the multiplexor routes the result back. The order is forced: the address must be decoded before the subordinate can respond — which is exactly why AHB splits each access into an address phase then a data phase.

That last figure plants the seed for the next two chapters: the journey has an order — address before data — because the subordinate cannot respond until the decoder has told it that it is the target. That ordering is not arbitrary; it is the architectural reason AHB has two phases, and it is exactly what chapters 2.3 and 2.4 will examine at signal level.

4. Real Hardware Perspective

In silicon, this architecture is a set of wires plus a few small logic blocks, and one structural detail is worth making explicit because it surprises people: AHB uses separate read and write data paths, not one bidirectional data bus.

On a classic bidirectional bus, the same wires carry data in both directions, which forces "turnaround" cycles when the direction flips and complicates timing. AHB avoids this. The address and control are driven by the active manager; write data flows on one set of wires from manager toward subordinate; read data flows on a separate set from subordinate back through the multiplexor to the manager. Because the directions have their own wires, there is no turnaround, the multiplexing is clean, and timing closure is simpler. This is a deliberate architectural choice that trades a few more wires for simpler, faster logic — a very AHB kind of trade.

The supporting blocks are correspondingly small. The arbiter is logic that watches the managers' request lines and asserts one grant. The decoder is combinational logic mapping the address to a one-hot subordinate select. The multiplexor is a wide mux steering the selected subordinate's read data and ready back. None of these needs queues, transaction tracking, or buffering — they are tiny compared to the managers and subordinates they serve. That is why an AHB interconnect costs a small fraction of a concurrent fabric: the architecture is mostly wires and a handful of gates, and the intelligence lives in the managers and subordinates, not in the interconnect.

5. System Architecture Perspective

At the system level, this architecture is a template that scales by adding managers and subordinates around the same fixed core of arbiter, decoder, and multiplexor — until it doesn't, at which point you move to the topologies of the previous module.

Adding a subordinate means extending the decoder's address map (a new region selects the new subordinate) and widening the multiplexor (one more input to route back). The cost is small and local — this is why AHB systems comfortably host a handful of memories and a bridge. Adding a manager is heavier: it adds an input to the arbiter and another competitor for the one shared bus, so each added manager raises contention exactly as the contention chapter described. The architecture therefore scales cheaply in subordinates but expensively in concurrent managers — which is the structural restatement of "AHB suits moderate, mostly single-threaded traffic."

This is also where the architecture connects to the chip's address map. The decoder is the address map made into logic: every range an architect assigns to a subordinate becomes a decode that selects it. When you place a new memory or peripheral in the system, you are simultaneously defining a decoder rule and a multiplexor input. The architecture and the address map are two views of the same thing, which is why getting the architecture clear also clarifies how the chip's memory map is realized.

And it is where the boundary to multi-layer AHB and AXI reappears structurally: those topologies replicate parts of this architecture — multiple address paths, per-subordinate arbitration — to break the single-bus serialization. Recognizing this architecture as the one-bus base case of that spectrum is what makes the more complex interconnects readable later: they are this diagram, multiplied.

6. Engineering Tradeoffs

The architecture embodies a tight set of tradeoffs, most of them already familiar, now grounded in structure.

One shared bus + one arbiter: minimal area, serialized managers. The single-bus core is tiny, but every manager competes for it. Cheap to build, limited in concurrency — the central AHB bargain, now visible as "one arbiter, one bus."
Separate read/write data paths: more wires, simpler timing. Splitting the data directions avoids bidirectional turnaround and eases timing closure, at the cost of more routing. AHB pays the wires to get the simplicity — a good trade for the speeds it targets.
Combinational decoder: fast selection, address-map coupling. Decoding the address combinationally keeps selection within the cycle, but it ties the interconnect to the address map: change the map, change the decoder. This is fine and expected, but it means the interconnect is not generic — it is built for a specific address map.
Centralized arbiter: predictable ordering, a single policy point. One arbiter gives clean, predictable bus ownership and one place to set priority/fairness policy. The cost is that all managers funnel through it, so it is both the control point and a contention point.

The unifying tradeoff: the architecture concentrates all sharing logic into a tiny central core and keeps the data paths simple. That concentration is what makes AHB cheap and predictable, and it is also what caps its concurrency — the single core can only let one access path through at a time. Every architectural strength here is the flip side of the concurrency ceiling, exactly as the mental model predicted.

7. Industry Example

Trace the architecture on a concrete microcontroller and watch each block do its job.

The chip has a processor and a DMA engine (managers), an on-chip SRAM, a flash controller, and an AHB-to-APB bridge (subordinates), plus the arbiter, decoder, and multiplexor of the interconnect.

Walk one transfer: the processor needs an instruction from flash.

The processor asserts its bus request; the arbiter, seeing no higher-priority manager active, grants it the bus.
The processor drives the address and control for the flash access onto the shared bus.
The decoder examines the address, recognizes it as the flash region, and selects the flash controller — the other subordinates see they are not selected and stay quiet.
The flash controller responds (perhaps needing the manager to wait if flash is slow); its read data and ready are routed by the multiplexor back to the processor.
Meanwhile the DMA engine may have been requesting the bus too; the arbiter, having granted the processor, makes the DMA wait its turn, and will grant it next.

Now scale the picture: add a second SRAM. The architects extend the decoder with a new address region and widen the multiplexor by one input — the rest of the architecture is untouched. Add a second DMA engine, though, and they add an arbiter input and a third competitor for the one bus, raising contention. The architecture absorbed the new subordinate almost for free and the new manager at a real cost — exactly the asymmetry the system-level section described. Reading a real AHB subsystem this way — singletons in the middle, managers and subordinates around them, transfers flowing through in the forced order — is the practical payoff of this chapter.

8. Common Mistakes

Architecture misconceptions to unlearn

"AHB has one bidirectional data bus." No — it uses separate read and write data paths to avoid turnaround and simplify timing. This is a deliberate architectural choice, not an accident.
"Separate read/write buses mean it can read and write simultaneously." No — there is still one shared bus and one access path at a time; an access is either a read or a write. The split is about wiring and timing, not concurrency.
"There are many arbiters and decoders." There is exactly one arbiter and one decoder for the shared bus, because there is one bus to grant and one address to decode at a time. Many managers and subordinates, but singleton control logic.
"The decoder is generic." It implements the chip's specific address map. Change the address map and you change the decoder — the interconnect is built for a particular set of subordinate regions.
"The arbiter or interconnect is the slow part." The interconnect logic is tiny and fast; the limit is the shared bus's serialization. Optimizing the gates does not fix a contention bottleneck.
"Adding a manager is as cheap as adding a subordinate." Adding a subordinate is cheap (extend decode, widen mux); adding a manager raises contention for the one bus. The architecture scales asymmetrically.

9. Interview Insight

"Draw the AHB architecture" or "walk me through an AHB transfer" is a standard interview task, and the structure of your answer reveals how deeply you understand it.

Figure 4 — the architecture in one card: managers and subordinates around a single shared bus, with one arbiter (picks the manager), one decoder (picks the subordinate), and a multiplexor (routes the response back). The senior detail that impresses: AHB uses separate read and write data buses rather than one bidirectional bus, avoiding turnaround and simplifying timing.

A strong answer names the singletons and the flow: "Managers and subordinates sit on one shared bus. The arbiter grants the bus to one manager; that manager drives address and control; the decoder selects the subordinate by address; the subordinate responds and the multiplexor routes its read data and ready back. Address precedes data because the subordinate can't respond until it's been selected — that's why there are two phases." Then add the detail that signals real understanding: AHB uses separate read and write data buses, not one bidirectional bus, to avoid turnaround.

10. Practice Challenge

Reason from the architecture, not from memorized block lists.

Name the singletons. State which blocks there is exactly one of in an AHB system and why each is a singleton.
Trace a write. Walk a processor's write to SRAM through every architecture block in order, naming what each does.
Explain the data paths. Describe why AHB separates read and write data, and explain why that does not give it read/write concurrency.
Scale it. Describe exactly what changes in the architecture when you add (a) a new memory subordinate and (b) a new DMA manager, and why one is cheaper than the other.
Locate a bottleneck. A subsystem is slow and a colleague proposes optimizing the decoder logic. Explain, from the architecture, why that is unlikely to help and what actually would.

11. Key Takeaways

The AHB architecture is managers and subordinates around one shared bus, served by a single arbiter, a single decoder, and a multiplexor. The control logic is singleton because the bus is singular.
Each block is a forced consequence of sharing one bus: arbiter (who drives), decoder (who responds), multiplexor (route the response back), default subordinate (handle unmapped addresses).
AHB uses separate read and write data paths, not one bidirectional bus — avoiding turnaround and simplifying timing, at the cost of more wires. This is not concurrency.
Address precedes data because the subordinate must be selected by the decoder before it can respond — the architectural root of the two-phase structure.
The architecture scales cheaply in subordinates, expensively in concurrent managers — the structural form of "AHB suits moderate, mostly single-threaded traffic."
The decoder is the address map in logic; the interconnect is built for a specific set of subordinate regions, and its gates are never the bottleneck — the shared bus's serialization is.

12. What Comes Next

You now have the structural map of an AHB system. The next chapter zooms into the supporting blocks individually, and then the module moves into the phases at signal level:

2.2 — Master, Slave, Decoder & Arbiter (coming soon) — each component in detail and the signals that connect them.
2.3 — The Address / Control Phase (coming soon) — what the manager drives in the address phase, at signal level, and why it precedes data.

To revisit the foundations this architecture realizes, see The AHB Mental Model, Manager / Subordinate Terminology, and Shared Bus vs Interconnect Thinking. For the broader context, see Why AHB Exists. For the broader protocol map, see the AMBA family overview.