Removed Arbitration

Chapter 12.2 listed the removed signals; this chapter zooms in on the single most consequential removal: arbitration. The arbiter and the request/grant handshake (HBUSREQ/HGRANT) exist for one purpose — to choose among competing masters and hand the bus between them. With a single master, there's no competition, so there's no choice to make and no handover to perform. The single master implicitly, always owns the bus — it never requests, never waits for a grant, and simply drives directly. This isn't just "the arbiter is removed"; it's that the entire concept of bus ownership becomes trivial (one owner, always). The consequences: no grant latency (the master drives immediately, no request-wait-grant before access), implicit atomicity (no other master can interrupt, so locking is automatic), and the entire arbitration verification class disappears (fairness, grant timing, starvation, handover races). This chapter explains why arbitration is removable, what "always owns the bus" precisely means, and the consequences.

1. What Is It?

Removed arbitration means AHB-Lite has no arbiter and no request/grant handshake — because, with one master, there's nothing to arbitrate. Recall what arbitration does in full AHB:

• The arbiter chooses which master gets the bus when several want it.
• HBUSREQ/HGRANT is the handshake: a master requests (HBUSREQ), waits, and the arbiter grants (HGRANT).
• Bus handover transfers ownership from the current master to the next.

With one master, all three of these are unnecessary: there's no "which master" to choose (only one), no need to request (no competitor to wait behind), and no handover (ownership never changes). So AHB-Lite removes the arbiter and the request/grant handshake entirely, and the single master always owns the bus — it drives the address/control directly, every cycle it has a transfer, without asking. So "removed arbitration" is the elimination of the bus-ownership-coordination layer: the master simply has the bus. This is the structural heart of the single-master simplification — the other removals (HMASTER, HLOCK, SPLIT/RETRY) largely follow from "one master, no arbitration." So removed arbitration is AHB-Lite's defining characteristic: no arbiter, no request/grant, one permanent owner.

2. Why Does It Exist?

Removed arbitration is the core simplification because arbitration's entire reason for being is multi-master coordination — and a single master makes every part of that reason vacuous. Understanding precisely why clarifies the whole of AHB-Lite.

The arbiter's reason for being is choosing among competitors: a bus is a shared resource only one master can drive at a time. With multiple masters wanting it, something must decide which one drives when — that's the arbiter, applying a policy (priority, round-robin) to pick a winner each time. So the arbiter exists solely to resolve competition for the bus. No competition → nothing to resolve → no arbiter. With one master, there's never a moment where two masters want the bus — so there's never a decision for an arbiter to make. So the arbiter's reason for being simply doesn't arise. So it's removed not as an optimization but because it would have nothing to do.

The request/grant handshake's reason is asking and being told: HBUSREQ is a master saying "I want the bus"; HGRANT is the arbiter saying "you may have it now." This dialogue exists because a master can't assume it has the bus — it must ask and wait (another master might have it). With one master, it can assume it has the bus — it always does — so it never needs to ask or wait. So the request/grant dialogue is pointless: the answer is always "yes, you have it." So HBUSREQ/HGRANT are removed because the question they encode ("may I have the bus?") has a constant answer with one master. So the handshake is vacuous.

