MC100 Certification Requirements Document (rev 0.3)

Contributors to all versions of the spec in alphabetical order

James Ball

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	0.3	Extension and Parameter appendices now only list things mentioned in the CRD. Changes to Sm extension definition in appendix: Clarified Unpriv shadow CSRs of M-mode CSRs (in their own table) Clarified that the c.ebreak instruction only exists if the C extension is present
Mar 9, 2026	0.2	The ecall, ebreak, and c.ebreak instructions are all IN-SCOPE (previously had them as exclusions incorrectly) Don’t use Smpmp term which is a made-up UDB extension name for the original PMP. Removed optional extensions not supported by tests (Zce and Smepmp)
Mar 3, 2026	0.1	Copied from RVI20 CRD rev 0.4 as a starting point What is left: Merge content from WARL/WLRL Legal Value Schema into the CSR field types section List each possible WARL/WLRL field and use the "WARL/WLRL Legal Value Schema" to assign the required behavior of WARL/WLRL fields in order to obtain a certificate Define additional parameters for extensions in MC100 not present in RVI20

Date

Revision

Changes

Mar 10, 2026

0.3

Extension and Parameter appendices now only list things mentioned in the CRD.
Changes to Sm extension definition in appendix:
- Clarified Unpriv shadow CSRs of M-mode CSRs (in their own table)
- Clarified that the c.ebreak instruction only exists if the C extension is present

Mar 9, 2026

0.2

The ecall, ebreak, and c.ebreak instructions are all IN-SCOPE (previously had them as exclusions incorrectly)
Don’t use Smpmp term which is a made-up UDB extension name for the original PMP.
Removed optional extensions not supported by tests (Zce and Smepmp)

Mar 3, 2026

0.1

Copied from RVI20 CRD rev 0.4 as a starting point
What is left:
- Merge content from WARL/WLRL Legal Value Schema into the CSR field types section
- List each possible WARL/WLRL field and use the "WARL/WLRL Legal Value Schema" to assign the required behavior of WARL/WLRL fields in order to obtain a certificate
- Define additional parameters for extensions in MC100 not present in RVI20

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 MC100-32 processor certificate is based on the RVI20U32 profile with the addition of M-mode. The MC100-64 processor certificate is based on the RVI20U64 profile with the addition of M-mode.

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. CSR Field Types

The RISC-V ISA defines CSR field specifications that require special handling by the certification tests. This includes determining the read value after writing an illegal value, and whether or not writing an unsupported value to a specific field creates an illegal instruction exception. This special handling is summarized in the table below and detailed in the sub-sections following the table.

Table 5. Definition of CSR Fields
Field Type	Read Value After Writing Illegal Value	Read Value Function Of	Illegal Instruction Exception	Priv ISA Manual Quote
WARL	Any deterministic legal value	Any architectural hart state	Prohibited	Implementations MUST NOT raise an exception on writes of unsupported values to a WARL field. Implementations MUST return any legal value on the read of a WARL field when the last write was of an illegal value, and the legal value returned MUST deterministically depend on the illegal written value and the architectural state of the hart.
WLRL	Any deterministic legal or illegal value	Value before write and illegal value written	Optional	Implementations MAY raise an illegal-instruction exception if an instruction attempts to write a non-supported value to a WLRL field. Implementations MAY return arbitrary bit patterns on the read of a WLRL field when the last write was of an illegal value, but the value returned MUST deterministically depend on the illegal written value and the value of the field prior to the write.
WPRI	0	Nothing	Not specified	Some whole read/write fields are reserved for future use. Implementations that do not furnish these fields MUST make them read-only zero.

1.4.1. WARL (Write Anything, Read Legal)

The Priv ISA requires reads of WARL fields to return some implementation-dependent deterministic legal value after the field is written with an illegal value. Certifying such behaviors is expensive and provides low value for a certificate since software can’t rely on a particular behavior from one implementation to another.

Processor CRDs define writes to WARL fields of illegal values to be OUT-OF-SCOPE unless otherwise stated (i.e., certification tests will only ever write legal values to WARL fields except for the special cases listed below). When not OUT-OF-SCOPE, the required behavior is defined as this might be more constrained in implementations than in the standard.

