HMASTER

Chapter 10.2 covered HBUSREQ/HGRANT — how the arbiter grants the bus to a master. But HGRANT goes only to the master. The rest of the system — slaves, the interconnect, protection logic — also needs to know which master currently owns the bus. That's what HMASTER provides: a small bus, driven by the arbiter, carrying the ID number of the master that currently owns the bus, broadcast to the fabric and slaves. It lets the system act on which master is making the current transfer. Its uses: a SPLIT-capable slave records HMASTER to know which master to call back (chapter 7.4); protection logic checks HMASTER against per-master access permissions; the interconnect uses it for routing or tracking. HMASTER follows the address-phase master (the data-phase master is a registered version, like other address-phase signals). So HMASTER is the master-identity signal the fabric needs — complementing HGRANT, which goes only to the master.

1. What Is It?

HMASTER is a small bus, driven by the arbiter, carrying the ID number of the master that currently owns the bus — broadcast to the fabric and slaves.

So HMASTER answers "which master is making this transfer?" — a question the fabric needs answered. The arbiter knows the granted master (it did the granting, chapter 10.2), so it drives HMASTER with that master's ID. The width of HMASTER depends on the number of masters (e.g., 4 bits for up to 16 masters). It's broadcast to slaves and the interconnect, so any component that needs to act on the master's identity can. HMASTER follows the address-phase master — it identifies the master whose address phase is current; because of the pipeline (chapter 5.2), the data-phase master is a registered (one-cycle-delayed) version of HMASTER, just like the other address-phase signals. So HMASTER is the address-phase master identity, with the data-phase identity being its registered version.

2. Why Does It Exist?

HMASTER exists because parts of the system need to know which master is making a transfer — for SPLIT, protection, and routing — and HGRANT (the grant signal) goes only to the master, not to the fabric. HMASTER broadcasts the master identity the fabric needs.