The handover's reason is transferring ownership: when the arbiter switches the bus from master A to master B (chapter 10.9), there's a careful handover (A finishes, B takes over). This exists because ownership changes among masters. With one master, ownership never changes — the one master owns the bus from reset, forever. So there's no handover. So handover logic is removed because ownership is static. So removed arbitration exists because every aspect of arbitration — choosing (arbiter), asking (request/grant), transferring (handover) — presupposes multiple masters competing for and exchanging the bus, and a single master makes all three vacuous: nothing to choose, nothing to ask, nothing to transfer. The single master implicitly, permanently owns the bus. This is why it's the structural core: once you accept "one master always owns the bus," the arbiter/request/grant/handover must go (they'd be inert), and the other simplifications (HMASTER — only one; HLOCK — nothing to lock out; SPLIT/RETRY — no one to release to) follow directly. So removed arbitration is the keystone removal from which AHB-Lite's simplicity flows. (It's the inverse of Module 10: everything Module 10 built — the request/grant handshake, the arbiter, locked transfers, handover — is exactly what's removed here.)

3. Mental Model

Model removed arbitration as owning your own car versus using a car-sharing service — a car-share needs a booking app, a queue when cars are scarce, a "checked out by someone else" status, and handover logistics between users (the arbitration); but with your own car sitting in your garage, you just get in and drive whenever you want — no booking, no waiting, no checking if it's free, because it's always yours.

A car-sharing service (full AHB, multi-master) serves many users (masters) from a limited pool. It needs coordination: a booking app where you request a car and are told when you can have one (request/grant), a dispatcher deciding who gets the next available car (the arbiter), a "checked out" status so two people don't take the same car (ownership tracking), and handover logistics when one user returns a car and another takes it (bus handover). All of this exists because users share a limited pool — you can't just assume a car is yours. Now consider owning your own car (AHB-Lite): it sits in your garage, and it's always yours. You don't book it, don't wait for a dispatcher, don't check if someone else has it, and there's no handover — you just get in and drive, immediately, whenever you have somewhere to go. The driving (the transfer) is identical; but all the sharing coordination is gone, because there's no one to share with. You implicitly, permanently own the car.

This captures removed arbitration: the car-share service = full AHB's arbitration; your own car = AHB-Lite; the booking app = HBUSREQ/HGRANT; the dispatcher = the arbiter; "checked out" status = ownership tracking/HMASTER; handover logistics = bus handover; getting in and driving immediately = the single master driving directly with no grant latency; always yours = always owning the bus. Own the car (one master) and you skip all the sharing coordination — just drive.

Watch the AHB-Lite master issue transfers continuously — no grant gaps:

The model's lesson: own your own car — get in and drive, no booking, no waiting. In the waveform, the master drives a continuous stream (even switching slaves) with no grant gaps — it always owns the bus.

4. Real Hardware Perspective

In hardware, removed arbitration means the arbiter block is gone, the request/grant signal network is gone, the master needs no request/grant FSM, and the address/control path is a direct broadcast (no master-side mux) — shortening the access path.

The deleted arbiter block is the headline: a full-AHB arbiter is real logic — it samples all masters' HBUSREQ, applies its policy (priority encoder, round-robin pointer), generates HGRANT per master, drives HMASTER, and manages handover timing. All of this is deleted in AHB-Lite. There's no arbiter module instantiated. So a whole block (and its policy logic, registers, and state) vanishes. So in hardware, removed arbitration deletes the arbiter entirely.

The deleted signal network and master FSM: the HBUSREQ/HGRANT wiring (a request and grant per master, routed to/from the arbiter) is gone. And the master no longer needs its request/grant state machine — the logic that asserts HBUSREQ when it wants the bus, waits for HGRANT, and gates its driving on having the grant. In AHB-Lite, the master's bus interface just drives — its outputs (HADDR, HTRANS, etc.) go straight to the bus whenever it has a transfer, with no grant-gating. So the master's control logic is simpler. So in hardware, both the inter-block wiring and the master's arbitration FSM are removed.

The direct broadcast and shorter access path: in full AHB, the masters' address/control outputs are muxed (the arbiter's grant selects which master drives), and the arbiter sits in the path to bus access. In AHB-Lite, the one master's outputs broadcast directly to all slaves — no mux, no arbiter in the path. This shortens the access path: there's no request-wait-grant before a transfer, and no arbiter/mux delay in driving the bus. So the master can start a transfer immediately (no grant latency), and the combinational path to the bus is shorter (easing timing). So in hardware, removed arbitration eliminates the arbiter block, the request/grant network, and the master's arbitration FSM, replaces master-muxing with a direct broadcast, and thereby removes grant latency and shortens the access timing path — all while the transfer datapath is unchanged. So the hardware is both smaller and (on the access path) faster.

5. System Architecture Perspective

At the system level, removed arbitration is what makes AHB-Lite both simpler and, in a sense, more predictable — the single master has deterministic, immediate bus access, and the design sheds the hardest-to-verify part of a multi-master bus.

The deterministic access point: in a multi-master bus, a master's access latency is variable — it depends on the arbiter's policy and the other masters' activity (it might wait several cycles for a grant if higher-priority masters are busy). In AHB-Lite, the single master's access is deterministic: it always has the bus, so a transfer starts immediately, every time, with no arbitration-induced variability. So AHB-Lite gives the master predictable, immediate bus access — valuable for real-time and latency-sensitive code (no arbitration jitter). So at the system level, removed arbitration makes bus-access latency deterministic. This is a subtle but real benefit: the single master's timing is not at the mercy of an arbiter.

