Contributors to all versions of the spec in alphabetical order

  • James Ball

  • 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

Mar 10, 2026

1.0 - Voted on and approved by the CSC Requirements WG on this date

  • Set allowed values for MISALIGNED_LDST_HW_SUPPORT to be "Any" to be consistent with other parameters.

  • Moved HPM_COUNTER_SZ to IN-SCOPE parameters and add "and will not trap if read." to its parameter definition.

Mar 10, 2026

0.8

  • Extension and Parameter appendices now only list things mentioned in the CRD.

  • The c.ebreak instruction only exists if the C extension is present.

Mar 9, 2026

0.7

  • Added "Dependent Extensions" section to list extensions that are only required if certain other extensions are present

Mar 5, 2026

0.6

Mar 4, 2026

0.5

  • Added note and link to GitHub issue that MISALIGNED_ATOMICITY_GRANULE_SIZE might be removed from this CRD

Mar 3, 2026

0.4

  • Incorporated feedback from CSC Requirements WG meeting on Feb 27, 2026

    • Removed WARL/WLRL handling section since there are no CSRs with WARL/WLRL fields in RVI20

    • Preliminary parameters now link to normative rules

  • Added Extensions and Parameters appendices

  • Added link to RFC2119 in glossary and use RFC2119 keywords in uppercase throughout the document

Feb 23, 2026

0.3

  • Incorporated feedback from CSC Requirements WG meeting on Feb 20, 2026

    • Added column for "Impact on Certificate Scope" in the IN-SCOPE parameters table

    • Added note that parameters are preliminary

Feb 23, 2026

0.2

Feb 5, 2026

0.1

  • Copied from UDB-generated adoc

Glossary

Table 1. Glossary
Term Meaning

RISC-V

(Reduced Instruction Set Computer) architecture, version 5

RVI

RISC-V International (organization that oversees RISC-V)

RVCP

RISC-V Certification Program

TSC

Technical Steering Committee (branch of RVI that creates standards)

CSC

Certification Steering Committee (branch of RVI that oversees the RVCP)

CRD

Certification Requirements Document

CTP

Certification Test Plan

CSR

Control & Status Register (located inside processor, not memory-mapped)

TBD

To Be Determined

N/A

“Not Applicable”

AKA

“Also Known As”

Additionally, this CRD follows RFC 2119 which defines the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in uppercase to indicate requirement level. This is summarized in the table below for convenience.

Table 2. RFC 2119 Requirement Level Keywords
Term Meaning

MUST

Indicates a mandatory requirement

SHOULD

Indicates a recommended requirement

MAY

Indicates an optional requirement

1. Introduction

The RVI20-32 processor certificate is based on the RVI20U32 profile. The RVI20-64 processor certificate is based on the RVI20U64 profile.

The RVI certificate class corresponds to the RVI Profile Family. This certificate class only includes the RISC-V Unprivileged ISA. Certificates for the RVI certificate class are intended for internal use by the RVCP (RISC-V Certification Program).

1.1. What’s a CRD?

Certification Requirements Documents (CRDs) list requirements an implementation MUST meet to obtain an associated RVI (RISC-V International) certificate. CRDs are developed by the RVI CSC (Certification Steering Committee) organization in collaboration with the RVI TSC (Technical Steering Committee) organization who creates RISC-V standards.

The CRDs refer to and augment information provided in existing ratified RVI standards.

There are a variety of certificates offered by RVI to accommodate the various RVI standards. There are certificates for processors, non-processor system IP (e.g., IOMMU), and system platforms (processor + system IP) hardware standards. There are multiple classes of processor certificates available to accommodate the wide range of RISC-V implementations from basic microcontrollers to advanced Applications-class processors.

Each CRD has a list of mandatory behaviors along with a list of optional behaviors. Note that not all behaviors allowed in RISC-V standards are supported by a particular CRD.

1.2. Naming Scheme

1.2.1. CRD Naming

All components of the RVCP share the following naming scheme:

Format: <name>[v<version>]

Where:

  • Left & right square brackets denote optional.

  • Less-than & greater-than signs just separate fields (i.e., they aren’t present in the CRD name).

  • <name> identifies the type of RISC-V standard (processor, non-processor system IP, or platform) along with any other information required to identify the variant of that standard.

  • <version> identifies a particular release

    • Format is <major>[.<minor>[.<patch>]]

    • Inspired by semantic versioning scheme (semver.org/) but doesn’t follow it exactly

