HBUSREQ & HGRANT

Chapter 10.1 established why an arbiter is needed. This chapter covers the request/grant handshake that assigns bus ownership: HBUSREQ and HGRANT. Each master drives HBUSREQ to the arbiter to request the bus; the arbiter, applying its policy, drives HGRANT to one requesting master — granting it ownership. The crucial timing nuance: a grant is not instant ownership. The granted master becomes the next owner and only begins driving the bus at the next transfer boundary — which it detects by HGRANT asserted together with HREADY high (the current transfer completing, the bus free). So "granted" means "you're next; take the bus at the next clean boundary." This keeps the handover clean — the previous master's transfer finishes before the new one drives. HBUSREQ/HGRANT is the per-master request/grant pair (one each per master), with only one HGRANT asserted at a time.

1. What Is It?

The request/grant handshake assigns bus ownership via two per-master signals:

• HBUSREQ — each master's request to the arbiter: "I want the bus." A master asserts it (and keeps it asserted) while it wants the bus.
• HGRANT — the arbiter's grant to a master: "you have it." The arbiter, per its policy, asserts HGRANT to exactly one requesting master.

So the handshake is: master requests (HBUSREQ), arbiter grants one (HGRANT), granted master becomes owner. There's one HBUSREQ and one HGRANT per master (the arbiter has a request input and a grant output for each master), and the arbiter asserts only one HGRANT at a time (the single-grant invariant, chapter 10.1). A master keeps HBUSREQ asserted as long as it wants the bus — so it can request, get granted, use the bus, and (if it still wants it) keep requesting; or deassert HBUSREQ when done. The arbiter continuously evaluates the requests and grants per its policy.

2. Why Does It Exist?

The request/grant handshake exists because the arbiter needs to know which masters want the bus (to apply its policy) and to tell the chosen master it has the bus — a two-way communication that HBUSREQ (request) and HGRANT (grant) provide.

For the arbiter to decide who gets the bus, it must know who wants it — which masters are requesting. HBUSREQ provides this: each master asserts it when it wants the bus, so the arbiter sees the set of requesters. Then the arbiter applies its policy to pick one and must tell that master it's been chosen — HGRANT provides this: the arbiter asserts it to the chosen master. So the handshake exists to carry the two halves of the arbitration decision: requests in (HBUSREQ, masters → arbiter) and the grant out (HGRANT, arbiter → master). Without HBUSREQ, the arbiter wouldn't know who wants the bus; without HGRANT, the chosen master wouldn't know it was selected. So the request/grant pair is the necessary communication for arbitration.

The reason a grant means "you're next" (not instant ownership) is the clean-handover requirement (chapter 10.1): the previous master's transaction must complete before the new master drives, or the bus would have two drivers (collision) or an interrupted transaction. So when the arbiter grants a new master, that master must wait until the current transfer completes before taking the bus. So the grant signals future ownership ("you're next"), and the master takes the bus at the next clean boundary. This is why grant ≠ instant ownership: the handover must be clean, so the grant is a "you're next" notification, not an immediate handover. The timing mechanism (HGRANT with HREADY high) is how the master knows when to take the bus.

The reason the master detects its turn via HGRANT + HREADY high is that this combination marks the clean boundary: HGRANT means "you're granted" and HREADY high means "the current transfer is completing." Together, at a transfer boundary, they mean "the bus is now yours to drive." So the granted master watches for HGRANT-and-HREADY-high to know when to start driving. This is the precise timing of the handover: the master takes the bus on the cycle after HGRANT + HREADY high (the current transfer done, the master granted). So the handshake's timing exists to coordinate the moment of handover — the granted master begins exactly when the bus is free and it's still granted. (Chapter 10.8 details this timing further.) This precise coordination is what makes the request/grant handshake produce a clean, glitch-free ownership change.

3. Mental Model

Model HBUSREQ/HGRANT as raising your hand to ask for the talking stick and being pointed to by the facilitator — but you don't grab the stick until the current speaker finishes their sentence.