HGRANT tells the granted master it has the bus, but it's a point-to-point signal to that master — the slaves and interconnect don't see it (and even if they did, they'd have to decode which of the per-master HGRANTs is asserted). The fabric needs a direct statement of "the current master is N." HMASTER provides exactly that: the arbiter, which knows the granted master, broadcasts its ID. So HMASTER exists to make the current master's identity available to the fabric — a piece of information the fabric needs but HGRANT doesn't give it. It's the arbiter telling everyone (not just the master) who's driving.

The reason the fabric needs the master identity is the set of per-master functions:

SPLIT (chapter 7.4) needs it: a SPLIT-capable slave records HMASTER to know which master it split, so it can call that master back via HSPLIT. Protection needs it: per-master access permissions (which master may access which regions) require knowing which master is accessing — HMASTER provides the identity to check. The interconnect needs it: for routing or tracking which master is accessing which subordinate. So these functions all need the master identity, and HMASTER provides it. Without HMASTER, SPLIT couldn't identify the master, protection couldn't enforce per-master rules, and the interconnect couldn't track masters. So HMASTER exists to serve these per-master functions that need to know who's accessing.

The reason HMASTER follows the address-phase master (with a registered data-phase version) is consistency with the pipeline (chapter 5.2): HMASTER is an address-phase signal (like HADDR, HSIZE), identifying the master whose address phase is current. The data-phase functions (e.g., a SPLIT slave acting in the data phase) use the registered HMASTER (one cycle later), matching the data-phase timing of the other signals. So HMASTER's timing follows the same address-then-data pipeline as everything else — the address-phase master identity, registered for data-phase use. This consistency is why HMASTER integrates cleanly with the pipelined bus. So HMASTER exists with pipeline-consistent timing, providing the master identity at both the address-phase (directly) and data-phase (registered) points.

3. Mental Model

Model HMASTER as a "now serving" display showing which customer's number is being served — the staff (slaves, fabric) read the display to know whose order they're handling, even though the "you're up" call (HGRANT) went only to that customer.

At a service counter (the bus), customers (masters) take numbers and are called up (HGRANT — "customer 3, you're up"). But that call goes to the customer. The staff behind the counter (the slaves, the fabric) need to know whose order they're currently handling — so there's a "now serving" display showing the current customer's number (HMASTER). The staff read the display to know who they're serving: a clerk who needs to flag the customer for a callback later (SPLIT) notes their number from the display; a clerk checking the customer's permissions (protection) reads the number to look up their allowances; the back office tracking which customer is at which counter (interconnect) uses the display. So the "now serving" display broadcasts the current customer's identity to all the staff — which the individual "you're up" call (to the customer) doesn't do.

This captures HMASTER: the "you're up" call to the customer = HGRANT (to the master); the "now serving" display = HMASTER (broadcast to the fabric); the staff reading the display = slaves/protection/interconnect using HMASTER; noting the number for a callback = SPLIT recording HMASTER; checking permissions = protection. The display tells the staff who's being served — the identity the fabric needs.

Watch HMASTER track the granted master:

The model's lesson: HMASTER is the "now serving" display — it broadcasts the current master's ID to the fabric. In the waveform, HMASTER shows 0 (CPU) then 1 (DMA), tracking the granted master, so slaves and the interconnect always know who's driving. HGRANT told the master it was up; HMASTER tells the fabric.

4. Real Hardware Perspective

In hardware, HMASTER is driven by the arbiter (which knows the granted master) as a small bus to the fabric, and slaves/interconnect logic that needs the master identity reads it — with the data-phase identity being a registered version.

The arbiter drives HMASTER: having granted a master (chapter 10.2), the arbiter knows the current owner and encodes its ID on HMASTER. So HMASTER is an arbiter output, derived from the grant. Its width is ceil(log2(num_masters)) (e.g., 4 bits for up to 16 masters). The arbiter updates HMASTER as ownership changes (at handovers), so HMASTER always reflects the current address-phase master. In hardware, HMASTER is a small bus from the arbiter, encoding the granted master's number.

The consumers read HMASTER for their per-master functions. A SPLIT-capable slave latches HMASTER when it issues a SPLIT (recording which master, chapter 7.4) and later asserts that master's bit on HSPLIT. Protection logic (a protection unit, or a slave's access-control) uses HMASTER (with HPROT, HNONSEC) to check per-master permissions. The interconnect may use HMASTER for routing or tracking. So each consumer reads HMASTER to get the master identity it needs. In hardware, HMASTER fans out to these consumers, like other address-phase signals.

The registered data-phase version is a hardware detail matching the pipeline (chapter 5.2): HMASTER (like HADDR) is an address-phase signal; a consumer acting in the data phase (e.g., a SPLIT slave completing in the data phase) uses a registered HMASTER — the value from the previous (address-phase) cycle. So consumers register HMASTER if they act in the data phase, matching the data-phase timing of the other signals. This is the same address-then-data registering as the rest of the bus. So HMASTER's hardware timing is consistent: address-phase value broadcast, registered for data-phase use.

