RVA23 Certification Requirements Document (rev 0.3)

Contributors to all versions of the spec in alphabetical order

Jordan Carlin
Ken Dockser
David Harris

This document is released under a Creative Commons Attribution 4.0 International License.

CRD Revision History

History of documentation changes that eventually lead to releases.

Date	Revision	Changes
April 29, 2026	0.1	Initial draft
July 27, 2026	0.2	Do not test traps into M-mode except ecall from S-mode.
August 6, 2026	0.3	Removed "custom M-mode"; made clarifications.

Date

Revision

Changes

April 29, 2026

0.1

Initial draft

July 27, 2026

0.2

Do not test traps into M-mode except ecall from S-mode.

August 6, 2026

0.3

Removed "custom M-mode"; made clarifications.

1. Introduction

This document describes the test requirements for a processor to be eligible for a RVA23 certificate.

RVA23 processor certification requires compliance with the RVA23S64 and RVA23U64 Profiles. As described in these profile specifications, compliance requires that the RV64I base instruction set and all mandatory extensions of the profile must be implemented. Furthermore, any optional extensions as specified in the profile may be implemented. Any optional portions of the base ISA and these extensions may be implemented, but if they are implemented, they must be implemented in their entirety.

There is no prohibition against implementing other RISC-V ratified base ISAs or extensions, custom extensions, or even non-conforming extensions as long as they don’t interfere with the proper functioning of the RVA23 mandatory and implemented optional extensions. However, these other base ISAs and extensions will not be tested as part of RVA23 Certification.

This document does not restate individual profile constraints such as Ssstrict. Those requirements are defined normatively in the RVA23 Profiles and are unchanged for certification.

We encourage those who have implemented other base ISAs or extensions to run the appropriate RISC-V ACTs to help ensure compliance.

1.1. Execution Environment and Test Supervisor Binary Interface (T-SBI)

Application-processor families, including RVA23, purposefully do not include a machine-mode (M-mode) profile as there is no intention that M-mode code be portable. Therefore, RVA23 Certification does not test M-mode instructions or CSRs. Any required interaction with M-mode is abstracted away by a Test Supervisor Binary Interface (T-SBI) and a Test Supervisor Execution Environment (T-SEE), which are analogous to the RISC-V Supervisor Binary Interface and OpenSBI software respectively; however, they are developed specifically for certification. The T-SEE is also responsible for invoking the implementation’s boot code as well as setting up the initial M-mode-controlled environment for the certification tests. This includes putting the processor into an initial state.

All certification tests run under the T-SEE.

As part of the certification test collateral, a reference implementation of the T-SEE is provided along with a full specification of the T-SBI. Just like with OpenSBI, it is up to the designer to modify the T-SEE, as necessary, for their implementation. The T-SBI specification is especially useful for those who have created an M-mode that differs substantially from M-mode 1.13 as defined in the RISC-V Privileged Architecture.

When the T-SEE receives a trap to M-mode, it invokes the appropriate handler. When it is necessary to execute M-mode instructions or access an M-mode CSR in order to properly set up the environment for lower privilege tests, a T-SBI-defined call is made by placing commands in registers and performing an ecall.

