HMASTER & HMASTLOCK

This chapter begins the multi-master signals — the part of full AHB that exists only because multiple managers share the bus, and which AHB-Lite largely drops (chapter 2.7). We cover HMASTER, which identifies the master currently granted the bus, and HMASTLOCK, which marks a transfer as part of a locked, indivisible sequence — the mechanism behind atomic operations like semaphores. These signals are rated Advanced and are most relevant to full multi-master AHB; understanding them rounds out the signal set and explains how AHB supports atomicity. We give each signal's role, the atomic-sequence mechanism, and the AHB-Lite relationship.

1. What Is It?

These are two multi-master sideband signals:

• HMASTER carries the number (ID) of the master currently granted the bus. It is driven by the arbiter (the block that grants the bus) so that subordinates and bus monitors know which master is performing the current access.
• HMASTLOCK indicates that the current transfer is part of a locked sequence — an indivisible (atomic) group of transfers that must not be interrupted by another master. When HMASTLOCK is high, the arbiter must not regrant the bus to a different master until the lock releases.

The framing to hold: these signals exist because there is more than one master. HMASTER answers "which master is this?" — meaningless if there is only one. HMASTLOCK answers "must this group of transfers be kept atomic against other masters?" — also a multi-master concern. In a single-master AHB-Lite system, HMASTER is dropped entirely (there is only one master), and the locking concept is simplified. So this chapter is really about full multi-master AHB, the world AHB-Lite-plus-bus-matrix largely replaced.

2. Why Does It Exist?

Each signal exists to solve a specific multi-master problem.

Why HMASTER. When multiple masters share a bus, some logic needs to know which master is performing a given access. The most important consumer historically was a SPLIT-capable subordinate: when a subordinate SPLITs a transfer (defers it and releases the bus), it must remember which master to resume later, and it identifies that master by HMASTER. More broadly, bus monitors, performance counters, and protection logic may want to attribute accesses to masters — for debugging ("which master accessed this?"), for per-master statistics, or for per-master protection. HMASTER is the signal that carries the master's identity along with the access, so any logic that cares who is doing the access can know. With a single master, there is nothing to identify, so HMASTER is unnecessary.

Why HMASTLOCK. Multi-master systems need atomic operations — sequences of accesses that must complete without another master interfering. The classic example is a semaphore (or mutex): to acquire a lock, a master reads the semaphore, checks if it is free, and if so writes to claim it. If another master could read the semaphore between this master's read and write, both masters might see it free and both claim it — a race that breaks mutual exclusion. To prevent this, the master performs the read and write as a locked sequence, asserting HMASTLOCK, and the arbiter guarantees no other master is granted the bus during the lock. HMASTLOCK exists to make such indivisible read-modify-write sequences possible — the foundation of inter-master synchronization. With a single master, there is no other master to race against, so locking is far less important (though the concept can still mark indivisible sequences).

So both signals exist because multiple masters create problems a single master never has: the need to identify the active master (HMASTER) and the need to protect a sequence from interleaving by other masters (HMASTLOCK). They are the bus's support for multi-master identity and atomicity, and they are precisely the kind of machinery AHB-Lite sheds by assuming one master.

3. Mental Model

Model HMASTLOCK as putting an "occupied — do not disturb" sign on a shared room while you do something that must not be interrupted.

Several people (masters) share a room (the bus), taking turns via a scheduler (the arbiter). Usually the scheduler can give the room to whoever is next between any two uses. But sometimes you need to do a two-step task that must not be interrupted — read a shared ledger, then write your claim to it — and if someone else used the room in between, they might claim the same thing. So you hang an "occupied — do not disturb" sign (HMASTLOCK): the scheduler will not give the room to anyone else until you take the sign down. Your read and write happen back-to-back with no one able to slip in between. HMASTER, meanwhile, is simply the name tag showing who is currently in the room — so anyone watching knows whose access this is.

Watch a locked read-modify-write sequence:

The model's lesson: HMASTLOCK is the "do not disturb" sign that makes a multi-step sequence atomic against other masters, and HMASTER is the name tag of whoever currently holds the room. The arbiter honours the sign by not regranting during the lock.

4. Real Hardware Perspective

In hardware, HMASTER is driven by the arbiter and HMASTLOCK couples the master's intent to the arbiter's grant behaviour.

HMASTER is an output of the arbiter: since the arbiter decides which master is granted, it knows the current master's ID and drives it on HMASTER for the rest of the system to observe. A SPLIT-capable subordinate latches HMASTER when it SPLITs a transfer, so it can later tell the arbiter to re-grant that specific master when the data is ready. Monitors and protection logic read HMASTER to attribute the access. The width of HMASTER accommodates the number of masters (e.g., 4 bits for up to 16). In a single-master AHB-Lite system there is no arbiter choosing among masters, so HMASTER does not exist.