In a discussion (the multi-master system), there's a talking stick (the bus). To speak, you raise your hand (assert HBUSREQ — "I want to speak"). The facilitator (the arbiter) sees the raised hands and points to one person (asserts HGRANT — "you're next"). But being pointed to doesn't mean you grab the stick right now — you wait for the current speaker to finish their sentence (the current transfer to complete), and then you take the stick (drive the bus). You know it's your turn when you're being pointed to and the current speaker is wrapping up (HGRANT + HREADY high). If you grabbed the stick mid-sentence, you'd talk over the current speaker (collision). So: raise your hand (request), get pointed to (granted = you're next), wait for the current sentence to finish, then take the stick (own the bus). And you keep your hand raised while you still want to speak.

This captures the handshake: raising your hand = HBUSREQ (request); the facilitator pointing to you = HGRANT (granted, "you're next"); waiting for the current sentence to finish = waiting for the transfer to complete; taking the stick when pointed-to and the speaker's wrapping up = driving the bus at HGRANT + HREADY high; keeping your hand up = keeping HBUSREQ asserted. Pointed-to means next, not now.

Watch the request/grant handshake for two masters:

The model's lesson: request by raising your hand (HBUSREQ), get pointed to (HGRANT = you're next), take the bus at the clean boundary. In the waveform, both masters request; the arbiter grants the CPU, then the DMA; only one HGRANT is high at a time, and the newly-granted master takes the bus at the next HREADY-high boundary — a clean handover.

4. Real Hardware Perspective

In hardware, HBUSREQ and HGRANT are per-master signals between each master and the arbiter — HBUSREQ an output of the master (input to the arbiter), HGRANT an output of the arbiter (input to the master) — and the master uses HGRANT + HREADY to time when it drives the bus.