This `ecall’s trap handler executes the necessary M-mode code needed to complete the requested action. One such need for a T-SBI call is necessary to fulfill a requirement of RVA23’s defined Sspm extension which requires an execution environment to provide a means to select PMLEN. Another need is for the tests to be able to request that specific traps are delegated away from M-mode.

There is no requirement that any traps can be delegated. But if they can be, the T-SEE must provide a means to request that they are and a means to determine which requested traps have been delegated.

1.2. Related Specifications

Unprivileged ISA Specification - Latest version
Privileged ISA Specification - Latest version

1.3. M-Mode Trap Handler Requirements

M-mode trap behavior is out of scope for RVA23, with a few exceptions listed below. As such, the certification tests delegate almost all traps to S-mode, and do not test M-mode interrupts (MEI/MTI/MSI). Exceptions are:

An ecall from S-mode must not be delegated because the T-SBI must trap to M-mode to handle these calls.
Any trap cause that should be handled invisibly by the firmware must also not be delegated.
Hardware might not support delegating certain traps to S-mode.

Invisible traps are traps to emulate a function in firmware that is not implemented in hardware. An example of an invisible trap is to fix a fdiv instruction that malfunctions for certain input values. If a system requires invisible traps to produce correct RVA23 behavior, the designer must provide custom firmware to handle these traps, and the certification tests rely on this firmware. For example, fdiv would throw an illegal instruction exception, and this exception would not be delegated to S-mode. The designer would have to provide a M-mode trap handler that inspects illegal instruction exceptions and determines if the instruction is an fdiv. If so, it invisibly fixes any problem and returns. Otherwise, the M-mode handler places trap information into sstatus,sepc/scause/stval and invokes the S-mode trap handler to handle other illegal instructions.

The M-mode trap handler performs the following functions:

Check if the trap is a T-SBI call and if so, perform the requested T-SBI function and return from the ecall.
Call custom firmware, if any exists, to handle invisible traps. The custom firmware will save registers relative to sp, inspect machine state to see if the trap is an invisible trap, and if so, perform the function, clean up, and return to the appropriate place (perhaps the instruction after the one that trapped, or an S-mode handler if the custom firmware expects S-mode to receive the trap next). If the trap is not an invisible trap, the custom firmware will return to the next step of the M-mode trap handler.
For traps that are not delegated in hardware but typically end up in an S-mode handler (sometimes after some checks in the M-mode handler), set up sstatus, sepc, scause, stval with values coming from the machine-mode trap CSRs, and return to the S-mode trap handler to effectively delegate to S-mode.

1.4. T-SBI Control of M-mode CSRs

The T-SBI specifies calls that enable the RISC-V certification test environment to achieve the same effect as accessing any M-mode CSR — as defined in the M-mode ISA 1.13 specification — that can affect the behavior of lower-privilege modes or provide essential information, even if the DUT does not implement that CSR.

These CSRs and memory-mapped I/O registers that need to be accessible by the T-SEE are:

CSR Notes

CSR	Notes
`mstatus`	TSR, TW, TVM
`mcounteren`	All fields not hardwired to 0 must be controllable to allow testing of counter access from lower privilege modes.
`mcountinhibit`	All fields not hardwired to 0 must be controllable to allow testing of counter behavior from lower privilege modes.
`mip`	Interrupts are controlled with RVMODEL macros. SEIP, STIP, and SSIP may be controlled with T-SBI accesses to `mip`.
`menvcfg`	STCE, PBMTE, ADUE, PMM, CBZE, CBCFE, CBIE, SSE, LPE may be controllable to allow testing of the behavior of lower privilege modes with these features enabled and disabled. Note that ADUE may be read-only zero because Svadu is optional, and that PMM may only be able to hold PMLEN=0 and 7 per the RVA23 profile. CBIE must be able to hold 00 and at least one of 01 and/or 11. CDE, DTE are out of scope because they do not relate to RVA23 features.
`mhpmevent*`	May need to be writable to trigger Sscofpmf LCOFI
`mhpmcounter*`	May need to be writable to trigger Sscofpmf LCOFI All writable fields must be controllable to allow testing of the behavior of lower privilege modes when certain features are disabled.
`mseccfg`	SSEED and USEED must be controllable if Zkr is supported; otherwise they are read-only zero. PMM, MLPE, RLB, MMWP, MML are out of scope because they do not relate to RVA23 features.
`mstateen`	SE0, ENVCFG, CONTEXT may be controllable to allow testing of the behavior of lower privilege modes when certain features are disabled. Other fields are out of scope because they do not relate to RVA23 features.
`medeleg`	Each exception cause except `ecall` from S-mode is delegated to S-mode if the corresponding bit can be written to 1. Otherwise, a designer-supplied M-mode trap handler intercepts invisible traps and relays the rest to S-mode.
`mideleg`	SEI, STI, SSI, and LCOFI are delegated to S-mode if the corresponding bit can be written to 1. Otherwise, the trap handler relays these to S-mode. VSEI, VSTI, VSSI and SGEI (if implemented) are read-only 1 per Priv Spec 22.4.2 because hypervisor is a mandatory part of the profile.
`mhartid`	Must be readable to influence the behavior of multicore tests.
`mtime`	Must be readable to find the current time to set timer interrupts.

mstatus

TSR, TW, TVM

mcounteren

All fields not hardwired to 0 must be controllable to allow testing of counter access from lower privilege modes.

mcountinhibit

All fields not hardwired to 0 must be controllable to allow testing of counter behavior from lower privilege modes.

mip

Interrupts are controlled with RVMODEL macros. SEIP, STIP, and SSIP may be controlled with T-SBI accesses to mip.

menvcfg

STCE, PBMTE, ADUE, PMM, CBZE, CBCFE, CBIE, SSE, LPE may be controllable to allow testing of the behavior of lower privilege modes with these features enabled and disabled. Note that ADUE may be read-only zero because Svadu is optional, and that PMM may only be able to hold PMLEN=0 and 7 per the RVA23 profile. CBIE must be able to hold 00 and at least one of 01 and/or 11. CDE, DTE are out of scope because they do not relate to RVA23 features.

mhpmevent*

May need to be writable to trigger Sscofpmf LCOFI

mhpmcounter*

May need to be writable to trigger Sscofpmf LCOFI

All writable fields must be controllable to allow testing of the behavior of lower privilege modes when certain features are disabled.

mseccfg

SSEED and USEED must be controllable if Zkr is supported; otherwise they are read-only zero. PMM, MLPE, RLB, MMWP, MML are out of scope because they do not relate to RVA23 features.

mstateen

SE0, ENVCFG, CONTEXT may be controllable to allow testing of the behavior of lower privilege modes when certain features are disabled. Other fields are out of scope because they do not relate to RVA23 features.

medeleg

Each exception cause except ecall from S-mode is delegated to S-mode if the corresponding bit can be written to 1. Otherwise, a designer-supplied M-mode trap handler intercepts invisible traps and relays the rest to S-mode.

mideleg

SEI, STI, SSI, and LCOFI are delegated to S-mode if the corresponding bit can be written to 1. Otherwise, the trap handler relays these to S-mode. VSEI, VSTI, VSSI and SGEI (if implemented) are read-only 1 per Priv Spec 22.4.2 because hypervisor is a mandatory part of the profile.

mhartid

Must be readable to influence the behavior of multicore tests.

mtime

Must be readable to find the current time to set timer interrupts.

The Certification Test Environment does not need to access the equivalent of the following M-mode CSRs/fields:

CSR Notes

CSR	Notes
`mstatus`	SD, SPELP, MXR, SUM, FS, VS, SPP, SPIE, SIE are accessible from `sstatus` and should not be tested through `mstatus` for RVA23 certification. GVA is accessible from `hstatus` and not tested from `mstatus`. MPV does not affect the behavior of lower privilege modes and therefore does not need to be dynamically changed. Additionally the fields XS, SDT, MBE, SBE, UBE, SXL, and UXL are out of scope for RVA23.
`mie`	SEIE, STIE, SSIE, LCOFIE, and SGEIE are controlled from `sie` or `hie`.
`misa`	Not tested because required RVA23 features are not turned off during testing.
`mvendorid`	Does not affect the behavior of lower privilege modes.
`marchid`	Does not affect the behavior of lower privilege modes.
`mimpid`	Does not affect the behavior of lower privilege modes.
`mconfigptr`	Does not affect the behavior of lower privilege modes.
`mtvec`	Trap vector must be set up during boot but is not modified through SBI.
`mepc`	Does not affect the behavior of lower privilege modes.
`mcause`	Does not affect the behavior of lower privilege modes.
`mscratch`	Does not affect the behavior of lower privilege modes.
`mtval`	Does not affect the behavior of lower privilege modes.
`mtinst`	Does not affect the behavior of lower privilege modes.
`mtval2`	Does not affect the behavior of lower privilege modes.
`mcycle`	Not tested.
`minstret`	Not tested.
`mtimecmp`	MTI is not tested.
`msip`	MSI is not tested.
PMP CSRs	PMP restrictions on access are indistinguishable below M-mode from a PMA that imposes similar restrictions.

mstatus

SD, SPELP, MXR, SUM, FS, VS, SPP, SPIE, SIE are accessible from sstatus and should not be tested through mstatus for RVA23 certification. GVA is accessible from hstatus and not tested from mstatus. MPV does not affect the behavior of lower privilege modes and therefore does not need to be dynamically changed. Additionally the fields XS, SDT, MBE, SBE, UBE, SXL, and UXL are out of scope for RVA23.

mie

SEIE, STIE, SSIE, LCOFIE, and SGEIE are controlled from sie or hie.

misa

Not tested because required RVA23 features are not turned off during testing.

mvendorid