HGRANT & HBUSREQ

This chapter covers the arbitration handshake — the signals by which masters ask for the bus and the arbiter hands it out. HBUSREQ is a master's request; HGRANT is the arbiter's grant. Together they implement the bus ownership decisions we have referred to since the architecture chapters. The subtle, important point — and the classic interview catch — is that a grant is not ownership: a master that has been granted the bus does not start driving until the previous owner's transfer completes, signalled by HREADY. These are full multi-master AHB signals that AHB-Lite drops (one master needs no arbitration). We give each signal's role, the ownership-transfer timing, and how it fits the arbiter from chapter 2.2.

1. What Is It?

These are the two arbitration signals:

• HBUSREQ is each master's bus request: master 1 drives HBUSREQ_1, master 2 drives HBUSREQ_2, and so on, to tell the arbiter "I want the bus."
• HGRANT is the arbiter's grant: the arbiter drives one HGRANT per master, asserting exactly one (one-hot) to name the master that may use the bus.

The key timing rule: a granted master does not take ownership immediately. Ownership transfers — the master starts driving the address — only on a cycle where its HGRANT is high and HREADY is high. HREADY high means the previous owner's transfer has completed, so the bus is free to hand over cleanly.

The framing: HBUSREQ/HGRANT are the request/grant pair that realizes arbitration. The arbiter (chapter 2.2) is the block that consumes the requests and produces the grant, applying its priority/fairness policy. And, as with every other AHB signal, the handover is gated by HREADY — the recurring theme that nothing advances until the current transfer completes. In a single-master AHB-Lite system, there is nothing to arbitrate, so HBUSREQ and HGRANT do not exist (chapter 2.7).

2. Why Does It Exist?

The request/grant handshake exists because a shared bus with multiple masters needs a clean, orderly way to decide and transfer ownership — and that decision must not corrupt an in-progress transfer.

Why HBUSREQ. Masters cannot just start driving the bus whenever they like — two masters driving at once would corrupt the bus. So a master must ask before it can drive, and HBUSREQ is that request. It lets the arbiter know which masters want the bus so it can apply its policy. Without a request signal, the arbiter would have no way to know who needs the bus.

Why HGRANT. The arbiter must tell the chosen master it may proceed, and the others that they must wait. HGRANT is that grant — one-hot so exactly one master is authorized at a time, which is the precondition for the bus working (only one driver). HGRANT is how the arbiter's decision reaches the masters.

Why ownership waits for HREADY. This is the subtle, essential part. When the arbiter grants the bus to a new master, the previous owner may still be mid-transfer (its data phase not yet complete). If the new master started driving immediately on HGRANT, it would collide with the previous owner's in-progress transfer. So ownership transfer is gated by HREADY: the new master, though granted, waits until HREADY is high — the moment the previous transfer completes — and only then begins driving. This makes the handover clean: the previous owner finishes, the bus becomes free, and the granted master takes over, with no overlap. HREADY is what synchronizes the ownership handoff to transfer boundaries.

So the handshake exists to make bus ownership requestable, decidable, and cleanly transferable among masters. HBUSREQ asks, HGRANT decides, and HREADY times the actual handover so it never collides with an in-progress transfer. All three are needed for orderly multi-master sharing — and all three are unnecessary with a single master, which is why AHB-Lite drops them.

3. Mental Model

Model the handshake as raising your hand for a shared microphone, the chair pointing to you, but you only speak once the current speaker finishes.

In a meeting with one microphone (the bus), you raise your hand (HBUSREQ) to ask to speak. The chair (arbiter) points to you (HGRANT) to say "you're next." But you do not grab the mic the instant you are pointed to — you wait until the current speaker finishes their sentence (HREADY high, the current transfer completes), then you take the mic. If you started talking the moment you were pointed to, you would talk over the current speaker (bus collision). The three steps — raise hand, get pointed to, take the mic when the current speaker stops — keep the conversation orderly.

Watch the request/grant/ownership sequence:

The model's lesson: raise hand (HBUSREQ), get pointed to (HGRANT), take the mic when the current speaker stops (HREADY high). The grant reserves your turn; HREADY is when the turn actually begins. The gap between grant and ownership is the previous transfer finishing.

4. Real Hardware Perspective

In hardware, HBUSREQ and HGRANT connect masters to the arbiter, and the ownership-transfer timing is enforced by gating on HREADY.

Each master drives its HBUSREQ to the arbiter when it has a transfer to perform. The arbiter (the sequential logic from chapter 2.2) samples all the HBUSREQ inputs, applies its policy (priority, round-robin, anti-starvation), and asserts one HGRANT. The granted master sees its HGRANT high and prepares to drive, but it qualifies the takeover with HREADY: it only begins driving the address on a cycle where HGRANT is high and HREADY is high. This gating is what prevents the new master from colliding with the previous owner's in-progress transfer — the previous transfer completes (HREADY high), and on that same edge the bus passes to the granted master.