The following special cases for WARL are supported when explicitly listed in the corresponding CRD CSR field requirements:

Probing for Field Width
- Some WARL fields are variable length such as the ASID field in the virtual memory extension.
- Here’s the algorithm recommended to discover the ASID width:
  - The number of implemented ASID bits, termed ASIDLEN, can be determined by writing one to every bit position in the ASID field, then reading back the value in the satp CSR to see which bit positions in the ASID field hold a one.
- The RVCP-provided certification materials (certification tests, certification reference models) can map writes of illegal values to the ASID field to the corresponding read value as long as they are provided the ASIDLEN value for an implementation.
Probing for Options
- E.g., Writable misa bits
Allowed values are a function of extension presence and/or their parameters
- E.g., satp.mode legal write values

1.4.2. WLRL (Write Legal, Read Legal)

The Priv ISA requires reads of WLRL fields to return some implementation-dependent deterministic arbitrary value after the field is written with an illegal value. Certifying such behaviors is expensive and provides low value for a certificate since software can’t rely on a particular behavior. Processor CRDs define writes to WLRL fields of illegal values to be OUT-OF-SCOPE unless otherwise stated (i.e., certification tests will only ever write legal values to WLRL fields).

1.4.3. WPRI (Write Preserve, Read Ignore)

The Priv ISA requires reads of WPRI fields to return a value of 0. Such WPRI fields are always unimplemented by definition. Certification tests are aware of which fields in the CSRs are WPRI and normally write them with 0 but will also write them with ~0 (all ones) and ensure that reads return 0 in both cases. It is OUT-OF-SCOPE for certification tests to write all possible values of WPRI fields (especially if they are more than just a few bits) and certification tests aren’t intended to be comprehensive verification test suites anyways.

1.5. Related Specifications

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

2. Base ISA

Table 6. 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

None

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

Table 7. Mandatory Extensions
Requirement ID	Extension	Version
REQ-EXT-C	C	~> 2.0
REQ-EXT-Zicsr	Zicsr	~> 2.0
REQ-EXT-Sm	Minimal Machine Mode	~> 1.13

3.2. Optional Extensions

Table 8. Optional Extensions
Requirement ID	Extension	Version
REQ-EXT-A	A	~> 2.1
REQ-EXT-M	M	~> 2.0
REQ-EXT-Zicntr	Zicntr	~> 2.0
REQ-EXT-Zifencei	Zifencei	~> 2.0
REQ-EXT-Zihpm	Zihpm	~> 2.0

4. Parameter Values

This section lists the parameters that are IN-SCOPE and OUT-OF-SCOPE for the MC100 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 9. 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.
MISALIGNED_ATOMICITY_GRANULE_SIZE	Any	Zero Misaligned AMO instructions are OUT-OF-SCOPE. Non-zero Misaligned AMO atomic instructions and misaligned load/store instructions are IN-SCOPE if within the NAPOT byte region assuming that any restrictions on misaligned supported 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 10. OUT-OF-SCOPE Parameters
Parameter
TBD

5. CSR WARL Fields

TBD

6. CSR WLRL Fields

TBD

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 Sm

Long Name: Minimal Machine Mode
Description: All Machine-mode features defined as mandatory by the RISC-V Privileged Architectures specification.

Table 11. RV32/64 mandatory CSRs (many can be read-only zero)
CSR name	Normative rule defining CSR as mandatory	Notes
misa	misa_always_rd
mvendorid	mvendorid_always_rd
marchid	marchid_always_rd
mimpid	mimpid_always_rd
mhartid	mhartid_always_rd
mstatus	mstatus_acc	closest rule requiring CSR to be implemented, seems implicitly required
mtvec	mtvec_mandatory
mip	mip_acc	closest rule requiring CSR to be implemented, seems implicitly required
mie	mie_acc	closest rule requiring CSR to be implemented, seems implicitly required
mcycle	m_mode_perf_monitoring
minstret	m_mode_perf_monitoring
mhpmcounter3-mhpmcounter31	mhpmcounter_mandatory
mscratch	mscratch_sz_acc	closest rule requiring CSR to be implemented, seems implicitly required
mepc	mepc_op	closest rule requiring CSR to be implemented, seems implicitly required
mcause	mcause_op	closest rule requiring CSR to be implemented, seems implicitly required
mtval	mtval_op	closest rule requiring CSR to be implemented, seems implicitly required
mconfigptr	mconfigptr_mandatory