A hardware note on HMASTER vs HGRANT: they're complementary. HGRANT is per-master, point-to-point from the arbiter to each master (telling that master it's granted). HMASTER is a broadcast bus from the arbiter to the fabric (telling everyone the current master's ID). So HGRANT is for the masters (who's granted), HMASTER is for the fabric (who's current). A system needs both: HGRANT to control which master drives, HMASTER to tell the fabric who's driving. So in hardware, the arbiter drives both — per-master HGRANTs and the broadcast HMASTER — serving the masters and the fabric respectively. They're derived from the same grant decision but serve different audiences.

5. System Architecture Perspective

At the system level, HMASTER is the master-identity signal that enables per-master system functions — SPLIT, protection/security, and master-aware interconnect behavior — making the master's identity available to the components that must act on it.

The per-master functions HMASTER enables are significant. Protection and security are the most important: a system with per-master access control (which master may access which regions — common in secure systems) needs to know which master is accessing, and HMASTER provides it. So HMASTER underpins master-based protection: the protection logic checks HMASTER against the access rules. This is a security-relevant function — e.g., allowing a trusted master to access secure regions while denying others — which requires the master identity HMASTER carries. So HMASTER is part of the system's protection/security architecture.

The SPLIT support (chapter 7.4) is another function: in full AHB with SPLIT, slaves record HMASTER to identify the master to call back. So HMASTER is essential infrastructure for SPLIT — without the master identity, SPLIT couldn't work. (Since SPLIT is legacy, this use is mostly in full-AHB systems.) So HMASTER served the legacy SPLIT mechanism, providing the master identity it needed.

The interconnect/tracking use is increasingly relevant: in systems with interconnects, knowing which master is accessing (HMASTER) helps with routing, tracking, performance monitoring (which master is generating traffic), and debugging. So HMASTER provides master-attribution information useful at the system level — for understanding and managing multi-master traffic. So HMASTER's identity is used beyond the protocol mechanics, for system-level tracking and management. Overall, HMASTER is the signal that makes the master identity available system-wide, enabling protection (the key modern use), SPLIT (legacy), and tracking — the per-master functions that need to know who is accessing. As a system grows in masters and in the need for per-master control (protection, security, attribution), HMASTER's role grows correspondingly. So HMASTER is the foundation of master-aware system behavior in multi-master AHB.

6. Engineering Tradeoffs

HMASTER reflects the broadcast-the-master-identity design.

• Broadcast HMASTER vs per-master decode. Broadcasting the master ID on HMASTER lets any fabric component get the identity directly, at the cost of a small bus. The alternative (each component decoding the per-master HGRANTs) would duplicate logic and require routing all HGRANTs to the fabric. The broadcast HMASTER is cleaner.
• HMASTER (fabric) vs HGRANT (masters). Having two signals — HGRANT (per-master, to the masters) and HMASTER (broadcast, to the fabric) — cleanly serves the two audiences, at the cost of both signals. They carry related info (from the same grant) but to different consumers. Both are needed.
• Encoded ID vs one-hot. Encoding the master as an ID number (HMASTER) is compact (log2 bits) vs a one-hot per-master signal. The encoded form suits a broadcast identity. (HGRANT is effectively per-master one-hot, suiting the per-master grant.)
• Pipeline-consistent timing. Making HMASTER an address-phase signal (with a registered data-phase version) matches the rest of the bus, at the cost that data-phase consumers must register it. The consistency is worth it — HMASTER integrates like other address-phase signals.

The throughline: HMASTER is a small bus, driven by the arbiter, broadcasting the current master's ID to the fabric — complementing HGRANT (which goes only to the master). It provides the master identity that per-master functions need: SPLIT (record which master to call back), protection (per-master permissions — the key modern use), and interconnect routing/tracking. It follows the address-phase master (registered for data-phase use), integrating with the pipeline. HMASTER is the foundation of master-aware system behavior — making who is accessing available to the components that must act on it.

7. Industry Example

Trace HMASTER's uses in a multi-master system.

A system has a CPU (master 0), a DMA (master 1), and a secure peripheral with per-master access control.

• HMASTER tracks the owner. As the arbiter grants the CPU then the DMA, HMASTER reflects the current owner — 0 (CPU) or 1 (DMA). The fabric reads HMASTER to know which master is making each transfer. So at any moment, the slaves and interconnect know the accessing master's ID.
• Per-master protection. The secure peripheral allows access only by the CPU (master 0), not the DMA (master 1) — a per-master access rule. Its protection logic reads HMASTER on each access: if HMASTER = 0 (CPU), allow; if HMASTER = 1 (DMA), deny (return ERROR). So HMASTER is what lets the peripheral enforce the per-master rule — it identifies the accessing master. Without HMASTER, the peripheral couldn't tell the CPU's access from the DMA's. This is a security function: HMASTER enables master-based access control.
• SPLIT recording (full AHB). If a slave issues a SPLIT to the DMA (in a full-AHB system), it records HMASTER = 1 (the DMA's ID) so it knows to call the DMA back via HSPLIT later. So HMASTER provides the master identity SPLIT needs (chapter 7.4).
• Interconnect tracking. The interconnect (or a performance monitor) uses HMASTER to track which master is generating traffic to which subordinate — useful for performance analysis and debugging (e.g., "the DMA is saturating the memory port"). So HMASTER provides master-attribution for system monitoring.
• The registered data-phase version. When the secure peripheral checks the access, it must use HMASTER consistent with the access's phase: if it checks in the data phase, it uses the registered HMASTER (the value from the address phase, one cycle earlier), matching the pipeline. Using the wrong HMASTER would check the wrong master's permissions. So the peripheral registers HMASTER appropriately.

The example shows HMASTER's uses: tracking the owner (so the fabric knows who's accessing), per-master protection (the secure peripheral checks HMASTER to allow the CPU and deny the DMA — a security function), SPLIT recording (which master to call back), and interconnect tracking (master attribution). HMASTER is the master-identity signal these per-master functions need, with pipeline-consistent timing (registered for data-phase use).

8. Common Mistakes

9. Interview Insight

HMASTER is a moderate interview topic — its role (broadcasting the master ID to the fabric) and uses (protection, SPLIT) are the signals.

The answer that lands explains the role and uses: "HMASTER is a small bus driven by the arbiter, carrying the ID number of the master that currently owns the bus, broadcast to the fabric and slaves. The key insight is that HGRANT — the grant signal — goes only to the master (point-to-point), so it doesn't tell the fabric who's current; HMASTER fills that gap, broadcasting the current master's identity to everyone who needs it. Its main uses are: per-master protection or security — checking HMASTER against access permissions to allow or deny based on which master is accessing, which is the key modern use; SPLIT support — a SPLIT-capable slave records HMASTER to know which master to call back via HSPLIT; and interconnect routing or tracking — knowing which master is generating which traffic. HMASTER follows the address-phase master, so a data-phase consumer uses the registered version, one cycle later, matching the pipeline. So HMASTER and HGRANT are complementary — HGRANT controls which master drives, HMASTER tells the fabric who's driving." The role (broadcast to the fabric vs HGRANT to the master), the uses (protection, SPLIT, tracking), and the pipeline timing are the senior signals.

10. Practice Challenge

Reason from HMASTER's role.

1. Define it. Explain what HMASTER is and what it carries.
2. HMASTER vs HGRANT. Explain why HMASTER is needed in addition to HGRANT.
3. Read the waveform. From Figure 3, explain how HMASTER tracks the owner.
4. Protection use. Explain how HMASTER enables per-master access control.
5. Pipeline timing. Explain why a data-phase consumer uses the registered HMASTER.

11. Key Takeaways

• HMASTER is a small bus, driven by the arbiter, carrying the ID of the current bus owner — broadcast to the fabric and slaves.
• It complements HGRANT — HGRANT goes only to the master (who's granted); HMASTER tells the fabric who's current. Different audiences.
• Its uses: per-master protection/security (check HMASTER against access permissions — the key modern use), SPLIT (record which master to call back — legacy), and interconnect routing/tracking (master attribution).
• It follows the address-phase master — a data-phase consumer uses the registered HMASTER (one cycle later), matching the pipeline.
• It's encoded (the master's ID number, log2 bits) and broadcast — versus HGRANT's per-master one-hot grant.
• HMASTER is the foundation of master-aware system behavior — making which master is accessing available to the components (protection, SPLIT, interconnect) that must act on it.

12. What Comes Next

You now understand the core arbitration signals (HBUSREQ/HGRANT/HMASTER). The next chapters cover locked transfers and the arbitration policies:

• 10.4 — Locked Transfers (HLOCK) (coming next) — locked sequences that prevent arbitration mid-transaction.
• 10.5 / 10.6 (coming soon) — fixed-priority and round-robin arbitration policies.

To revisit the grant handshake, see HBUSREQ & HGRANT; for why arbitration exists, Why Arbitration Exists. For SPLIT, which uses HMASTER, see SPLIT Response. For the broader protocol map, see the AMBA family overview.