The implicit atomicity point: because no other master can ever access the bus, every sequence the single master issues is automatically atomic — a read-modify-write, a multi-transfer sequence, anything — cannot be interrupted by another master (there is none). In full AHB, achieving this requires locked transfers (HLOCK); in AHB-Lite, it's free and automatic. So the single master gets atomicity for nothing — it never needs to lock. So at the system level, removed arbitration provides implicit, free atomicity (which is why HLOCK is also removed — chapter 12.2). This simplifies software too (no need to use lock mechanisms for atomic sequences on the bus).

The verification-and-risk point (the biggest, echoing chapter 12.2): arbitration is the hardest part of a multi-master bus to get right and to verify. Fairness (does every master eventually get the bus?), grant timing (is the handover clean?), starvation (can a master be locked out?), priority interactions, lock/unlock corner cases, handover races — these are subtle, numerous, and a frequent source of bugs. Removing arbitration removes this entire category of design risk and verification effort. So at the system level, removed arbitration is the single biggest reduction in both complexity and risk — you don't just delete a block, you delete the hardest block and its hardest-to-verify behaviors. So removed arbitration's system value is threefold: deterministic immediate access (no arbitration jitter — good for real-time), implicit free atomicity (no locking needed), and a massive reduction in design risk and verification (the hardest, most bug-prone part of a multi-master bus is gone). This is why "removed arbitration" is the heart of why AHB-Lite is so attractive for single-master systems — it removes the part that is expensive, jittery, and dangerous, leaving a simple, deterministic, fully-performant transfer bus. So at the system level, removed arbitration is the keystone benefit, not just a keystone removal.

6. Engineering Tradeoffs

Removed arbitration embodies the no-competition-no-coordination design.

• No arbiter vs arbiter. Removing the arbiter eliminates the choosing/granting/handover logic and its verification, at the cost of supporting only one master. With one master, there's nothing to arbitrate, so it's pure savings.
• Direct drive (no grant latency) vs request/grant. Driving directly gives immediate, deterministic access (no grant wait); request/grant adds latency and variability. For one master, direct drive is strictly better.
• Implicit atomicity vs explicit locking. A single master gets atomicity free (no other master to interrupt); multi-master needs HLOCK. The single-master case removes the need for (and logic of) locking.
• Deterministic vs arbitration-jittered latency. AHB-Lite's access latency is deterministic (always owns the bus); multi-master latency varies with arbiter policy and contention. Determinism aids real-time design.

The throughline: the arbiter and request/grant handshake exist only to choose among competing masters and hand the bus between them; with one master there's no competition, so they're removed and the master implicitly always owns the bus, driving directly. This removes grant latency (immediate, deterministic access), provides implicit free atomicity (no locking), and eliminates the entire arbitration verification class (fairness, grant timing, starvation, handover races) — the hardest, most bug-prone part of a multi-master bus. It's the structural keystone of AHB-Lite, from which the other simplifications follow.

7. Industry Example

See removed arbitration in a single-master MCU.

A microcontroller's CPU is the sole master on its AHB-Lite bus.

• From reset, the CPU owns the bus. There's no arbiter to grant it; the CPU's bus interface drives HADDR/HTRANS from reset. When fetching the first instruction, it simply drives a NONSEQ transfer — no request, no grant wait.
• Immediate, deterministic access. Every memory access (instruction fetch, data load/store) starts immediately — the CPU never waits for a grant. So its bus-access latency is deterministic, with no arbitration jitter. This helps tight, real-time code where predictable timing matters.
• Idle cycles use HTRANS = IDLE. When the CPU has no bus transaction (e.g. executing register-only instructions), it drives HTRANS = IDLE — still owning and driving the bus, just signaling "no transfer." It doesn't release the bus; there's no one to release it to.
• Atomic sequences are free. When the CPU does a read-modify-write (e.g. a bit-set on a peripheral register), no other master can interrupt between the read and the write — there is no other master. So the sequence is automatically atomic; the CPU never needs a lock. (On full AHB with a DMA present, it would need HLOCK to guarantee this.)
• Adding a DMA breaks it. If a DMA engine is added as a second master, "the CPU always owns the bus" is no longer true — now there's competition. The design must add arbitration (full AHB) or use a bus matrix (per-slave arbitration with concurrency). At that point, grant latency, atomicity-needs-locking, and arbitration verification all return. So removed arbitration is valid precisely while there's one master.
• Verification. The MCU's bus verification has no arbitration tests — no fairness, no grant timing, no starvation, no handover. It focuses on transfers and slaves. The hardest multi-master verification simply doesn't exist for this bus.