HMASTLOCK couples a master's locking intent to the arbiter. A master that wants an atomic sequence asserts a lock request (HLOCK, covered in a later chapter) ahead of the sequence, and the arbiter responds by asserting HMASTLOCK during the locked transfers and — crucially — by not regranting the bus to another master until the lock is released. So HMASTLOCK is the arbiter-level reflection of the master's lock request, and the arbiter's grant logic must honour it: hold the grant on the locking master for the whole locked sequence. This is how the hardware guarantees no other master interleaves: the arbiter simply refuses to switch masters while HMASTLOCK is asserted.

The hardware subtlety is that locking constrains arbitration: a locked sequence by one master delays all others (they cannot be granted until the lock releases), which is a latency cost. So locked sequences are kept short (typically just the read and write of an atomic operation) to minimize how long other masters are blocked. A master that held the lock too long would starve the others — so locking, like long bursts, trades atomicity for others' latency, and is used sparingly for exactly the sequences that need it.

5. System Architecture Perspective

At the system level, HMASTER and HMASTLOCK support two important multi-master capabilities: per-master attribution/security and atomic synchronization — both of which matter in systems with several masters and shared resources.

Per-master attribution (HMASTER). In a multi-master system, being able to attribute an access to a specific master enables several system features: a protection scheme can enforce per-master access rights (master A may access region X, master B may not); a debug/trace system can record which master made each access; performance monitors can count per-master bandwidth. HMASTER is the signal that makes this attribution possible at the bus level. In modern systems this concept evolved — AHB5 and related architectures carry richer master/security identity — but HMASTER is the classic mechanism for "which master is this?" at the system level.

Atomic synchronization (HMASTLOCK). Multi-master systems with shared data structures need synchronization primitives — semaphores, mutexes, locks — to coordinate access, and these are built on atomic read-modify-write operations. HMASTLOCK is the bus-level support for those atomics: it lets a master perform an indivisible read-then-write that other masters cannot interrupt, which is exactly what a semaphore acquire requires. So HMASTLOCK connects the bus protocol to the software-level world of locks and mutexes — the inter-master synchronization that multi-master systems depend on. Without a bus-level atomic mechanism, software could not safely coordinate multiple masters sharing memory.

The AHB-Lite contrast. As established in chapter 2.7, modern systems are largely built from AHB-Lite managers plus a bus matrix, not full multi-master AHB. In that world, HMASTER (master identity for the shared-bus arbiter) is not part of the single-master AHB-Lite interface — the matrix and its arbitration handle multi-master concerns outside the protocol. Atomicity in such systems is handled by other mechanisms (exclusive-access monitors, the AHB5 exclusive-access signals covered later, or matrix-level support) rather than the classic HMASTLOCK-holds-the-arbiter approach. So at the system level, HMASTER and HMASTLOCK are best understood as the classic full-AHB answers to identity and atomicity — important to know, but partly superseded by the AHB-Lite-plus-matrix and AHB5 mechanisms in modern designs.

So these signals are the full-AHB system's support for knowing who is accessing and for atomic synchronization — central to classic multi-master AHB, and a useful lens on how those concerns are handled (differently) in the AHB-Lite-based systems that dominate today.

6. Engineering Tradeoffs

The multi-master signals embody tradeoffs around identity and atomicity.

• Carrying master identity vs not. HMASTER lets the system attribute accesses (for SPLIT, protection, debug, performance) at the cost of extra bus signalling and the arbiter driving it. A system that does not need attribution (or has one master) does not need HMASTER. The trade is attribution capability versus signalling cost — and single-master AHB-Lite simply drops it.
• Locking for atomicity vs others' latency. HMASTLOCK enables atomic sequences (essential for synchronization) but blocks all other masters for the lock's duration, hurting their latency. The trade is atomicity versus fairness/latency, managed by keeping locked sequences short. A long lock would starve other masters, so locking is used only for genuinely atomic operations.
• In-protocol locking (HMASTLOCK) vs out-of-band atomics. Classic AHB builds atomicity into arbitration (the arbiter holds the grant during HMASTLOCK), which is simple but couples atomicity to the arbiter and blocks the whole bus. Modern approaches (exclusive-access monitors) achieve atomicity without holding the bus, allowing other masters to proceed — more concurrency at more complexity. The trade is simplicity (lock the bus) versus concurrency (exclusive monitors), and the industry trended toward the latter for performance.
• Full multi-master AHB vs AHB-Lite + matrix. Carrying HMASTER/HMASTLOCK is part of full AHB's in-protocol multi-master support, which (chapter 2.7) is largely superseded by AHB-Lite plus a bus matrix. The trade is in-protocol multi-master machinery versus the cleaner factoring of simple masters plus a matrix — resolved, in modern design, toward the latter.

The through-line: HMASTER and HMASTLOCK are full-AHB's answers to multi-master identity and atomicity, each trading capability for cost (signalling, blocked latency, arbiter coupling). They are important classic mechanisms, but modern systems often achieve the same goals through bus matrices and exclusive-access monitors, which is why these signals feel like "advanced/legacy" full-AHB territory.

