AMBA AXI · Module 6

AxPROT, AxQOS & AxREGION

Decode the AXI system attributes — AxPROT (privilege/secure/instruction protection), AxQOS (4-bit quality-of-service priority), and AxREGION (region identifier), and where each is set and consumed.

Three more address-channel signals carry system policy rather than transfer geometry: AxPROT (protection — privilege, security, instruction-vs-data), AxQOS (a quality-of-service priority hint), and AxREGION (a region identifier that lets one slave port serve several address regions). Like AxLOCK/AxCACHE, they don't change the data or the address — they tell the system how to police, prioritize, and decode the access. A defining trait here: some of these are driven not by the original manager but by the interconnect (AxREGION especially). This chapter decodes all three and pins down who sets each and who acts on it.

1. Three System Attributes

Signal	Width	Carries
`AxPROT`	3 bits	Protection: privileged/unprivileged, secure/non-secure, instruction/data
`AxQOS`	4 bits	Quality-of-service priority identifier (arbitration hint)
`AxREGION`	4 bits	Region identifier (up to 16 logical regions per slave port)

All three ride the address handshake (AWPROT/ARPROT, AWQOS/ARQOS, AWREGION/ARREGION) and are constant for the transaction. They are optional to act on — a simple slave can ignore AxQOS/AxREGION and a non-secure-unaware slave can ignore AxPROT — but in a real SoC they drive access control, arbitration, and slave-side decode.

2. AxPROT — Protection

AxPROT is a 3-bit field, one bit per protection axis:

Bit	`0`	`1`
`AxPROT[0]`	Unprivileged	Privileged
`AxPROT[1]`	Secure	Non-secure
`AxPROT[2]`	Data	Instruction

Note the inverted sense of bit 1: AxPROT[1] = 0 means secure, = 1 means non-secure. This is the AXI integration point for TrustZone: a secure slave (or a TZ-aware interconnect/memory controller) checks AxPROT[1] and rejects a non-secure access to a secure region (returning a SLVERR/DECERR-style response). AxPROT[0] distinguishes privileged (OS/kernel) from unprivileged (user) accesses, and AxPROT[2] flags an instruction fetch vs a data access (a hint — 0/data is the safe default for ambiguous cases).

Figure 1 — AxPROT's three protection bits. Bit 0: privileged vs unprivileged. Bit 1: secure vs non-secure (note the inverted sense — 0 = secure), the TrustZone integration point. Bit 2: instruction vs data. A protection-aware slave or interconnect uses these to permit or reject the access.

3. AxQOS — Quality of Service

AxQOS is a 4-bit quality-of-service identifier — a priority hint the interconnect can use when arbitrating between competing managers. The spec deliberately does not mandate its meaning: by convention a higher value indicates a higher-priority transaction, and 4'b0000 means the access is not participating in any QoS scheme (the default). It is purely advisory — a slave needn't honor it, and it carries no ordering or correctness guarantee; it only influences arbitration, never the result.

Typical use: a latency-sensitive manager (a display controller that must not underflow) drives a high AxQOS so the interconnect's arbiter favors its requests over a bulk DMA engine's lower-QoS traffic during contention. Because it's just an arbitration weight, getting it wrong degrades performance/latency, never functional correctness.

Figure 2 — AxQOS as a 4-bit priority identifier feeding interconnect arbitration. By convention higher = higher priority, 0000 = not participating. It is advisory: the arbiter may favor high-QoS managers under contention, but QoS never changes the data or guarantees ordering — only which request wins arbitration.

4. AxREGION — Region Identifier

AxREGION is a 4-bit identifier that lets a single slave interface present up to 16 logical regions without the slave having to re-decode the high address bits. The interconnect decodes the address and drives AxREGION so that the slave can use it as a pre-decoded "which of my regions is this?" selector.

The classic case: one peripheral exposes several address ranges (say, a register block at one offset and a buffer at another) that all map to the same physical slave port. Instead of every region re-running address decode, the interconnect decodes once and tags the transaction with AxREGION; the slave switches on AxREGION directly. All accesses with a given AxREGION value must lie within a single contiguous address region. Crucially, AxREGION is generated by the interconnect, not the original manager — the manager just issues an address.

Figure 3 — AxREGION. The interconnect decodes the address once and tags the transaction with a region identifier; a single slave port then serves multiple logical regions by switching on AxREGION instead of re-decoding the address. AxREGION is interconnect-generated — the manager only supplies the address.

5. Who Sets Each, Who Acts on It

The key mental model is the producer/consumer split — and that the interconnect, not just the manager, is a producer here:

Figure 4 — producers and consumers. AxPROT is set by the manager and enforced by protection-aware slaves / TrustZone logic. AxQOS is set by the manager (or remapped by the interconnect) and consumed by the arbiter as an advisory priority. AxREGION is generated by the interconnect from the address decode and consumed by the slave as a pre-decoded region selector.

6. Common Misconceptions

Myths to unlearn

