RISC-V server readiness depends on the complete system-on-chip (SoC), not just compatible processor cores. RISC-V International’s Server SoC Requirements v1.0 sets provisions for timers, interrupts, device access, PCIe, reliability, management, performance monitoring and security, with each clause marked mandatory, recommended or conditional. The requirements give readers a way to assess the platform side of RISC-V alongside broader industry developments, including the RISC-V China Summit in Shenzhen, covered by NeoTeo.
What the server SoC requirements cover
The specification applies to system-level behavior and components exposed to software. Its formal terms matter: MUST marks a requirement, SHOULD marks a recommendation, and some requirements apply only when a system implements a particular interface or feature. A recommendation and a conditional requirement are not the same as a universal MUST.
The official Server SoC Requirements v1.0 covers the following areas:
| System area | Provision | Force or condition | Platform significance |
| Timers and interrupts | Defined timer behavior; AIA and message-signaled interrupts (MSI) | MUST | Supports predictable system time and interrupt delivery. |
| IOMMU and PCIe | IOMMU governance for covered devices and root ports; software-visible PCIe rules and controls | MUST, with specified exceptions and applicable-component scope | Sets requirements for device access and the PCIe root complex. |
| Reliability and serviceability | Error-data poisoning, RERI and error correction capabilities | Generally SHOULD; some requirements apply if RERI is implemented | Recommends ways to detect, record and handle errors without setting one universal RAS level. |
| QoS, management and monitoring | Workload-isolation mechanisms, management interfaces and HPM counters | Generally SHOULD or conditional | Recommends platform tools for managing and observing server workloads. |
| Security | Hardware root of trust as the primary root of trust | MUST; other named security capabilities are SHOULD | Establishes one mandatory security foundation and additional recommendations. |
Timer and interrupt thresholds
The time CSR must advance in 1-nanosecond units at a constant frequency of at least 100 MHz. It must remain available and retain its count during hart low-power idle states, with stated exceptions for system power states G3, S3 and S4.
The SoC must support the RISC-V Advanced Interrupt Architecture (AIA), and external interrupts must use MSI. For each hart, the IMSIC must provide at least one S-mode interrupt file and at least five VS-mode interrupt files. Each S-mode file must support at least 255 interrupt identities, while each VS-mode file must support at least 63.
These are minimums for the interrupt architecture, not processor-performance measurements. If a SoC implements devices that use wire-signaled interrupts, it must use an APLIC to convert those interrupts to MSI, subject to the specification’s stated conditions.
IOMMU coverage and PCIe behavior
A RISC-V IOMMU must govern DMA-capable peripherals and software-accessible PCIe root ports, subject to listed exceptions. Those exceptions include interrupt controllers, IOMMUs, certain debug-module blocks, and management controllers accessing resources reserved for their use. The specification does not set a required number of IOMMUs.
Applicable software-visible components in the PCIe root complex must follow the relevant rules in PCIe Specification 6.0. That scope does not make every optional PCIe capability mandatory. The specification requires PCIe MSI and prohibits INTx virtual-wire interrupt signaling. PCIe root ports must also support AER, DPC and RP PIO controls.
For an architecture review, the useful question is whether each covered device and root port has the required IOMMU governance, and whether the applicable root-complex components meet their software-visible and error-control provisions. A core count by itself answers neither question.
Reliability, workload isolation and management
The specification sets no single mandatory level of reliability, availability and serviceability (RAS). It recommends support for generating, storing and forwarding poisoned data, as well as the RISC-V Error Record Register Interface (RERI). If RERI is implemented, certain error-reporting and record behaviors become mandatory. Error detection and correction for significant caches and memories, single-symbol ECC in DRAM controllers, and periodic or patrol scrubbing are also recommendations.
For quality of service (QoS), the SoC should include mechanisms to reduce unjustified interference among workloads that share caches and system memory. Cache-capacity and memory-bandwidth controls, including CBQRI, are recommended; further MUST provisions apply if CBQRI is supported.
Management and monitoring provisions are largely recommendations. The specification recommends support for Redfish, PLDM, MCTP and SPDM-related protocols. It also recommends a BMC connection over an x1 PCIe lane, preferably Gen 5 and at least Gen 3, plus I2C-based IPMI SSIF and a UART debug-console connection. Those lane generations describe the recommended BMC connection, not a universal minimum PCIe generation for the SoC.
HPM counters in significant caches, memory controllers and PCIe ports are recommended, as is monitoring average memory-request latency. For NUMA-capable systems, local-versus-remote filtering is also recommended.
Security: one mandatory foundation
A hardware root of trust must be the SoC’s primary root of trust. The specification separately recommends PCIe IDE, off-chip DRAM encryption with a transient key of at least 256 bits, and an interface to a TPM conforming to TPM 2.0.
That distinction gives platform reviews a concrete starting point: check the mandatory root-of-trust provision, then evaluate the recommended security capabilities as separate design choices. Server SoC Requirements v1.0 defines provisions for a platform; it does not certify a particular chip against them.
