The CPU Intensive test results displayed at RV-Zurich can be found in the following locations:
The goal of this effort is to develop a specification for a server-class RISC-V processor; there are three classes of server of interest which share common goals but may have different configuration profiles and extensions:
Datacenter analytic (HTC) server
Cloud virtualization server
HPC compute server
This work will evaluate the requirements of all three server classes and identify the key aspects required (above and beyond a basic processor) to provide server-class capabilities. It should comprehend existing capabilities within the RISC-V community as well as independent RISC-V research by other academic and industry research efforts (that are publicly available) so as to avoid reinventing anything that would be suitable either as-is or with manageable extensions or modifications.
Capabilities of interest include:
Extended address space (sv39 / sv48 or 128b such as -Xbgas)
Extended compute (128b state, additional I&F operations, encryption/decryption operations/engines, ...)
Appropriate extensions (Q, L, B, J, T, P, V, ... and custom as required)
Capabilities (like Cheri)
RAS (enhanced hardware and monitoring/tracking infrastructure)
Hardware abstraction layer API/ABI (Itanium PAL and SAL)
Memory Protection (buffer overflow, bounds checking, ...)
The outcome of this work is a detailed report providing details for each server class configuration profile including required features; this report should include appropriate specification changes for existing features and reasonably-detailed architecture specifications for new or alternative features.
The specific work items are as follows:
1. Define required capabilities for server-class architectures including:
a. Datacenter analytic server
b. Cloud virtualization server
c. HPC compute server
2. Starting with the standard RISC-V RV64 architecture (user mode and system, including optional and known custom extensions), determine any existing capabilities that would support the requirements for these architectures as well as any gaps that will need additional definition, either exposed (hardware: additional operations and state) or hidden (accessible through a software abstraction layer: privileged API/ABI).
a. Gaps in existing capabilities that are incomplete and can be reasonably extended (or note where existing capabilities are in the way and may require workarounds to avoid incompatibilities with required new capabilities) e.g. addition of new operations such as SAG and centrifuge within existing bit-manipulation capabilities.
b. Gaps where there are no suitable existing capabilities to use as a starting point and which require completely new extensions e.g. hardware-abstraction interface, 128b three-operation instruction bundles
c. Gaps that require non-RISC-V IP - e.g. high-performance memory or interconnect blocks, encryption/decryption engines, TPM modules, etc.
3. Develop specifications for any gaps and estimate consequences, complexity, and cost for these additions.
a. Consequences (and compatibility):
- additional context-switch state (fixed or variable), new instruction formats, incompatibilities with the standard architecture or optional additions or extensions (whether in the RISC-V architecture specification or from known outside work).
- design time, validation effort
- area, power (static and dynamic), and timing (critical path)