HNONSEC & HEXCL (Variants)

This chapter closes the AHB Signal Deep Dive with the AHB5 additions — the signals that modernized AHB for secure, multi-master systems. HNONSEC carries a security state (secure vs non-secure) for TrustZone-style isolation, and the exclusive-access signals (HEXCL / HEXOKAY) provide atomicity without holding the bus — the modern replacement for the HMASTLOCK bus-locking we met in chapter 3.11. These are the newest, most forward-looking signals in the set, and they reflect how AHB evolved to meet security and concurrency demands. We cover each, the exclusive-access mechanism in detail, and how they relate to the classic mechanisms they supersede.

1. What Is It?

AHB5 added two capabilities via sideband signals:

• HNONSEC is a security bit: it indicates whether an access is non-secure (1) or secure (0). A firewall (filter) in the system uses it to enforce that non-secure accesses cannot reach secure regions — the foundation of TrustZone-style security on AHB.
• Exclusive access uses HEXCL (a master output marking an access as exclusive) and HEXOKAY (a response indicating whether an exclusive write succeeded). Together they let a master perform an atomic read-modify-write without holding the bus: an exclusive read followed by an exclusive write that succeeds only if no other master touched the location in between.

The framing: these are AHB5 modernizations addressing two needs that the classic signal set handled poorly or not at all — security (HNONSEC, for secure/non-secure separation) and non-blocking atomicity (exclusive access, replacing bus-holding locks). They are "variants" in the sense of being later additions/options, but they are central to how AHB is used in modern secure SoCs. Understanding them completes the signal picture and shows where AHB is headed.

2. Why Does It Exist?

Each addition answers a need that emerged as systems grew more secure and more concurrent.

