AMBA AXI · Module 9

Locked Access (Legacy AXI3)

AXI3's locked access mode — hard bus locking for atomicity — how it worked, why it serialized the interconnect, why AXI4 removed it in favor of exclusive access, and what AXI3→AXI4 bridges must do about it.

This is a short, historical chapter on a feature AXI4 deliberately removed: locked access. In AXI3, AxLOCK was 2 bits and offered three modes — normal, exclusive, and locked — where locked access achieved atomicity by hard-locking the interconnect so no other master could interpose. It worked, but it was a throughput catastrophe: locking the fabric serializes everyone. AXI4 dropped it (shrinking AxLOCK to 1 bit, normal/exclusive only — Chapter 6.4), keeping the far better exclusive access (Chapter 9.3) as the sole atomicity mechanism. Understanding locked access matters mainly for legacy AXI3 designs and AXI3↔AXI4 bridges.

1. What Locked Access Was

In AXI3, a master could mark a transaction (or sequence) locked via AxLOCK = 2'b10. A locked access told the interconnect: do not let any other master access the target until I issue an unlocked transaction. The interconnect would hold off all other masters' traffic to that subordinate (often the whole path) for the duration of the locked sequence. This guaranteed atomicity by exclusion — a locked read followed by a locked write could not be interposed by another master, so the read-modify-write was atomic simply because nobody else could get in.

It was the brute-force way to do atomics: instead of detecting interference (exclusive access), it prevented it by locking everyone out.

Figure 1 — AXI3 locked access. A locked master (AxLOCK=10) causes the interconnect to block all other masters from the target subordinate for the duration of the locked sequence, guaranteeing atomicity by exclusion. The cost: every other master is stalled — the fabric serializes around the lock holder.

2. On the Wire

A locked sequence drove AxLOCK = 2'b10 and held the lock until an unlocked transaction released it:

locked-access — AXI3 locked read/write sequence (AxLOCK=10)

7 cycles

Figure 2 — locked-access: an AXI3 locked sequence. The locked read and write drive AxLOCK=2'b10; while locked, the interconnect refuses other masters access to the subordinate. The final (unlocked) transaction, AxLOCK=2'b00, releases the lock. Atomicity is by exclusion — others are blocked, not monitored.

3. Why AXI4 Removed It

Locked access was removed because its costs vastly outweighed its benefit:

It destroys concurrency. Locking the fabric serializes all traffic through it — the entire outstanding-transaction, multi-master, out-of-order model (Module 8) is suspended while one master holds the lock. Throughput collapses for everyone, not just the lock holder.
It risks deadlock. If a locked transaction can't make progress (a slow or stuck subordinate), the whole interconnect is frozen behind it — a single point of failure for the entire fabric.
It's complex to implement. The interconnect must track lock ownership, arbitrate lock/unlock, and guarantee the lock is always released — significant logic for a rarely-needed feature.
Exclusive access does the same job better. Exclusive access (9.3) achieves atomic read-modify-write without blocking anyone: it detects interference via the monitor and retries on failure, so other masters flow freely. It's strictly superior — same atomicity, no serialization, no deadlock risk.

So AXI4 shrank AxLOCK to 1 bit (normal/exclusive) and made exclusive access the only atomicity mechanism. Locking by exclusion gave way to atomicity by detection-and-retry.

Figure 3 — why locked was replaced by exclusive. Locked access blocks all other masters (serializes the fabric, risks deadlock) to guarantee atomicity by exclusion. Exclusive access (9.3) uses a non-blocking monitor and retry-on-failure, achieving the same atomicity while other masters keep flowing. Exclusive is strictly better, so AXI4 removed locked.

4. AXI3 ↔ AXI4 Migration

Because AXI4 has no locked mode, bridging an AXI3 master that uses locked access to an AXI4 (or AXI4 subordinate) side needs care:

A locked AXI3 transaction has no direct AXI4 equivalent — AxLOCK=2'b10 simply isn't representable in AXI4's 1-bit field.
A bridge must either reject/avoid locked sequences, convert the intent to exclusive access (non-trivial — different semantics), or, if it must preserve locking, enforce the exclusion itself by serializing at the bridge (re-creating the throughput cost locally).
The AxLOCK width difference (2-bit AXI3 vs 1-bit AXI4) must be handled in the bridge's signal mapping, and the absence of locked on the AXI4 side documented.

In practice, modern designs avoid locked access entirely and use exclusive access, so the migration concern is mainly about legacy AXI3 IP that still issues locked transactions.

Figure 4 — AXI3→AXI4 bridging of locked access. AXI3's 2-bit AxLOCK locked mode has no AXI4 equivalent (1-bit field), so a bridge must avoid/reject locked sequences, convert the intent to exclusive access, or enforce exclusion locally by serializing — each with trade-offs. Modern designs avoid locked access and use exclusive throughout.

5. Common Misconceptions

Myths to unlearn