The example shows removed arbitration's reality: the CPU owns the bus from reset, accesses immediately and deterministically, gets free atomicity, uses IDLE for no-op cycles, and the design avoids all arbitration logic and verification — valid as long as the CPU is the only master, revisited the moment a second master (DMA) appears.

8. Common Mistakes

9. Interview Insight

Removed arbitration is a conceptual interview topic — the "no competition → no arbiter," the "always owns the bus," and the consequences (no grant latency, free atomicity, verification savings) are the signals.

The answer that lands gives the reasoning and consequences: "AHB-Lite needs no arbiter or request/grant because those exist solely to choose among competing masters and hand the bus between them. The arbiter decides which master drives when several want the bus; HBUSREQ/HGRANT is the handshake where a master requests and waits to be granted; handover transfers ownership between masters. With a single master, there's no competition — no decision to make, no need to ask (the answer is always yes), and no handover (ownership never changes). So all of it is removed, and the single master implicitly, always owns the bus: it drives the address and control directly from reset, never requesting, and for no-op cycles it drives HTRANS = IDLE rather than releasing the bus. The consequences are significant. There's no grant latency — the master starts a transfer immediately, with deterministic access timing (no arbitration jitter), which helps real-time code. Atomicity is automatic — no other master can interrupt a sequence, so locking is unnecessary. And the entire arbitration verification class disappears — fairness, grant timing, starvation, handover races — which is the hardest, most bug-prone part of a multi-master bus. This is the structural core of AHB-Lite; the other simplifications, like removing HMASTER and HLOCK, follow from it." The no-competition reasoning, the always-owns framing, and the three consequences are the senior signals.

10. Practice Challenge

Reason from removed arbitration.

1. Why removable. Explain the arbiter's and request/grant's purpose and why each is vacuous with one master.
2. Always owns. Explain precisely what "the master always owns the bus" means, including idle cycles.
3. Read the waveform. From Figure 2, explain how the master issues back-to-back transfers (even switching slaves) with no grant gaps.
4. Consequences. State the three consequences of removed arbitration (latency, atomicity, verification).
5. Keystone. Explain how removing HMASTER, HLOCK, and SPLIT/RETRY follow from removed arbitration.

11. Key Takeaways

• AHB-Lite has no arbiter and no request/grant — these exist only to choose among competing masters and hand the bus between them; with one master, there's no competition, so they're removed entirely.
• The single master implicitly, always owns the bus — it drives the address/control directly from reset, never requesting or waiting for a grant, and uses HTRANS = IDLE for no-op cycles (it never releases the bus).
• No grant latency, deterministic access — transfers start immediately, with no arbitration-induced variability (good for real-time).
• Implicit free atomicity — no other master can interrupt, so sequences are automatically atomic; HLOCK is unnecessary (and removed).
• The entire arbitration verification class disappears — fairness, grant timing, starvation, handover races — the hardest, most bug-prone part of a multi-master bus is gone.
• It's the structural keystone of AHB-Lite — the other simplifications (no HMASTER, no HLOCK, no SPLIT/RETRY, no handover) all follow from "one master, always owns the bus."

12. What Comes Next

You now understand removed arbitration — the keystone simplification and its consequences. The next chapters cover the remaining AHB-Lite specifics:

• Simplified Responses (next) — the narrowing to OKAY/ERROR (no SPLIT/RETRY), and how a slow slave stalls with wait states.
• AHB-Lite Slave Design — how to build a correct, simpler AHB-Lite slave.

To revisit the arbitration machinery being removed, see HBUSREQ & HGRANT, Bus Ownership Handover, and Locked Transfers; for the broader simplification, see Single-Master Simplification.