7. Industry Example

Trace a semaphore acquire on a classic multi-master AHB, then contrast with a modern approach.

A system has two processors (masters M1 and M2) sharing memory, coordinating via a semaphore.

• M1 acquires the semaphore (locked). M1 wants exclusive access to a shared resource. It performs an atomic read-modify-write on the semaphore: it asserts its lock request, the arbiter asserts HMASTLOCK and holds the grant on M1, and HMASTER shows M1. M1 reads the semaphore (free), then writes to claim it — back to back, with HMASTLOCK high across both. The arbiter does not grant the bus to M2 during this sequence, so M2 cannot read the semaphore in between. M1's acquire is atomic; it now owns the resource. HMASTLOCK drops, and the arbiter may grant M2.
• The race that locking prevents. Without HMASTLOCK, after M1 read the semaphore (free) but before M1 wrote to claim it, the arbiter could grant M2, which reads the same semaphore (still free, M1 has not written yet) and also claims it. Both processors believe they own the resource — a classic synchronization bug. HMASTLOCK prevents exactly this by keeping the bus on M1 across the read-modify-write.
• HMASTER's role for a SPLIT slave. Suppose the shared memory were a SPLIT-capable subordinate. If it SPLIT one of M1's accesses, it would latch HMASTER = M1 so it could later signal the arbiter to re-grant M1 specifically when the data was ready. HMASTER carries the identity needed to resume the right master.
• The modern contrast. In a contemporary AHB-Lite-plus-matrix or AHB5 system, this atomicity would more likely be handled by an exclusive-access mechanism (an exclusive monitor that detects whether another master touched the location between an exclusive read and write) rather than by holding the bus with HMASTLOCK. That allows M2 to use the bus for other locations during M1's atomic sequence, improving concurrency. Same goal (atomic semaphore), different mechanism — illustrating how the classic HMASTLOCK approach was superseded.

The semaphore acquire shows HMASTLOCK doing its essential job — making a read-modify-write atomic against another master — and HMASTER carrying the identity that multi-master features need. The modern-contrast point shows why these are "classic" mechanisms that newer designs often replace.

8. Common Mistakes

9. Interview Insight

These signals test whether you understand multi-master concerns and atomicity — and the AHB-Lite contrast.

The answer that lands names both roles and connects HMASTLOCK to atomicity: "HMASTER carries the ID of the master currently granted the bus, driven by the arbiter, so subordinates and monitors know which master is accessing — used by SPLIT-capable slaves to track which master to resume. HMASTLOCK marks a transfer as part of a locked, indivisible sequence: the arbiter won't regrant the bus until the lock releases, which is how AHB does atomic read-modify-write for semaphores. Both are full multi-master AHB; AHB-Lite drops HMASTER since it has one master." Connecting HMASTLOCK to atomic semaphores, and noting the AHB-Lite drop, are the senior signals.

10. Practice Challenge

Reason from multi-master identity and atomicity.

1. State the roles. Define HMASTER and HMASTLOCK in one line each, and say who drives each.
2. Explain the atomicity. In three sentences, explain how HMASTLOCK makes a semaphore acquire atomic and the race it prevents.
3. Distinguish request vs grant. Contrast HLOCK and HMASTLOCK.
4. Justify the AHB-Lite drop. Explain why HMASTER is unnecessary in AHB-Lite.
5. Diagnose the hang. A multi-master system hangs with one master holding the bus. Explain how HMASTLOCK could cause it and how exclusive-access monitors avoid the problem.

11. Key Takeaways

• HMASTER carries the current granted master's ID, driven by the arbiter, so subordinates and monitors know which master is accessing — used by SPLIT-capable subordinates, per-master protection, and debug.
• HMASTLOCK marks a locked, indivisible sequence — the arbiter must not regrant the bus until the lock releases, enabling atomic read-modify-write.
• HMASTLOCK is how classic AHB does atomic operations like semaphores, preventing another master from interleaving between an atomic read and write.
• HLOCK (master's request) vs HMASTLOCK (arbiter's granted-lock indication) are distinct — request versus the lock in effect.
• Both are full multi-master AHB signals; AHB-Lite drops HMASTER (one master) and handles atomicity differently.
• Locking blocks other masters, so locked sequences must be short; modern designs often prefer non-blocking exclusive-access monitors (AHB5) over bus-holding locks for atomicity.

12. What Comes Next

These signals begin the multi-master set. The remaining Module 3 chapters cover the rest of the arbitration and advanced signalling:

• 3.12 — HGRANT & HBUSREQ (coming next) — the bus-request / bus-grant arbitration handshake between masters and the arbiter.
• 3.13 — HSPLIT & HLOCK (coming soon) — split-capable subordinate signalling and the master lock request.

To revisit why these multi-master signals are absent from the dominant form of AHB, see AHB-Lite Overview and Master, Slave, Decoder & Arbiter. For the broader protocol map, see the AMBA family overview.