"AXI4 has a locked access mode." It does not — locked was an AXI3 feature, removed in AXI4. AXI4's AxLOCK is 1 bit (normal/exclusive only).
"Locked and exclusive are the same thing." Different mechanisms: locked blocks all other masters (atomicity by exclusion); exclusive detects interference with a monitor and retries (atomicity by detection). Exclusive doesn't block anyone.
"Locked access is just a stronger exclusive." It's not stronger — it's worse: it achieves the same atomicity at the cost of serializing the whole fabric and risking deadlock, which is exactly why it was dropped.
"You should use locked access for critical atomics." Use exclusive access. Locked is legacy-only; modern designs avoid it entirely.
"AxLOCK is 2 bits." Only in AXI3. In AXI4 it's 1 bit — a common source of bridge bugs at the AXI3/AXI4 boundary.

6. Debugging Insight

🔍 Debugging insight — locked access shows up as serialization or bridge mismatches

Locked-access issues are mostly migration and legacy-performance problems:

A whole interconnect stalls during one master's atomic sequence (AXI3)? That's locked access working as designed — it serializes the fabric. The fix isn't a bug fix; it's to switch to exclusive access, which doesn't block others.
An AXI3 locked sequence misbehaves through an AXI3→AXI4 bridge? The bridge has no way to represent locked on the AXI4 side. Check how the bridge handles AxLOCK=2'b10 — it may be dropping the lock (breaking atomicity) or serializing locally. The real fix is to stop using locked access in the AXI3 master.
AxLOCK width mismatch at an AXI3/AXI4 boundary? 2-bit vs 1-bit — the bridge's signal mapping is wrong, possibly misinterpreting the bits. Verify the mapping and that the locked encoding is handled explicitly.
Throughput tanks whenever a particular master runs? If it's an AXI3 master using locked sequences, each one freezes the fabric. Migrate it to exclusive.

The pattern: fabric-wide stalls tied to one master's atomics → locked access (migrate to exclusive); boundary atomicity/width bugs → AXI3/AXI4 locked-mode mismatch in the bridge.

7. Verification Insight

✅ Verification insight — mostly a legacy and bridge concern

For pure AXI4 designs there's nothing to verify here — locked access doesn't exist, so a checker should flag any AxLOCK encoding outside normal/exclusive as illegal (a 1-bit field can't carry locked). The verification effort applies to legacy AXI3 and AXI3↔AXI4 bridges. For AXI3: verify that a locked sequence actually achieves exclusion (no other master interposes while the lock is held) and that the lock is always released by the terminating unlocked transaction — a never-released lock is a fabric deadlock, the highest-severity case. For bridges: verify the AxLOCK width mapping (2-bit↔1-bit) and that the bridge's chosen policy for locked transactions (reject, convert, or serialize) is correct and doesn't silently drop the atomicity guarantee.

Coverage: AXI3 locked read/write sequences with concurrent contending masters (assert exclusion holds and the lock releases); a stuck/slow subordinate during a locked sequence (assert no permanent fabric freeze, or that the deadlock risk is documented/mitigated); and at the bridge, every AxLOCK value across the boundary. The single highest-value check is lock release / no-deadlock — since the defining hazard of locked access is freezing the interconnect. Most modern verification simply asserts locked access is not used and steers designs to exclusive access instead.

8. Interview Questions

9. Summary

Locked access is a removed AXI3 feature: AxLOCK=2'b10 let a master hard-lock the interconnect so no other master could interpose, guaranteeing atomicity by exclusion. It worked but was a liability — locking the fabric serializes all traffic (suspending the whole concurrency model), risks fabric-wide deadlock if the lock is never released, and is complex to implement. Since exclusive access (9.3) achieves the same atomic read-modify-write by detection and retry without blocking anyone, AXI4 removed locked access and shrank AxLOCK to 1 bit (normal/exclusive only — 6.4).

The practical relevance is legacy and migration: AXI3↔AXI4 bridges must handle the absent locked mode and the 2-bit↔1-bit AxLOCK width difference (avoid, convert to exclusive, or serialize locally — never freeze the whole new fabric). The deeper lesson is the design philosophy: atomicity by detection beat atomicity by exclusion because most atomics are uncontended, so the optimistic, non-blocking, retry-on-conflict approach is dramatically better on a high-throughput interconnect. Next, the final Module 9 chapter zooms out to where AXI ordering ends — the boundary into cache-coherency protocols (ACE/CHI) and memory barriers.

10. What Comes Next

You've seen the legacy atomicity mode; next, where AXI's ordering model reaches its limit:

9.5 — Memory Barriers & Coherency Boundary (coming next) — where AXI ordering ends and cache-coherency protocols (ACE/CHI) and memory barriers begin.

Previous: 9.3 — Exclusive Access. Related: 6.4 — AxLOCK & AxCACHE for the AxLOCK encoding change, and 9.3 — Exclusive Access for the mechanism that replaced locked. For the broader protocol catalog, see the AMBA family overview doc.