The rules for updating <major>, <minor>, and <patch> are defined by the type of RVCP component. However, they follow these general guidelines:

  • A <major> release of 0 is used for pre-release versions and release versions start with 1.

  • The <major> release number is updated when mandatory changes are made.

  • The <minor> release number is updated when optional changes are made.

  • The <patch> release number is updated for documentation fixes/improvements that don’t affect certificates already obtained for a particular implementation.

The specific rules for updating the version number of a CRD are as follows:

  • The <major> release number is updated for changes that could cause a previously certified implementation to no longer meet requirements. An example is requiring a new version of a standard.

  • The <minor> release number is updated for increased support of optional behaviors.

  • The <patch> release number is updated for documentation fixes/improvements. These changes cannot cause a previously certified implementation to no longer meet requirements.

1.2.2. Processor Naming

RVCP components for processors have the following format for their <name>:

<class><model>[<-base>]

Where:

  • <class> is MC for Microcontroller Class and AC for Apps-processor Class

  • <model> is 3-digit integer defined as follows:

    • The hundreds' digit indicates the series

    • The ten’s digit identifies large differences in mandatory extensions (e.g., V, H) within the series

    • The one’s digit identifies small/medium differences in mandatory extensions (e.g., Zicond, PMP) within the series

  • <base> is optional and is 32 for RV32I, 64 for RV64I, and 32E for RV32E

    • If multiple bases are supported and <base> is omitted in a reference, the reference applies to all bases

    • If only one base is supported then <base> is generally omitted

1.3. Requirements Terminology

Table 3. Requirement Types
Term Meaning

MANDATORY

You have to implement it to get a certificate and the certificate tests will cover it

OPTIONAL

It’s up to you if you implement or not. If you claim to implement it, certificate tests will cover it

IN-SCOPE

Either MANDATORY or OPTIONAL

OUT-OF-SCOPE

It’s up to you if you implement or not. If you implement it, it won’t be certified but make sure you don’t mess up anything we are certifying.

INCOMPATIBLE

If you implement it you won’t get a certificate
Table 4. Requirement ID Naming
Term Meaning

REQ-<ID>

A requirement that applies to both RV32 and RV64

REQ32-<ID>

A requirement that applies to only RV32

REQ64-<ID>

A requirement that applies to only RV64

1.4. Related Specifications

2. Base ISA

Table 5. Base ISA Requirements
Requirement ID Description

REQ32-BASE

Uses the RV32I base integer ISA

REQ64-BASE

Uses the RV64I base integer ISA

REQ-ENDIANNESS

Only little-endian is supported

2.1. Exclusions

As per the unprivileged architecture specification, the ecall instruction causes a requested trap to the execution environment. Since the RVI profile family doesn’t define any execution environments the ecall instruction is OUT-OF-SCOPE for the RVI20 certificate.

Similarly the ebreak and c.ebreak instructions are OUT-OF-SCOPE for the RVI20 certificate since they cause a breakpoint exception and the RVI profile family doesn’t define any execution environments to handle such exceptions.

3. Extensions

Any RISC-V extensions not listed in this section are OUT-OF-SCOPE and the associated certificate doesn’t cover their behaviors.

Please refer to the Extension Definitions appendix for more information about the extensions listed in this section or click on the extension names in the table below to jump to their definitions.

Note that the syntax ~> for version numbers in the tables below means "version or later backwards-compatible version".

3.1. Mandatory Extensions

None

3.2. Optional Extensions

Table 6. Optional Extensions
Requirement ID Extension Version

REQ-EXT-A

A

~> 2.1

REQ-EXT-C

C

~> 2.0

REQ-EXT-D

D

~> 2.2

REQ-EXT-F

F

~> 2.2

REQ-EXT-M

M

~> 2.0

REQ-EXT-Zicntr

Zicntr

~> 2.0

REQ-EXT-Zifencei

Zifencei

~> 2.0

REQ-EXT-Zihpm

Zihpm

~> 2.0

3.3. Dependent Extensions

Table 7. Dependent Extensions
Requirement ID Extension Version Dependency

REQ-EXT-Zicsr

Zicsr

~> 2.0

Required if Zicntr or F extensions are present

4. Parameter Values

This section lists the parameters that are IN-SCOPE and OUT-OF-SCOPE for the RVI20 certificate.

Please refer to the Parameter Definitions appendix for more information about the parameters listed in this section or click on the parameter names in the table below to jump to their definitions.

4.1. IN-SCOPE Parameters

An implementation MUST abide by the "Allowed Value(s)" of IN-SCOPE parameters to obtain a certificate. If the "Allowed Value(s)" is "Any" then any value defined by the parameter is acceptable.