Table 12. RV32/64 read-only shadows of M-mode CSRs
Shadow CSR	M-mode CSR	Normative rule defining shadow	Notes
cycle	mcycle	cycle_op	read-only shadow of mcycle[31:0]
time	mtime	time_op	read-only shadow of mtime[31:0] memory-mapped register, only exists if TIME_CSR_HW_SUPPORT parameter is true
instret	minstret	instret_op	read-only shadow of minstret[31:0]
hpmcounter3-hpmcounter31	mhpmcounter3-mhpmcounter31	hpmcounter_op	read-only shadow of mhpmcounter3[31:0]-mhpmcounter31[31:0]

Table 13. Additional RV32-only mandatory CSRs (many can be read-only zero)
CSR name	Normative rule defining CSR as mandatory	Notes
mstatush	mstatush_acc	Mentioned as mandatory in the Priv ISA manual "Preface to Version 20211203"
mcycleh	mcycleh_op
minstreth	minstreth_op
mhpmcounter3h-mhpmcounter31h	mhpmcounterh_op

Table 14. Additional RV32-only read-only shadows of M-mode CSRs
Shadow CSR	M-mode CSR	Normative rule defining shadow	Notes
cycleh	mcycleh	cycle_op	read-only shadow of mcycle[63:32]
timeh	mtimeh	time_op	read-only shadow of mtime[63:32] memory-mapped register, only exists if TIME_CSR_HW_SUPPORT parameter is true
instreth	minstreth	instret_op	read-only shadow of minstret[63:32]
hpmcounterh3-hpmcounterh31	mhpmcounterh3-mhpmcounterh31	hpmcounter_op	read-only shadow of mhpmcounter3[63:32]-mhpmcounter31[63:32]

Table 15. Memory-mapped registers (not CSRs)
Register name	Normative rule defining register as mandatory	Notes
mtime	mtime_acc
mtimecmp	mtimecmp_sz

Table 16. Instructions
Instruction name	Normative rule defining operation	Notes
ecall	ecall_op
ebreak	ebreak_op
c.ebreak	c-ebreak_op	Only present when the C extension is present
mret	mret_presence
wfi	wfi_op

Table 17. PMAs (Physical Memory Attributes)
PMA	Normative rule or Implementation-defined behavior
Main-memory PMAs	pma_mm_vs_io_def
Support read and write of all access widths required by the attached devices	pma_mm_rw
Support instruction fetch if PMA_MM_IFETCH is true for the PMA region	PMA_MM_IFETCH
Support atomics if PMA_CACHE_MM_ALL_ATOMICS is true for the PMA region	PMA_CACHE_MM_ALL_ATOMICS
AMO support levels	pma_amo_levels
Size support per AMO level	pma_amo_sz_support

A.7. Extension Zicntr

Long Name: Base Counters and Timers
Description: Base counters and timers including the time/timeh, cycle/cycleh, and instret/instreth CSRs.

A.8. Extension Zicsr

Long Name: Control and Status Register Instructions
Description: Instructions for reading and writing control and status registers.

A.9. Extension Zifencei

Long Name: Instruction Fence
Description: Instruction fence instructions and related CSRs.

A.10. 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.

Parameter and Mapping to Normative Rules

Type

ISA Feature

Definition

HPM_COUNTER_SZ

Normative Rule(s):

HPM_PLATFORM_SPECIFIC_IMPL

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):

LR_RESERVATION_SET_SIZE

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):

MISALIGNED_LDST_HW_SUPPORT

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).

MISALIGNED_ATOMICITY_GRANULE_SIZE

Normative Rule(s):

MISALIGNED_ATOMICITY_GRANULE_SIZE

Integer

Atomic

See normative rule

TIME_CSR_HW_SUPPORT

Normative Rule(s):

EE_IMPL_FLEX

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.