A RISC-V server platform includes a RISC-V application processor and may include one or more service processors. These service processors may provide services such as security and power management to software executing on the application processors, and they may themselves implement the RISC-V ISA. The requirements in this section apply solely to harts in the application processors of the SoC.
ID# | Requirement |
---|---|
|
The RISC-V application processor harts in the SoC MUST support the RVA23 ISA profile cite:[RVA23]. |
The next major release of the profiles is expected to be RVA24, which is still under construction. This specification should be updated to comply with the RVA24 profiles as the profile definition becomes more finalized. |
|
|
The RISC-V application processor harts in the SoC MUST support the following extensions:
|
Ssccfg, Sscind, and Ssctr are under construction. |
|
|
The ISA extensions and associated CSR field widths implemented by any of the RISC-V application processor harts in the SoC MUST be identical. |
The RVA23 profile supports a set of optional extensions. The set of optional extensions implemented by the harts must be identical. Where the extension supports optionality in the form of field widths (e.g., ASIDLEN, VLEN, allowed vstart values, physical address width, debug triggers, cache-block size, etc.), the implementation of these must also be identical. Having an identical ISA on all harts allows system software to migrate tasks among the harts without constraints. |
|
|
The RISC-V application processor harts in the SoC MAY support different power and performance characteristics but MUST be otherwise indistinguishable from each other from a software execution viewpoint. |
All harts in the SoC being indistinguishable from a software execution viewpoint allows system software to migrate tasks among the harts without constraints. |
|
|
The RISC-V application processor hart MUST support:
|
|
The RISC-V application processor hart MUST support:
|
|
The RISC-V application processor MUST support at least 6 hardware performance counters defined by the Zihpm extension in addition to the three counters defined by Zicntr extension. |
ID# | Requirement |
---|---|
|
The RISC-V SoC MUST comply to the Server SoC specification cite:[ServerSoC]. |
The Server SoC specification is still under construction. This specification should be updated once the specification versioning info is finalized. |
|
|
All peripherals that are intended for assignment to a VM or a user space device driver must be PCIe devices or be compliant to rules for SoC-integrated PCIe devices (cite:[ServerSoC, Section 2.5.11). |
ID# | Requirement |
---|---|
|
For remote-access and system engineering purposes, a fully 16550-compatible cite:[NS16550] UART MUST be implemented. |
This is a stronger requirement than the Server SoC |
|
|
The implemented UART MUST support:
|
|
If a USB controller is implemented, it MUST comply to XHCI 1.2 or later cite:[XHCI]. |
|
Implemented XHCI controllers must:
|
|
If a SATA controller is implemented, it must comply to AHCI 1.3.1 or later cite:[AHCI]. |
|
Implemented AHCI controllers must:
|
|
A battery-backed RTC or analogous timekeeping mechanism MUST be implemented. |
ID# | Requirement |
---|---|
|
The RISC-V SoC MUST comply to the BRS-I recipe described in the Boot and Runtime Service specification cite:[BRS]. |
The Boot and Runtime Services specification is still under construction. This specification should be updated once the specification versioning info is finalized. |
|
|
MUST include the ability to boot from disk (block) and network (PXE, HTTP) devices. |
Security requirements straddle hardware and firmware.
TBD: it is expected the high-level RoT / boot flow requirements will come from the platform security spec.
ID# | Requirement |
---|---|
|
MUST implement UEFI Secure Boot and Driver Signing (cite:[UEFI] Section 32) |
|
MUST back the UEFI Authenticated Variables implementation with a mechanism that cannot be accessed or tampered by an unauthorized software or hardware agent. |
|
MUST implement in-band firmare updates as per cite:[BRS]. |
|
Firmware update payloads must be digitally signed. |
|
Firmware update signatures need to be validated before being applied. |
|
It should not be possible to bypass secure boot, authentication or digital signature failures. |