The arbiter typically grants ahead of time — it can assert HGRANT for the next master while the current master is still finishing, so the handover is seamless when HREADY goes high. This pipelined granting (decide the next owner during the current transfer) keeps the bus efficiently utilized: the moment the current transfer completes, the next owner is already chosen and can take over immediately. So HGRANT being high does not mean "drive now"; it means "you are the next owner, take over when the bus is free."

A hardware subtlety is the relationship to HLOCK/HMASTLOCK (chapters 3.11/3.13): a master can assert a lock request alongside its bus request, and the arbiter, honouring it, will keep granting that master (not regrant to another) for the locked sequence. So the arbitration handshake interacts with locking — the grant logic must hold the grant during a lock. And in legacy AHB, the handshake also interacts with SPLIT (chapter 3.13): a SPLIT-capable subordinate can cause the arbiter to temporarily de-grant a master and re-grant it later via HSPLIT. So HBUSREQ/HGRANT are the core of a richer arbitration system that locking and splitting plug into.

5. System Architecture Perspective

At the system level, HBUSREQ/HGRANT are where arbitration policy lives in action, and they determine the multi-master system's latency and fairness behaviour.

The arbiter's policy — decided in one place (chapter 2.2) — is expressed through HGRANT: which master gets granted, how often, and in what order is the policy in action. A priority scheme grants the high-priority master's HBUSREQ preferentially; a round-robin scheme cycles HGRANT among requesting masters; anti-starvation ensures every requesting master eventually gets a grant. So the system's multi-master latency and fairness characteristics are realized through the HBUSREQ/HGRANT handshake under the arbiter's policy. Tuning the policy tunes how grants are distributed, which is how the architect balances latency-sensitive masters against fairness — all visible at the HGRANT level.

The ownership-transfer-on-HREADY rule has a system-level efficiency consequence: because the arbiter can grant ahead and ownership transfers exactly at transfer boundaries, the bus moves between masters without idle re-arbitration cycles. This keeps multi-master throughput high — the bus is productively used right up to the handover and immediately after. A naive scheme that re-arbitrated only after a transfer fully completed (inserting an idle cycle to decide the next owner) would waste a cycle per ownership change; the grant-ahead pattern avoids that.

This is also where the AHB-Lite-plus-matrix contrast (chapter 2.7) matters at the system level. Modern systems largely do not use this in-protocol HBUSREQ/HGRANT arbitration; instead, each master is a single-master AHB-Lite manager, and a bus matrix handles arbitration per subordinate outside the protocol. So the HBUSREQ/HGRANT handshake is the classic full-AHB arbitration mechanism, important to understand, but largely replaced by matrix-level arbitration in contemporary designs — the same story as the other multi-master signals. Knowing this handshake explains how classic AHB arbitrated and clarifies what the bus matrix took over.

So at the system level, HBUSREQ/HGRANT are the live expression of arbitration policy and the mechanism for efficient ownership transfer in classic multi-master AHB — and a lens on what AHB-Lite-plus-matrix replaced.

6. Engineering Tradeoffs

The arbitration handshake reflects choices about how ownership is decided and transferred.

• Explicit request/grant vs implicit access. Requiring masters to request and be granted (rather than just driving) guarantees exactly one driver and clean ownership, at the cost of the handshake signalling and the arbiter logic. The alternative (masters driving freely) would corrupt the bus. The handshake is the price of safe multi-master sharing.
• Grant-ahead vs grant-after. Granting the next master during the current transfer (and transferring on HREADY) keeps the bus busy across handovers, at the cost of slightly more arbiter logic (deciding the next owner speculatively). Granting only after a transfer completes would be simpler but waste a cycle per ownership change. AHB favours grant-ahead for efficiency.
• Policy sophistication vs simplicity. A richer arbiter policy (weighted priority, anti-starvation, lock/split handling) gives better latency/fairness control but more complex grant logic; a simple fixed-priority arbiter is easy but can starve masters. The policy — expressed through HGRANT — trades sophistication for simplicity, tuned to the system's needs.
• In-protocol arbitration vs matrix arbitration. Carrying HBUSREQ/HGRANT in the protocol (full AHB) couples masters to a shared-bus arbiter; the AHB-Lite-plus-matrix approach moves arbitration into the interconnect, keeping masters simple. The trade is in-protocol arbitration versus the cleaner matrix factoring — resolved, in modern design, toward the matrix.