"AxPROT[1]=1 means secure." Inverted — AxPROT[1] = 0 is secure, = 1 is non-secure. Reading it backwards inverts your TrustZone access checks (the most dangerous bug here).
"AxQOS guarantees ordering or priority of completion." No — AxQOS is an advisory arbitration hint. It influences which request the arbiter favors under contention; it never reorders responses by rule, never guarantees latency, and never affects correctness. A slave may ignore it entirely.
"The manager drives AxREGION." Usually not — AxREGION is generated by the interconnect from the address decode. The manager just issues an address; the interconnect tags the region.
"AxQOS = 0 means lowest priority." 4'b0000 conventionally means not participating in QoS (the default), not "lowest." The convention is higher value = higher priority, but the spec doesn't mandate the exact policy.
"These signals change what data is returned." They don't — AxPROT/AxQOS/AxREGION are policy/routing qualifiers (protection, arbitration, region decode), not data or address.

7. Debugging Insight

🔍 Debugging insight — system attributes fail as access-denied, latency, or wrong-region bugs

These signals rarely show as corrupted bus data — they surface as access rejections, latency anomalies, or wrong-region behavior:

A secure region access is unexpectedly rejected (or a non-secure access unexpectedly allowed)? Check AxPROT[1] and its sense — 0 = secure, 1 = non-secure. A master defaulting AxPROT to all-zeros is issuing secure, unprivileged, data accesses; a master leaving it all-ones is non-secure — a classic cause of "works on one master, denied on another." Trace the actual AWPROT/ARPROT bits at the slave, not the intended ones.
A latency-sensitive master starving / underflowing under load? Check AxQOS — if its high-priority traffic is going out with AxQOS=0 (default) while a bulk engine also sits at 0, the arbiter has no basis to favor it. This is a performance bug (correct data, missed deadlines), and the fix is QoS assignment, not the data path.
A multi-region slave routing accesses to the wrong region? Check AxREGION — and remember it's interconnect-generated. A wrong region usually means the interconnect's address-decode/region map is misconfigured, or the slave is re-decoding the address itself and disagreeing with the interconnect's AxREGION. Don't debug it as a master bug.
Privilege faults from the wrong context? Check AxPROT[0] — user-mode (unprivileged) accesses to a privileged-only region are correctly rejected; if a kernel access is being denied, the master may be issuing it as unprivileged.

So: access-denied → AxPROT (especially the inverted secure bit); missed deadlines → AxQOS; wrong region → AxREGION (look at the interconnect, not the master).

8. Verification Insight

✅ Verification insight — protection legality, QoS coverage, region/decode consistency

Each attribute needs a different verification angle. For AxPROT: assert protection-aware slaves enforce the policy — a non-secure access (AxPROT[1]=1) to a secure region returns the expected error and never reads/writes secure data; cover all relevant combinations (secure/non-secure × privileged/unprivileged × instruction/data), and explicitly test the inverted secure bit so a backwards check is caught. For AxQOS: because it's advisory, you verify behavior under contention (high-QoS traffic is favored on average) and coverage of QoS values, not a strict ordering rule — and assert QoS never alters returned data. For AxREGION: check the interconnect drives the region consistent with the address decode, that all accesses sharing a region value fall within one contiguous range, and that the slave's region handling matches the interconnect's AxREGION (no double-decode mismatch).

The highest-value negative tests are the security ones: drive forbidden AxPROT combinations at secure regions and prove rejection — a functional data check alone never exercises the access-control path. TrustZone/protection and QoS-arbitration coverage are expanded in the system-integration and performance modules.

9. Interview Questions

10. Summary

AxPROT, AxQOS, and AxREGION are system-policy qualifiers on the address channel — protection, priority, and region decode — that never touch the data or address. AxPROT (3 bits) encodes privilege ([0]), security ([1], inverted: 0=secure — the TrustZone hook), and instruction/data ([2]), enforced by protection-aware slaves. AxQOS (4 bits) is an advisory priority identifier (higher = higher priority by convention, 0000 = not participating) consumed by the interconnect arbiter — it affects performance, never correctness, and may be remapped by the interconnect. AxREGION (4 bits) is an interconnect-generated region identifier letting one slave port serve up to 16 logical regions without re-decoding the address.

The unifying lesson is the producer/consumer split: the manager sets AxPROT (and a baseline AxQOS), but the interconnect is itself a producer — it generates AxREGION and may remap AxQOS. Their bugs read as access-denied (AxPROT, watch the inverted secure bit), missed deadlines (AxQOS), or wrong-region routing (AxREGION, look at the interconnect) — never as corrupted data. Next: AxUSER and the user-defined sideband signals — the escape hatch the spec leaves open, and the interoperability risk it carries.

11. What Comes Next

You've decoded the system attributes; next, the user-defined escape hatch:

6.6 — AxUSER & Sideband Signals (coming next) — user-defined sideband signals and the integration/interoperability risks they carry.
6.7 — WSTRB Write Strobes (coming soon) — byte-lane strobes, alignment, and sparse writes.

Previous: 6.4 — AxLOCK & AxCACHE. For the broader protocol catalog, see the AMBA family overview doc.