The signal directions are: each master drives its HBUSREQ to the arbiter (the master's request output); the arbiter drives each master's HGRANT (the arbiter's grant output to that master). So the arbiter has, per master, an HBUSREQ input and an HGRANT output. The master has an HBUSREQ output and an HGRANT input. This is a point-to-point request/grant pair per master, all going to/from the central arbiter. The arbiter's policy logic (chapters 10.5–10.6) maps the set of HBUSREQ inputs to the HGRANT outputs (asserting one).

The master's drive timing uses HGRANT and HREADY: the granted master begins driving the bus (its address phase) on the cycle after it sees HGRANT asserted and HREADY high — meaning it's granted and the current transfer is completing.

So the master doesn't drive the moment it's granted; it waits for the clean boundary (HGRANT + HREADY high). This timing ensures the previous master's transfer completes first. In hardware, the master's control logic gates its bus-driving on (HGRANT and HREADY high) — it starts its address phase only then. So the request/grant handshake plus HREADY produces the clean, timed handover (chapter 10.8 details the cycle-by-cycle timing).

The keeping-HBUSREQ-asserted behavior is how a master holds or re-requests the bus: a master that wants the bus for multiple transactions keeps HBUSREQ asserted; the arbiter may keep granting it (if its policy allows) or grant others between (round-robin). A master deasserts HBUSREQ when it no longer wants the bus. So HBUSREQ is a level signal (asserted while wanting the bus), not a one-shot pulse. The arbiter continuously evaluates the asserted HBUSREQs. This is why a master can be granted, use the bus, and stay granted (or be re-granted) by keeping HBUSREQ high — useful for a master with sustained traffic.

A hardware note on the default master / bus parking: when no master is requesting (all HBUSREQ deasserted), the arbiter may park the bus on a default master (grant it by default) so the bus has an owner ready. This avoids a delay when a master next requests (the parked master can start immediately, or the default is granted). So the arbiter often has a parking policy for the idle case — granting a default master when no one's requesting. This is a hardware optimization for the idle-to-active transition. (The details vary by arbiter design.) So the request/grant handshake includes handling the no-requests case via parking.

5. System Architecture Perspective

At the system level, the request/grant handshake is the interface between the masters and the arbiter — how masters express their need for the bus and learn they have it — and its timing (grant-then-own) is what enables clean, glitch-free ownership handover in a multi-master system.

The master-arbiter interface is the handshake's role: HBUSREQ/HGRANT is the protocol by which masters and the arbiter coordinate bus access. A master that needs the bus asserts HBUSREQ; the arbiter responds with HGRANT. So this handshake is the multi-master coordination interface — every master implements it (request output, grant input), and the arbiter implements the other side (request inputs, grant outputs). So the request/grant handshake is the standardized way masters and the arbiter interact, making masters and arbiters interoperable (any compliant master works with any compliant arbiter). This is a key architectural interface in multi-master AHB.

The clean-handover enablement is the handshake's timing contribution: because grant means "you're next" (not instant ownership), and the master takes the bus only at the clean boundary (HGRANT + HREADY high), the handover between masters is clean — the previous master's transfer completes, then the new master drives, with no overlap. So the request/grant timing is what makes multi-master ownership changes glitch-free. This is essential: without the grant-then-own timing, a grant could cause two masters to drive at once (collision). So the handshake's timing is the system-level mechanism for clean bus handover (detailed in chapters 10.8–10.9). The handshake doesn't just assign ownership; it assigns it with clean timing.

The latency implication is a system consideration: there's a latency between a master requesting the bus (asserting HBUSREQ) and actually driving it (after being granted and waiting for the clean boundary) — the arbitration latency. This latency depends on the arbiter's policy (how quickly it grants this master, given contention) and on the current transfer completing. So a master's bus-access latency includes this arbitration delay. For latency-sensitive masters, the arbitration policy (chapters 10.5–10.7) is tuned to minimize their wait (e.g., high priority). So at the system level, the request/grant handshake introduces an arbitration latency that the policy shapes — a key factor in multi-master system performance. The handshake is the mechanism; the policy and contention determine how long a master waits between request and ownership. So the request/grant handshake is the master-arbiter interface, enabling clean handover with a policy-dependent arbitration latency — fundamental to how multi-master AHB coordinates and performs.

6. Engineering Tradeoffs

The request/grant handshake reflects the explicit-request, timed-grant design.

• Explicit request (HBUSREQ) vs implicit. Having masters explicitly request (HBUSREQ) lets the arbiter know exactly who wants the bus and apply its policy precisely, at the cost of a per-master request signal. An implicit scheme would be ambiguous. Explicit requests are clean and standard.
• Grant-then-own vs instant ownership. Making grant mean "you're next" (own at the clean boundary) ensures clean handover (no collision, no interrupted transfer) at the cost of arbitration latency (the master waits for the boundary). Instant ownership would risk collisions/interruptions. Grant-then-own is the safe, clean choice.
• Level HBUSREQ vs pulsed. A level HBUSREQ (asserted while wanting the bus) lets the arbiter continuously evaluate and lets a master hold/re-request, at the cost that the master must manage when to deassert. A pulsed request would be one-shot and less flexible. Level is flexible and standard.
• Bus parking vs no parking. Parking the bus on a default master when idle reduces the idle-to-active latency (the parked master can start quickly) at the minor cost of the parking logic. No parking would add a grant delay on the first request. Parking is a common optimization.

The throughline: HBUSREQ (request) and HGRANT (grant) are the per-master handshake by which masters request the bus and the arbiter grants it to one — with the key timing that a grant means "you're next," the granted master taking the bus at the next clean boundary (HGRANT + HREADY high). This explicit, timed handshake is the master-arbiter interface, enabling clean glitch-free handover, with a policy-dependent arbitration latency. The grant-then-own timing is the crucial detail — it's what makes the handover clean.

7. Industry Example

Trace the request/grant handshake in a multi-master system.

A system has a CPU and a DMA engine sharing a bus via an arbiter.

• The CPU requests and is granted. The CPU needs the bus, so it asserts HBUSREQ_cpu. The arbiter, per its policy, asserts HGRANT_cpu — granting the CPU. The CPU, seeing HGRANT_cpu and HREADY high at a boundary, begins driving the bus (its transfers). The CPU is now the owner.
• The DMA requests while the CPU owns the bus. The DMA also needs the bus, so it asserts HBUSREQ_dma — but the CPU currently owns the bus (HGRANT_cpu high). So the DMA waits, HBUSREQ_dma asserted, not yet granted. The arbiter sees both requests but has granted the CPU.
• The arbiter hands over to the DMA. When the CPU finishes (or the policy decides to switch — e.g., round-robin, or the CPU deasserts HBUSREQ), the arbiter asserts HGRANT_dma and deasserts HGRANT_cpu. The DMA, seeing HGRANT_dma and HREADY high at the next boundary, takes the bus and begins driving. The CPU's last transfer completed cleanly before the DMA drove — a clean handover.
• The grant-then-own timing. Crucially, the DMA didn't drive the instant it was granted — it waited for HREADY high (the CPU's transfer completing). This ensured no collision. The grant said "you're next"; the DMA took the bus at the clean boundary.
• Sustained requests. A master with ongoing traffic keeps its HBUSREQ asserted, so the arbiter keeps it in consideration (granting it again if the policy allows, or interleaving with others). A master done with the bus deasserts HBUSREQ. So the level HBUSREQ lets masters express sustained or one-off needs.
• Bus parking. When neither master is requesting (both HBUSREQ deasserted), the arbiter parks the bus on a default master (say the CPU), so when the CPU next needs it, there's no grant delay. This optimizes the idle-to-active transition.

The example shows the request/grant handshake coordinating the CPU and DMA: each requests via HBUSREQ, the arbiter grants one via HGRANT, and the granted master takes the bus at the clean boundary (HGRANT + HREADY high) — never instantly, ensuring no collision. The level HBUSREQ handles sustained requests, and parking optimizes the idle case. The grant-then-own timing is what makes the handover clean.

8. Common Mistakes

9. Interview Insight

HBUSREQ/HGRANT is a common interview topic — the request/grant roles and the grant-then-own timing are the signals.

The answer that lands explains the handshake and the timing: "HBUSREQ and HGRANT are the request/grant handshake. Each master drives HBUSREQ to the arbiter to request the bus — it's a level signal, asserted while the master wants the bus. The arbiter, applying its policy, drives HGRANT to exactly one requesting master — only one HGRANT is asserted at a time. The crucial nuance is the timing: a grant is not instant ownership. HGRANT means the master is next — it becomes the owner and starts driving the bus only at the next clean transfer boundary, which it detects by HGRANT asserted together with HREADY high, meaning it's granted and the current transfer is completing. So the granted master waits for the current transfer to finish, then drives — keeping the handover clean, with no collision. A common mistake is thinking grant means drive-now; but the master must gate its driving on HGRANT and HREADY high. And there's an arbitration latency between requesting and owning, shaped by the policy and contention." The request/grant roles, the grant-then-own timing (HGRANT + HREADY high), and the level-request/single-grant properties are the senior signals.

10. Practice Challenge

Reason from the request/grant handshake.

1. State the signals. Explain what HBUSREQ and HGRANT each do and their directions.
2. The grant timing. Explain why a grant means "you're next" and how the master times its bus-driving.
3. Read the waveform. From Figure 2, identify the handover from CPU to DMA and why it's clean.
4. Level request. Explain why HBUSREQ is a level signal and how a master holds/re-requests.
5. Arbitration latency. Explain the latency between requesting and owning the bus.

11. Key Takeaways

• HBUSREQ is each master's request for the bus (a level signal, asserted while wanting the bus); HGRANT is the arbiter's grant to one requesting master (per its policy).
• One HBUSREQ and one HGRANT per master (point-to-point with the arbiter); only one HGRANT asserted at a time (single-grant invariant).
• A grant is not instant ownership — it means "you're next." The granted master drives the bus at the next clean boundary, detected by HGRANT asserted with HREADY high.
• The master gates its bus-driving on (HGRANT and HREADY high), not HGRANT alone — so the current transfer finishes first, keeping the handover clean (no collision).
• There's an arbitration latency between requesting and owning the bus, shaped by the policy and contention; the arbiter may park the bus on a default master when idle.
• HBUSREQ/HGRANT is the master-arbiter interface — the standardized request/grant handshake enabling clean, timed ownership handover in multi-master AHB.

12. What Comes Next

You now understand the request/grant handshake. The next chapter covers how the arbiter signals the current master to the rest of the system:

• 10.3 — HMASTER (coming next) — how the arbiter signals the current master's ID to the fabric (used by slaves, SPLIT, etc.).
• 10.4 — Locked Transfers (HLOCK) (coming soon) — locked sequences that prevent arbitration mid-transaction.

To revisit why arbitration is needed, see Why Arbitration Exists. For the clean-handover timing this enables, the arbitration-timing and bus-ownership-handover chapters come later in this module. For the HREADY the grant timing uses, see What HREADY Means. For the broader protocol map, see the AMBA family overview.