The through-line: HBUSREQ/HGRANT trade signalling and arbiter logic for safe, efficient, policy-driven ownership transfer among masters. The grant-ahead-plus-HREADY-transfer pattern is the efficiency highlight, and the in-protocol-vs-matrix choice is why this classic mechanism is largely superseded in modern AHB-Lite-based systems.

7. Industry Example

Trace a bus handover between two masters on a classic multi-master AHB.

A system has a processor (M1) and a DMA engine (M2) sharing the bus, with an arbiter.

• M2 requests while M1 owns the bus. M1 is mid-transfer (owns the bus). M2 (the DMA) has data to move, so it asserts HBUSREQ_2. The arbiter sees the request and, per its policy, decides M2 should go next.
• The arbiter grants ahead. While M1 is still finishing its transfer, the arbiter asserts HGRANT_2 — granting M2 before the bus is free. M2 sees its grant but does not drive yet, because HREADY is still low (M1's transfer is completing, perhaps with wait states).
• Ownership transfers on HREADY. When M1's transfer completes (HREADY high), the bus is free. On that cycle, with HGRANT_2 high and HREADY high, ownership transfers to M2, which begins driving its address. The handover happened exactly at the transfer boundary, with no collision and no wasted idle cycle (the grant was already decided).
• The collision that the rule prevents. Had M2 treated HGRANT_2 high as immediate ownership and started driving while M1's transfer was still completing (HREADY low), M2 would have collided with M1's in-progress transfer — two masters driving the bus, corruption. The HREADY-gated handover is exactly what prevents this.
• Policy in action. If the processor M1 needs low latency, the arbiter's policy grants M1 preferentially when both request; if fairness matters, it round-robins. Either way, the policy is expressed through which HGRANT it asserts and when. The handshake is how the policy becomes actual bus ownership.

The handover shows the full handshake: M2 requests (HBUSREQ), the arbiter grants ahead (HGRANT), and ownership transfers cleanly when the previous transfer completes (HREADY high). The grant-ahead pattern kept the bus busy, and the HREADY gating kept the handover collision-free.

8. Common Mistakes

9. Interview Insight

The arbitration handshake tests whether you understand that a grant is not ownership.

The answer that lands names the handshake and the timing rule: "Each master drives HBUSREQ to request the bus; the arbiter applies its policy and asserts a one-hot HGRANT to name the next owner. But the crucial point is that a grant is not ownership — the granted master takes the bus only when HGRANT is high and HREADY is high, so the previous owner's transfer has completed. The arbiter typically grants ahead, during the current transfer, so the handover is seamless on HREADY. These are full multi-master AHB; AHB-Lite drops them." The grant-is-not-ownership point and the HREADY gating are the senior signals.

10. Practice Challenge

Reason from the request/grant/own sequence and HREADY gating.

1. Name the handshake. State what HBUSREQ and HGRANT do and who drives each.
2. State the ownership rule. Give the exact condition under which a granted master takes the bus.
3. Read the waveform. In Figure 2, identify the cycle M2 is granted, the cycle it takes ownership, and why they differ.
4. Explain grant-ahead. In two sentences, explain why the arbiter grants the next master during the current transfer.
5. Diagnose handover corruption. A system corrupts on handovers, worse with wait states. Explain the grab-on-grant bug and the fix.

11. Key Takeaways

• HBUSREQ is a master's bus request; HGRANT is the arbiter's one-hot grant naming the next owner — the request/grant handshake that realizes arbitration.
• A grant is not ownership: ownership transfers only when HGRANT is high and HREADY is high, so the previous owner's transfer has completed and the bus is free.
• HREADY gates the handover to a clean transfer boundary, preventing collision with an in-progress transfer — the same HREADY-qualification discipline subordinates use.
• The arbiter grants ahead — deciding the next owner during the current transfer — so ownership transfers immediately on HREADY with no idle re-arbitration cycle.
• The handshake expresses arbitration policy (priority, round-robin, anti-starvation) and interacts with locking (HLOCK) and legacy SPLIT.
• Both are full multi-master AHB signals dropped by AHB-Lite; modern systems arbitrate in a bus matrix instead. The grab-on-grant collision (ignoring HREADY) is the classic bug.

12. What Comes Next

Two Module 3 chapters remain, covering the rest of the arbitration/advanced signalling:

• 3.13 — HSPLIT & HLOCK (coming next) — the split-capable subordinate's resume signalling and the master's lock request.
• 3.14 — HNONSEC & HEXCL (Variants) (coming soon) — the AHB5 security and exclusive-access sideband.

To revisit the arbiter that drives HGRANT and the locking it interacts with, see Master, Slave, Decoder & Arbiter and HMASTER & HMASTLOCK; for why AHB-Lite has none of this, see AHB-Lite Overview. For the broader protocol map, see the AMBA family overview.