6.1. RVA20 Profiles
The RVA20 profiles are intended to be used for 64-bit application processors running rich OS stacks. Only user-mode (RVA20U64) and supervisor-mode (RVA20S64) profiles are specified in this family.
| There is no machine-mode profile currently defined for application processor families. A machine-mode profile for application processors would only be used in specifying platforms for portable machine-mode software. Given the relatively low volume of portable M-mode software in this domain, the wide variety of potential M-mode code, and the very specific needs of each type of M-mode software, we are not specifying individual M-mode ISA requirements in the A-family profiles. |
| Only XLEN=64 application processor profiles are currently defined. It would be possible to also define very similar XLEN=32 variants. |
6.1.1. RVA20U64 Profile
The RVA20U64 profile specifies the ISA features available to user-mode execution environments in 64-bit applications processors. This is the most important profile within the application processor family in terms of the amount of software that targets this profile.
RVA20U64 has one optional extension (Zihpm).
6.1.1.1. RVA20U64 Mandatory Base
RV64I is the mandatory base ISA for RVA20U64, and is little-endian.
As per the unprivileged architecture specification, the ecall
instruction causes a requested trap to the execution environment.
The fence.tso instruction is mandatory.
The fence.tso instruction was incorrectly described as
optional in the 2019 ratified specifications. However, fence.tso is
encoded within the standard fence encoding such that implementations
must treat it as a simple global fence if they do not natively support
TSO-ordering optimizations. As software can always assume without any
penalty that fence.tso is being exploited by a hardware
implementation, there is no advantage to making the instruction a
profile option. Later versions of the unprivileged ISA
specifications correctly indicate that fence.tso is mandatory.
|
6.1.1.2. RVA20U64 Mandatory Extensions
-
M Integer multiplication and division.
-
A Atomic instructions.
-
F Single-precision floating-point instructions.
-
D Double-precision floating-point instructions.
-
C Compressed Instructions.
-
Zicsr CSR instructions. These are implied by presence of Zicntr or F.
-
Zicntr Basic counters.
-
Ziccif Main memory regions with both the cacheability and coherence PMAs must support instruction fetch, and any instruction fetches of naturally aligned power-of-2 sizes up to min(ILEN,XLEN) (i.e., 32 bits for RVA20) are atomic.
| Ziccif is a new extension name capturing this feature. The fetch atomicity requirement facilitates runtime patching of aligned instructions. |
-
Ziccrse Main memory regions with both the cacheability and coherence PMAs must support RsrvEventual.
| Ziccrse is a new extension name capturing this feature. |
-
Ziccamoa Main memory regions with both the cacheability and coherence PMAs must support AMOArithmetic.
| Ziccamoa is a new extension name capturing this feature. |
-
Za128rs Reservation sets must be contiguous, naturally aligned, and at most 128 bytes in size.
| Za128rs is a new extension name capturing this feature. The minimum reservation set size is effectively determined by the size of atomic accesses in the A extension. |
-
Zicclsm Misaligned loads and stores to main memory regions with both the cacheability and coherence PMAs must be supported.
| This introduces a new extension name for this feature. This requires misaligned support for all regular load and store instructions (including scalar and vector) but not AMOs or other specialized forms of memory access. Even though mandated, misaligned loads and stores might execute extremely slowly. Standard software distributions should assume their existence only for correctness, not for performance. |
6.1.1.3. RVA20U64 Optional Extensions
-
Zihpm Hardware performance counters.
| Hardware performance counters are a supported option in RVA20. The number of counters is platform-specific. |
| The rationale to not make Q an optional extension is that quad-precision floating-point is unlikely to be implemented in hardware, and so we do not require or expect A-profile software to expend effort optimizing use of Q instructions in case they are present. |
Zifencei is not classed as a supported option in the user-mode
profile because it is not sufficient by itself to produce the desired
effect in a multiprogrammed multiprocessor environment without OS
support, and so the instruction cache flush should always be performed
using an OS call rather than using the fence.i instruction.
fence.i semantics can be expensive to implement for some hardware
memory hierarchy designs, and so alternative non-standard
instruction-cache coherence mechanisms can be used behind the OS
abstraction. A separate extension is being developed for more general
and efficient instruction cache coherence.
|
The execution environment must provide a means to synchronize writes to
instruction memory with instruction fetches, the implementation of which
likely relies on the Zifencei extension.
For example, RISC-V Linux supplies the __riscv_flush_icache system call and
a corresponding vDSO call.
|
6.1.2. RVA20S64 Profile
The RVA20S64 profile specifies the ISA features available to a supervisor-mode execution environment in 64-bit applications processors. RVA20S64 is based on privileged architecture version 1.11.
RVA20S64 has one unprivileged option (Zihpm) and one privileged option (Sv48).
6.1.2.1. RVA20S64 Mandatory Base
RV64I is the mandatory base ISA for RVA20S64, and is little-endian.
The ecall instruction operates as per the unprivileged architecture
specification. An ecall in user mode causes a contained trap to
supervisor mode. An ecall in supervisor mode causes a requested
trap to the execution environment.
6.1.2.2. RVA20S64 Mandatory Extensions
The following unprivileged extensions are mandatory:
-
The RVA20S64 mandatory unprivileged extensions include all the mandatory unprivileged extensions in RVA20U64.
-
Zifencei Instruction-Fetch Fence.
| Zifencei is mandated as it is the only standard way to support instruction-cache coherence in RVA20 application processors. A new instruction-cache coherence mechanism is under development which might be added as an option in the future. |
The following privileged extensions are mandatory:
-
Ss1p11 Privileged Architecture version 1.11.
-
Svbare The
satpmode Bare must be supported.
| This is a new extension name for this feature. |
-
Sv39 Page-Based 39-bit Virtual-Memory System.
-
Svade Page-fault exceptions are raised when a page is accessed when A bit is clear, or written when D bit is clear.
| This is a new extension name for this feature. |
-
Ssccptr Main memory regions with both the cacheability and coherence PMAs must support hardware page-table reads.
| This is a new extension name for this feature. |
-
Sstvecd
stvec.MODEmust be capable of holding the value 0 (Direct). Whenstvec.MODE=Direct,stvec.BASEmust be capable of holding any valid four-byte-aligned address.
| This is a new extension name for this feature. |
-
Sstvala
stvalmust be written with the faulting virtual address for load, store, and instruction page-fault, access-fault, and misaligned exceptions, and for breakpoint exceptions other than those caused by execution of theebreakorc.ebreakinstructions. For illegal-instruction exceptions,stvalmust be written with the faulting instruction.
| This is a new extension name for this feature. |
6.1.2.3. RVA20S64 Optional Extensions
RVA20S64 has one unprivileged option.
-
Zihpm Hardware performance counters.
| The number of counters is platform-specific. |
RVA20S64 has the following privileged options:
-
Sv48 Page-Based 48-bit Virtual-Memory System.
-
Ssu64xl
sstatus.UXLmust be capable of holding the value 2 (i.e., UXLEN=64 must be supported).
| This is a new extension name for this feature. |