Why HNONSEC. Modern SoCs run trusted (secure) and untrusted (non-secure) software, and must guarantee that untrusted code cannot access secure resources — secure keys, trusted memory, secure peripherals. This requires the bus to carry the security state of each access so that a firewall can enforce the separation: a non-secure access to a secure region must be blocked. HNONSEC is that security state on the bus. The classic AHB signals (even HPROT's privilege bit) did not express secure-vs-non-secure as a distinct dimension; HNONSEC adds it, enabling TrustZone-style two-world security on AHB. So HNONSEC exists because security isolation became a first-class requirement, and the bus needed to carry the secure/non-secure distinction to enforce it.

Why exclusive access (HEXCL/HEXOKAY). As discussed in chapter 3.11, the classic way to do atomic read-modify-write was HMASTLOCK — hold the bus across the sequence so no other master interleaves. But that blocks every other master for the lock's duration, hurting concurrency and risking starvation. Exclusive access solves atomicity differently: instead of preventing interference by locking, it detects interference and retries. A master does an exclusive read (recorded by an exclusive monitor), and later an exclusive write; the monitor checks whether the location was modified by anyone else since the read. If not, the write succeeds (HEXOKAY) — the operation was atomic. If it was, the write fails and the master retries the whole sequence. Crucially, the bus is never held — other masters use it freely throughout — so atomicity costs no concurrency. Exclusive access exists to provide atomicity without the blocking cost of bus-locking, which matters increasingly as systems have more masters that must not be starved.

So these signals exist because modern systems demanded security isolation (HNONSEC) and non-blocking atomicity (exclusive access) — needs the classic AHB signal set did not meet. AHB5 added them to keep AHB viable in secure, concurrent SoCs.

3. Mental Model

Model the two additions as a security clearance on your badge (HNONSEC) and an optimistic "did anyone touch this?" check (exclusive access).

HNONSEC is like a clearance level on your badge. Every time you try to enter a room (access a region), a guard (firewall) checks your badge: if you are "non-secure" and the room is "secure," you are turned away. The badge travels with you on every access, and the guard enforces the rule. This is two-world security: secure rooms for cleared personnel only.

Exclusive access is like leaving a sticky note on a shared document and checking it before you commit your edit. You read the document and put a note: "I'm about to edit this." You go do other things (the bus is free for others). When you come back to write your edit, you check: did anyone else edit the document since your note? If not, you commit — your edit was effectively atomic. If someone did, you abandon your edit and start over (re-read, re-check). You never locked the document (others could read and even edit it); you just detected whether your assumption held. That is optimistic, non-blocking atomicity.

Watch an exclusive read-write pair:

The model's lesson: HNONSEC is a clearance the firewall checks on every access; exclusive access is optimistic atomicity — read, do other things, then write only if nothing interfered, never holding the bus. Atomicity by detection-and-retry, not by locking.

4. Real Hardware Perspective

In hardware, HNONSEC feeds a firewall, and exclusive access relies on an exclusive monitor — both lightweight compared to the mechanisms they augment or replace.

HNONSEC is a master output (driven from the processor's security state) carried with the access. A firewall (security filter), placed in the interconnect or in front of secure subordinates, decodes HNONSEC together with the address: if a non-secure access (HNONSEC=1) targets a secure region, the firewall blocks it — typically returning an ERROR response (chapter 3.9). So HNONSEC plus a firewall implement secure/non-secure access control at the bus level, analogous to how HPROT[1] plus a protection unit implement privilege control (chapter 3.6) — but for the secure/non-secure dimension specifically. The processor drives HNONSEC according to which security world it is executing in, and the firewall enforces the boundary.

Exclusive access relies on an exclusive monitor — logic that tracks exclusive-read addresses and watches for intervening writes. The sequence:

• A master issues an exclusive read (HEXCL asserted). The monitor records the address (and the master) as having an outstanding exclusive operation.
• Other accesses proceed normally; the monitor watches whether any write hits the recorded address.
• The master issues an exclusive write (HEXCL asserted) to the same address. The monitor checks: was the address written by anyone since the exclusive read? If no, the write is allowed and HEXOKAY is asserted (success). If yes, the write is not committed and HEXOKAY is not asserted (fail) — the master must retry the whole exclusive sequence.

The hardware beauty is that this needs only a small monitor (tracking a few exclusive addresses), not the bus-holding arbitration machinery of HMASTLOCK. Other masters are never blocked — they use the bus freely during the exclusive sequence — so atomicity costs no concurrency. The price is that the exclusive write can fail (if interfered with), so the master must be prepared to retry; but failures only happen under actual contention, which is rare, so the common case is fast and non-blocking. This detect-and-retry approach is exactly the modern alternative to bus-locking that chapters 3.11 and 3.13 referenced.

5. System Architecture Perspective

At the system level, HNONSEC and exclusive access are how AHB participates in two major modern-SoC concerns: hardware security and scalable synchronization.

HNONSEC and system security. Hardware-enforced security (TrustZone-style) partitions the system into a secure world (trusted firmware, secure keys, secure peripherals) and a non-secure world (the rich OS and applications), with hardware guaranteeing the non-secure world cannot reach secure resources. HNONSEC is the bus-level carrier of this partition: every access is tagged secure or non-secure, and firewalls throughout the system enforce that non-secure accesses stay out of secure regions. So HNONSEC connects AHB to the system's security architecture — without it, AHB could not participate in hardware-enforced isolation. In secure SoCs (which is most modern ones), HNONSEC and its firewalls are essential, not optional. This is the security dimension HPROT alone could not provide.

Exclusive access and scalable synchronization. As systems gain more masters (multi-core, many DMA engines, accelerators), synchronization that blocks the bus (HMASTLOCK) scales poorly — every atomic operation stalls all other masters. Exclusive access provides synchronization that scales: many masters can perform atomic operations concurrently (on different locations) without blocking each other, because atomicity is per-location detection, not bus-wide locking. So exclusive access is how AHB supports synchronization in systems with many masters, where bus-holding locks would be a bottleneck. It maps directly to the load-linked/store-conditional primitives that modern processors use for lock-free and lock-based synchronization, so it connects the bus to the software's concurrency primitives.

The evolution completed. These AHB5 additions complete the arc this module has traced: classic AHB had bus-locking (HMASTLOCK) for atomicity and HPROT for basic protection; AHB5 added non-blocking exclusive access for scalable atomicity and HNONSEC for security-world isolation. Together with the AHB-Lite-plus-matrix structural evolution (chapter 2.7), they show AHB modernizing to meet the security and concurrency demands of contemporary SoCs while keeping its simple, synchronous core. So at the system level, HNONSEC and exclusive access are AHB's answers to the two defining concerns of modern SoC design — security and scalable concurrency — and they are where the protocol stays relevant in current designs.

6. Engineering Tradeoffs

The AHB5 additions reflect choices about security and atomicity mechanisms.

• Security on the bus (HNONSEC) vs out-of-band. Carrying the security state per access (HNONSEC) lets firewalls enforce isolation precisely at the bus, at the cost of an extra signal and firewall logic. The alternative — out-of-band security — would be less precise and harder to enforce per access. AHB5 puts security on the bus for precise, per-access enforcement.
• Exclusive (non-blocking) vs locking (blocking) atomicity. Exclusive access gives atomicity without blocking other masters, scaling far better, at the cost of possible retry under contention and the monitor logic. Bus-locking (HMASTLOCK) never retries but blocks everyone. For systems with many masters, non-blocking wins decisively; for trivial systems, locking is simpler. AHB5 added exclusive access because concurrency demands grew.
• Optimistic retry vs guaranteed first-try success. Exclusive access is optimistic — the write may fail and need a retry if another master interfered. This is excellent when contention is rare (the common case) but requires the master to handle retries. A locking approach guarantees first-try success at the cost of blocking. The trade is occasional-retry-with-no-blocking versus never-retry-but-always-blocking; the former scales better.
• Adding signals (AHB5) vs protocol stability. Extending AHB with HNONSEC and exclusive-access signals keeps it relevant for modern systems but adds to the signal set and requires IP to support the extensions. AHB5 judged the security and atomicity needs worth the additions. Systems that do not need them can omit them (they are options).

The through-line: HNONSEC and exclusive access trade extra signals and (for exclusive) occasional retries for precise bus-level security and non-blocking, scalable atomicity — modernizations that keep AHB viable in secure, many-master SoCs. The non-blocking-atomicity choice in particular reflects the same concurrency-over-blocking preference seen throughout the bus's evolution.

7. Industry Example

Trace HNONSEC and exclusive access in a modern secure, multi-core SoC.

• A non-secure access blocked (HNONSEC). The rich OS (non-secure world) attempts to read a secure key-storage peripheral. The processor drives HNONSEC=1 (non-secure). The firewall in front of the secure peripheral decodes HNONSEC and the address, sees a non-secure access to a secure region, and blocks it, returning an ERROR. The secure key is protected from non-secure software — hardware-enforced isolation, realized through HNONSEC and the firewall.
• A secure access allowed. Trusted firmware (secure world) reads the same key peripheral, driving HNONSEC=0 (secure). The firewall sees a secure access to a secure region and allows it. The same peripheral is accessible to secure software and blocked from non-secure — the two-world model.
• An atomic counter increment (exclusive access). Two cores share a counter and must increment it atomically. Core A does an exclusive read of the counter (monitor records it), computes counter+1, and does an exclusive write. If core B did not touch the counter in between, A's write succeeds (HEXOKAY) and the increment was atomic. If core B did increment it in between, A's exclusive write fails, and A retries — re-reads (now seeing B's value), recomputes, and writes again. Crucially, throughout A's sequence, the bus was never held — core B (and every other master) used it freely. Atomicity without blocking.
• The contrast with HMASTLOCK. Had this used the classic HMASTLOCK approach, core A would have locked the bus across its read-modify-write, blocking core B (and all masters) for the duration — even though B wanted a different resource. Exclusive access blocks no one; only A's own write might retry, and only under actual contention on that exact counter. In a many-core system doing frequent atomics, this difference is the difference between scaling and bottlenecking.

The secure-access enforcement and the lock-free atomic increment show the AHB5 additions doing their modern jobs: HNONSEC enforcing security-world isolation, and exclusive access providing scalable, non-blocking atomicity that bus-locking could not.

8. Common Mistakes

9. Interview Insight

The AHB5 additions test awareness of modern security and lock-free atomicity.

The answer that lands explains both and the lock-free insight: "AHB5 added HNONSEC, a security bit — non-secure versus secure — that a firewall uses to keep non-secure accesses out of secure regions, enabling TrustZone-style isolation. And it added exclusive access via HEXCL and HEXOKAY: a master does an exclusive read then an exclusive write, and the write succeeds only if no other master touched the location in between, with the monitor reporting success on HEXOKAY. The key point is that this gives atomicity without holding the bus — other masters run freely, and only the exclusive write might retry under contention — which is why it replaced the bus-locking HMASTLOCK approach." The non-blocking-atomicity insight is the senior signal.

10. Practice Challenge

Reason from the security and lock-free-atomicity mechanisms.

1. Define both. State what HNONSEC and the exclusive-access signals (HEXCL/HEXOKAY) do.
2. Trace a block. Walk a non-secure access to a secure region through HNONSEC and the firewall.
3. Trace an atomic op. Walk an exclusive read-modify-write that succeeds, and one that fails and retries.
4. Contrast with locking. Explain why exclusive access scales better than HMASTLOCK for many masters.
5. Distinguish the dimensions. Explain the difference between HNONSEC (security) and HPROT[1] (privilege).

11. Key Takeaways

• HNONSEC is the AHB5 security bit — non-secure (1) versus secure (0) — used by a firewall to keep non-secure accesses out of secure regions, enabling TrustZone-style two-world security.
• HNONSEC is a separate dimension from HPROT's privilege bit — security (secure/non-secure) versus privilege (user/privileged); a system can use both.
• Exclusive access (HEXCL/HEXOKAY) provides atomic read-modify-write without holding the bus — an exclusive read and write where the write succeeds (HEXOKAY) only if no other master touched the location in between.
• It is lock-free and optimistic: detect interference and retry, rather than lock and hold. The bus is never held, so other masters are never blocked.
• Exclusive access replaced HMASTLOCK bus-locking because it scales to many masters; software must handle the possible exclusive-write failure with a retry (load-linked/store-conditional pattern).
• These AHB5 additions modernized AHB for secure, many-master SoCs — security isolation and scalable atomicity — completing the protocol's evolution alongside the AHB-Lite-plus-matrix structural change.

12. What Comes Next

This completes Module 3 — the AHB Signal Deep Dive. You now know every AHB signal: the global clock/reset, the address-phase controls, the data buses, the handshake, the response and select, the multi-master arbitration signals, and the AHB5 security and exclusive-access additions. With the full signal vocabulary in hand, the remaining modules turn to applying it — transfer-type and burst behaviour in depth, arbitration and multi-master systems, the AHB-to-APB bridge, the bus matrix, RTL design, verification, and debugging.

• Module 4 onward (coming next) — applying the signals: deeper transfer behaviour, multi-master systems, bridges, the bus matrix, and the design/verification practice that builds on this foundation.

To revisit the classic atomicity and security mechanisms these AHB5 signals modernize, see HMASTER & HMASTLOCK, HSPLIT & HLOCK, and HPROT. For the broader protocol map, see the AMBA family overview.