Protection and Security

AHB carries transaction attributes with HPROT and, when supported, secure transfer information with HNONSEC. These signals are address-phase metadata. They travel with the address/control information and must remain constant throughout a burst.

HPROT

HPROT describes protection and memory attributes. The classic 4-bit view is:

Bit	Name	Meaning when asserted
HPROT[0]	Data/Opcode	Data access. When LOW, instruction/opcode fetch.
HPROT[1]	Privileged	Privileged access. When LOW, user/unprivileged access.
HPROT[2]	Bufferable	Write response can be returned before final destination in allowed cases.
HPROT[3]	Modifiable / Cacheable legacy bit	Transfer characteristics can be modified; older Issue A material called this Cacheable.

If a Manager cannot generate accurate protection information, the specification recommends HPROT=0b0011, meaning non-cacheable, non-bufferable, privileged data access. Subordinates should not depend on HPROT unless they truly need it for protection or memory behavior.

Extended memory types

AHB5 can extend HPROT up to HPROT[6:0] using the Extended_Memory_Types property. The extended bits add lookup, allocate, and shareability behavior.

Bit	Name	Practical meaning
HPROT[0]	Data/Inst	Data access or instruction fetch hint.
HPROT[1]	Privileged	Privileged or unprivileged access.
HPROT[2]	Bufferable	Whether early/intermediate write response can be allowed for the memory type.
HPROT[3]	Modifiable	Whether transfer characteristics such as size or burst can be modified.
HPROT[4]	Lookup	Whether cache lookup is required.
HPROT[5]	Allocate	Cache allocation recommendation.
HPROT[6]	Shareable	Transfer targets memory shared with other Managers; response visibility rules are stronger.

The permitted memory categories include:

Memory type	Key behavior
Device-nE	Device memory with no early write response. Reads and writes must reach the final destination, ordering is strong, writes are not merged, reads are not speculative.
Device-E	Device memory where an early write response can be returned, but writes must be observable to other Managers when the response is given and must reach the final destination in a timely manner.
Normal Non-cacheable	Normal memory without caching. Reads can be satisfied from the final destination or a progressing write in defined cases.
Write-through	Cache lookup is required. Writes must become visible at the final destination in a timely manner.
Write-back	Cache lookup is required. Writes can be held in a cache or buffer and are not required to reach the final destination immediately.

Device memory is restrictive: transfers must not be merged, reads must not be prefetched, transfer size must not be changed, and accesses from the same Manager to the same Subordinate must remain ordered. Normal memory allows more performance-oriented behavior such as speculative reads, merged writes, cache lookups, and transfer modification when permitted by the attributes.

Legacy HPROT mapping

Some older AHB components only drive the classic HPROT[3:0] signals, while a newer AHB5 system might use the extended HPROT[6:0] memory type attributes. The specification gives a recommended compatibility mapping so the older cacheable/bufferable encoding can still be interpreted as a valid extended memory type.

HPROT[0] and HPROT[1] still carry the instruction/data and privileged/unprivileged attributes. The mapping below covers the memory-type bits that can be derived from the legacy cacheable/bufferable encoding. HPROT[5] is not shown in this legacy table because it is an Allocate hint for Write-through and Write-back memory, and it must be zero for Device memory.

Mapping of an HPROT[3:0] signaling component to provide HPROT[6:0] signaling

This table is useful at integration boundaries. A legacy Manager can keep driving its original protection bits, and the interconnect or wrapper can fill in the missing extended attributes before sending the transfer into an AHB5-style memory system. The first two rows become Device memory types, distinguishing whether early write response is allowed. The cacheable rows become Shareable Normal memory types, with Write-through and Write-back behavior selected from the original cacheable/bufferable combination.

When converting in the opposite direction, from extended HPROT[6:0] into a component that only understands HPROT[3:0], the higher-order HPROT bits can be removed. That is legal for compatibility, but information such as shareability, lookup, and allocation can be lost. The specification notes one direct consequence: this reduction can map a Write-through memory type to Non-cacheable memory. A different mapping is allowed if the system has extra information that lets it choose a more accurate legacy encoding.

For verification, the important part is not just signal encoding. It is whether the system preserves required ordering and visibility rules for the memory type being used.

Secure transfers

HNONSEC is present when the Secure_Transfers property is supported. It is asserted for a Non-secure transfer and deasserted for a Secure transfer. This active-HIGH Non-secure convention matches Arm security-extension signaling.

HNONSEC is an address-phase signal and must remain constant throughout a burst. A secure interconnect or Subordinate can use it to block illegal access, select a secure resource, or return an ERROR response. Extra care is required when connecting components that do not both support secure transfers, because dropping the signal can accidentally change the security meaning of an access.

Attribute checklist

Check	Reason
HPROT is stable with address/control	Attributes belong to the address phase.
HPROT remains constant throughout a burst	Burst beats must not silently change memory behavior.
Device memory is not speculated, merged, or resized	Device registers often have side effects.
Shareable transfers use correct visibility rules	Response timing can imply visibility to other Managers.
Security attribute is routed through interconnect	Dropping HNONSEC can break isolation.
Illegal protected access returns a defined response	Software needs deterministic behavior.
Attribute combinations are covered	Many bugs only appear in non-default attributes.

AHB Protocol