RVA23 Certification Requirements Document (rev 0.4)

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

Changes to this document, by revision.

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.
October 6, 2026	0.4	Editorial and technical review.

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.

October 6, 2026

0.4

Editorial and technical review.

1. Introduction

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

RVA23 processor certification requires compliance with the RVA23S64 and RVA23U64 Profiles. As described in these profile specifications, compliance requires implementing the RV64I base instruction set and all mandatory extensions of the profile. 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. The base instruction set and extensions are defined in the Unprivileged and Privileged ISA specifications.

There is no prohibition against implementing other 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.

DUTs that implement other extensions are encouraged to run the appropriate RISC-V ACTs to help ensure compliance.

The remainder of the document describes requirements for the device under test (DUT), developers, and the execution environment.

2. Certification Requirements

The RISC-V Certification Tests certifies processors, not platforms. Nevertheless, testing requires certain basic platform capabilities to run tests and report results. Therefore, the hart being certified must be supported by a platform that provides the following capabilities:

Load an ELF file into memory at a physical address below 0x40_0000_0000 (so that Sv39 can identity-map it) and begin execution
Trigger and clear SEI and SSI through software, if these interrupts are supported
Print characters to a console to report test results
Terminate a test with a success or failure code under software control, either via a testbench for RTL or a hardware signal for silicon
Run tests on several harts at once, if the DUT has more than one, to stress memory ordering and atomicity
Implement memory-mapped mtime register if it is not part of the hart

The developer must supply a configuration directory containing the following files. See the Certification Test Plan (CTP) for more details.

A Unified Database (UDB) <dut>.yaml file describing the DUT’s supported extensions and all the parameters affecting the behavior of these extensions
A link.ld linker file to place the test code and data in memory
A rvmodel_macros.h file providing DUT-specific macros to perform functions such as printing a character to the console, terminating a test, and triggering and clearing interrupts
A sail.json file to configure the reference model to match the expected behavior of the DUT
A test_config.yaml file supplying paths to the toolchain and other config files

The developer may optionally supply:

A RVMODEL_BOOT macro in the rvmodel_macros.h file containing custom boot code, such as initializing a PLL, memory controller, or custom CSRs
A RVMODEL_INVISIBLE_TRAP_HANDLER macro in the rvmodel_macros.h file containing a custom M-mode trap handler for DUT-specific invisible traps
Modified rvtest_setup.h and rvtest_trap_handler.h files to accommodate DUT-specific boot code or T-SEE (see Chapter 3)
A run_cmd.txt file with the command line to run an ELF on the DUT, if not using their own test harness

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

Application-processor families, including RVA23, deliberately 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 directly test M-mode instructions or CSRs.

RVA23 certification tests operate within a Test Supervisor Execution Environment (T-SEE) that consists of M-mode code including boot code and a M-mode trap handler. Certification tests come with a reference T-SEE (rvtest_setup.h and rvtest_trap_handler.h) compatible with Privileged Architecture version 1.13 (Sm1p13). Just like with OpenSBI, developers may modify the reference to handle implementation-specific boot code or to accommodate non-portable M-mode.

The Test Supervisor Binary Interface (T-SBI) is a set of calls that let tests running below M-mode request services from the T-SEE, such as accessing protected memory and modifying machine-mode CSRs. For example, the T-SBI supports RVA23’s requirements to make an ecall to the T-SEE from S-mode and to provide a means to select PMLEN for Sspm.

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, as specified in the Abstraction Layer section of the CTP.

3.1. 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). Special cases 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 not be delegated.
Hardware might not support delegating certain traps to S-mode.

The M-mode trap handler requirements to support invisible traps and undelegable traps are defined in the Abstraction Layer section of the CTP.

3.2. T-SBI Control of M-mode CSRs

The T-SBI specifies calls to the T-SEE that enable the test program to achieve the same effect as accessing any M-mode CSR — as defined in Sm1p13 — 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:

Register	Notes
`mstatus`	TW must be controllable.
`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. CBIE must be able to hold 00 and at least one of 01 or 11. CDE, DTE are out of scope because they do not relate to RVA23 features.
`mhpmevent*`	Must be writable to trigger Sscofpmf LCOFI
`mhpmcounter*`	Must be writable to trigger Sscofpmf LCOFI
`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.
`mstateen0`	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 other than `ecall` from S-mode is delegated to S-mode if the corresponding bit can be written to 1. Otherwise, the trap handler relays these to S-mode. However, the developer may supply an invisible M-mode trap handler where needed by the implementation, such as to emulate an unsupported function. In such a case, the affected traps would not be delegated, and the M-mode handler would provide the needed support.
`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 (if implemented) SGEI are read-only 1 because the H-extension 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

TW must be controllable.

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. CBIE must be able to hold 00 and at least one of 01 or 11. CDE, DTE are out of scope because they do not relate to RVA23 features.

mhpmevent*

Must be writable to trigger Sscofpmf LCOFI

mhpmcounter*

Must be writable to trigger Sscofpmf LCOFI

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.

mstateen0

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 other than ecall from S-mode is delegated to S-mode if the corresponding bit can be written to 1. Otherwise, the trap handler relays these to S-mode. However, the developer may supply an invisible M-mode trap handler where needed by the implementation, such as to emulate an unsupported function. In such a case, the affected traps would not be delegated, and the M-mode handler would provide the needed support.

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 (if implemented) SGEI are read-only 1 because the H-extension 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 T-SEE does not need to access the equivalent of the following M-mode CSRs/fields:

Register	Notes
`mstatus`	SD, SPELP, MXR, SUM, FS, VS, SPP, SPIE, SIE, UXL 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. XS, SDT, MBE, SBE, UBE, and SXL are out of scope for RVA23. TSR and TVM are problematic when trapping to supervisor mode for RVA23 because they enter a trap loop on their own `sret` at the end of the handler.
`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 T-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	Boot code must configure PMP to provide access to main memory. 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, UXL 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. XS, SDT, MBE, SBE, UBE, and SXL are out of scope for RVA23. TSR and TVM are problematic when trapping to supervisor mode for RVA23 because they enter a trap loop on their own sret at the end of the handler.

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