40 Volume II: RISC-V Privileged Architectures V1.10
address space. Some memory regions might not support reads, writes, or execution; some might
not support subword or subblock accesses; some might not support atomic operations; and some
might not support cache coherence or might have different memory models. Similarly, memory-
mapped control registers vary in their supported access widths, support for atomic operations, and
whether read and write accesses have associated side effects. In RISC-V systems, these properties
and capabilities of each region of the machine’s physical address space are termed physical memory
attributes (PMAs). This section describes RISC-V PMA terminology and how RISC-V systems
implement and check PMAs.
PMAs are inherent properties of the underlying hardware and rarely change during system oper-
ation. Unlike physical memory protection values described in Section 3.6, PMAs do not vary by
execution context. The PMAs of some memory regions are fixed at chip design time—for example,
for an on-chip ROM. Others are fixed at board design time, depending, for example, on which
other chips are connected to off-chip buses. Off-chip buses might also support devices that could
be changed on every power cycle (cold pluggable) or dynamically while the system is running (hot
pluggable). Some devices might be configurable at run time to support different uses that imply
different PMAs—for example, an on-chip scratchpad RAM might be cached privately by one core
in one end-application, or accessed as a shared non-cached memory in another end-application.
Most systems will require that at least some PMAs are dynamically checked in hardware later in
the execution pipeline after the physical address is known, as some operations will not be supported
at all physical memory addresses, and some operations require knowing the current setting of a
configurable PMA attribute. While many other systems specify some PMAs in the virtual memory
page tables and use the TLB to inform the pipeline of these properties, this approach injects
platform-specific information into a virtualized layer and can cause system errors unless attributes
are correctly initialized in each page-table entry for each physical memory region. In addition, the
available page sizes might not be optimal for specifying attributes in the physical memory space,
leading to address-space fragmentation and inefficient use of expensive TLB entries.
For RISC-V, we separate out specification and checking of PMAs into a separate hardware structure,
the PMA checker. In many cases, the attributes are known at system design time for each physical
address region, and can be hardwired into the PMA checker. Where the attributes are run-time
configurable, platform-specific memory-mapped control registers can be provided to specify these
attributes at a granularity appropriate to each region on the platform (e.g., for an on-chip SRAM
that can be flexibly divided between cacheable and uncacheable uses). PMAs are checked for any
access to physical memory, including accesses that have undergone virtual to physical memory
translation. To aid in system debugging, we strongly recommend that, where possible, RISC-V
processors precisely trap physical memory accesses that fail PMA checks. Precisely trapped PMA
violations manifest as load, store, or instruction-fetch access exceptions, distinct from virtual-
memory page-fault exceptions. Precise PMA traps might not always be possible, for example, when
probing a legacy bus architecture that uses access failures as part of the discovery mechanism. In
this case, error responses from slave devices will be reported as imprecise bus-error interrupts.
PMAs must also be readable by software to correctly access certain devices or to correctly configure
other hardware components that access memory, such as DMA engines. As PMAs are tightly tied
to a given physical platform’s organization, many details are inherently platform-specific, as is
the means by which software can learn the PMA values for a platform. The configuration string
(Chapter 8) can encode PMAs for on-chip devices and might also describe on-chip controllers for off-
chip buses that can be dynamically interrogated to discover attached device PMAs. Some devices,