Table 8. IN-SCOPE Parameters
Parameter Allowed Value(s) Impact on Certificate Scope

HPM_COUNTER_SZ

Any

Only counters with a size of 0 are IN-SCOPE since the behavior of HPM counters is implementation-specific.

LRSC_RESERVATION_STRATEGY

Any

The load-reserved/store-conditional instructions are only IN-SCOPE if this parameter is not "Other"

MISALIGNED_LDST_HW_SUPPORT

Any

Misaligned load/store instructions are only IN-SCOPE if this parameter is true and if any restrictions on misaligned load/store instructions expressed by other parameters are met.

TIME_CSR_HW_SUPPORT

Any

Reading time-related CSRs is only IN-SCOPE if this parameter is true

4.2. OUT-OF-SCOPE Parameters

There are no restrictions on the values of OUT-OF-SCOPE parameters for certification purposes because the certificate doesn’t cover the behavior associated with the parameter.

Table 9. OUT-OF-SCOPE Parameters
Parameter

None

5. CSR WARL Fields

There are no CSRs in RVI20 with WARL fields.

6. CSR WLRL Fields

There are no CSRs in RVI20 with WLRL fields.

Appendix A: Extension Definitions

This appendix contains information about RISC-V extensions mentioned in this CRD.

A.1. Extension A

Long Name

Atomic Instructions

Description

Atomic instructions from the Zaamo and Zalrsc extensions

A.2. Extension C

Long Name

Compressed instructions

Description

Always includes Zca, includes Zcf if F is present (RV32 only), and includes Zcd if D is present

A.3. Extension D

Long Name

Double-Precision Floating-Point

Description

Double-precision floating-point instructions and CSRs. Requires F.

A.4. Extension F

Long Name

Single-Precision Floating-Point

Description

Single-precision floating-point instructions and CSRs

A.5. Extension M

Long Name

Multiply

Description

Integer multiply and divide instructions

A.6. Extension Zicntr

Long Name

Base Counters and Timers

Description

Base counters and timers including the time/timeh, cycle/cycleh, and instret/instreth CSRs.

A.7. Extension Zicsr

Long Name

Control and Status Register Instructions

Description

Instructions for reading and writing control and status registers.

A.8. Extension Zifencei

Long Name

Instruction Fence

Description

Instruction fence instructions and related CSRs.

A.9. Extension Zihpm

Long Name

Hardware Performance Counters

Description

The number of counters is platform-specific.

Appendix B: Parameter Definitions

Parameters are hardware options supported by RISC-V standards. Many parameters are not named in RISC-V standards but a golden list of parameters is maintained separately by RISC-V International and this section uses those names.

The golden list of parameters is still under development so the parameters in this document are "preliminary parameters" and subject to change as the golden list is finalized.

Parameters map to one or more normative rules in the RISC-V ISA manual. Typically these normative rules are the Implementation-Defined Behavior variant of normative rules. These are normative rules that allow for multiple behaviors and require the implementation to specify its behavior. By convention, Implementation-Defined Behaviors have uppercase names while other types of normative rules have lowercase names.

Table 10. Parameter Definitions

Parameter and Mapping to Normative Rules

Type

ISA Feature

Definition

HPM_COUNTER_SZ

Normative Rule(s):

Array[3:31] of Integer 0 to 64

Zicntr

Bit width of each implemented unprivileged hardware performance counter. A value of 0 indicates the corresponding counter is not implemented and will not trap if read.

LRSC_RESERVATION_STRATEGY

Normative Rule(s):

Enum (Exact, 64B, 128B, Other)

Atomic (Zalrsc extension)

Defines the reservation strategy for load-reserved/store-conditional (LR/SC) atomic instructions:

Value Definition

Exact

Reservation set is exactly enough to cover the access and no more

64B

Reservation set is naturally-aligned 64-byte region

128B

Reservation set is naturally-aligned 128-byte region

Other

Reservation set strategy doesn’t fit any of the specified choices

MISALIGNED_LDST_HW_SUPPORT

Normative Rule(s):

Boolean

RV32I/RV64I Base ISA

Hardware support for misaligned integer and floating-point load/store instructions.

Value Definition

False

No hardware support for misaligned load/store instructions

True

Misaligned load/store instructions are supported in hardware (potentially with restrictions expressed by other parameters).

TIME_CSR_HW_SUPPORT

Normative Rule(s):

Boolean

Zicntr

Implementation supports reading of all unprivileged time-related CSRs without triggering an exception. For RV31I the time and timeh CSRs are the unprivileged time-related CSRs. For RV64I the time CSR is the only unprivileged time-related CSR.