Ein RISC-V-Server braucht mehr als kompatible Prozessorkerne: Die Spezifikation Server SoC Requirements v1.0 von RISC-V International macht Vorgaben für Timer, Interrupts, Gerätezugriffe, PCIe, Verwaltung und Sicherheit. Sie unterscheidet verbindliche Anforderungen mit MUST von Empfehlungen mit SHOULD; manche Anforderungen gelten nur, wenn eine bestimmte Funktion umgesetzt wird. Das ist wichtig, weil ein RISC-V-Kern allein noch keine Aussage darüber erlaubt, ob ein komplettes Server-SoC die Plattformvorgaben erfüllt.
Was die Server-SoC-Spezifikation abdeckt
Ein SoC (System-on-Chip) bündelt zentrale Funktionen eines Systems auf einem Chip. Für Server reicht die Spezifikation von RISC-V International über den Prozessorkern hinaus: Sie behandelt unter anderem Timer, Interrupts, IOMMU, PCIe, Zuverlässigkeit und Wartbarkeit (RAS), die Aufteilung von Ressourcen zwischen Arbeitslasten (QoS), Verwaltung, Leistungsüberwachung und Sicherheit. Die vollständigen Vorgaben stehen in Server SoC Requirements v1.0.
MUST kennzeichnet eine verbindliche Vorgabe. SHOULD bezeichnet eine Empfehlung. Bei bedingten Anforderungen hängt die Pflicht davon ab, ob das SoC die betreffende Funktion oder Schnittstelle implementiert. Für die Bewertung zählt daher nicht nur, welche Funktionen vorhanden sind, sondern auch, welche Vorgaben für genau diese Umsetzung gelten.
| Systembereich | Vorgabe | Verbindlichkeit und Geltungsbereich |
| Timer | Das time-CSR verwendet Einheiten von 1 ns und aktualisiert sich mit mindestens 100 MHz. | MUST; muss im Leerlauf eines Harts weiterlaufen, mit Ausnahmen für G3, S3 und S4. |
| Interrupts | Unterstützung der AIA und MSI für externe Interrupts; Mindestumfang für IMSIC-Dateien und Interrupt-Identitäten. | MUST; die Mindestwerte hängen vom Betriebsmodus ab. |
| Gerätezugriffe | DMA-fähige Peripheriegeräte und softwarezugängliche PCIe-Root-Ports müssen einer IOMMU unterstehen. | MUST, mit ausdrücklich genannten Ausnahmen. |
| PCIe | Geltende softwareseitig sichtbare PCIe-6.0-Regeln sowie MSI; Root-Ports müssen AER, DPC und RP-PIO-Steuerungen unterstützen. | MUST für die jeweils anwendbaren Komponenten und Vorgaben. |
| Zuverlässigkeit, Verwaltung und QoS | Unter anderem Empfehlungen zu Fehlerdaten, Ressourcensteuerung, Verwaltungsprotokollen und Leistungszählern. | Größtenteils SHOULD oder abhängig von implementierten Funktionen. |
| Sicherheit | Eine Hardware-Root-of-Trust muss die primäre Vertrauensbasis bilden. | MUST; weitere genannte Sicherheitsfunktionen sind Empfehlungen. |
Timer und Interrupts für Betriebssysteme und Virtualisierung
Das time-CSR muss in Schritten von 1 Nanosekunde zählen und sich mit einer konstanten Frequenz von mindestens 100 MHz aktualisieren. Es muss als ständig aktiv erscheinen und seinen Zählerstand während des Low-Power-Idle-Zustands eines Harts behalten. Für die Systemzustände G3, S3 und S4 gelten Ausnahmen.
Bei Interrupts verlangt die Spezifikation die RISC-V Advanced Interrupt Architecture (AIA). Externe Interrupts müssen als Message-Signaled Interrupts (MSI) zugestellt werden. Ein IMSIC muss pro Hart mindestens eine Interrupt-Datei für den S-Modus und fünf für den VS-Modus bereitstellen. Die S-Modus-Datei muss mindestens 255 Interrupt-Identitäten unterstützen; jede VS-Modus-Datei mindestens 63.
Setzt ein SoC Geräte mit drahtgebundenen Interrupts ein, muss es unter den dafür genannten Bedingungen einen APLIC implementieren. Dieser wandelt solche Interrupts in MSI um. Die Vorgabe gilt also für diese Implementierung, nicht pauschal für jedes SoC.
IOMMU und PCIe regeln den Gerätezugriff
Die IOMMU-Vorgaben betreffen DMA-fähige Peripheriegeräte und softwarezugängliche PCIe-Root-Ports. DMA ermöglicht einem Gerät, Daten direkt im Speicher zu übertragen. Solche Geräte müssen grundsätzlich einer IOMMU unterstehen, die Zugriffe nach den Vorgaben der RISC-V-IOMMU-Spezifikation behandelt. Genannte Ausnahmen umfassen unter anderem Interrupt-Controller, IOMMUs selbst, bestimmte Debug-Modul-Blöcke sowie Verwaltungscontroller, sofern sie auf für sie reservierte Ressourcen zugreifen. Eine feste Anzahl von IOMMUs schreibt die Spezifikation nicht vor.
Für die softwareseitig sichtbaren Komponenten des PCIe-Root-Complex gelten die einschlägigen Regeln der PCIe-Spezifikation 6.0. Das macht jedoch nicht automatisch jede optionale PCIe-6.0-Funktion zur Pflicht. MSI muss unterstützt werden, INTx-Interruptsignalisierung über virtuelle Leitungen darf nicht unterstützt werden. PCIe-Root-Ports müssen außerdem AER für erweiterte Fehlerberichte, DPC für die Eindämmung von Fehlern und RP-PIO-Steuerungen unterstützen.
RAS, QoS und Verwaltung: teils Empfehlungen, teils Bedingungen
Die Spezifikation schreibt kein einheitliches RAS-Niveau vor. Sie empfiehlt, fehlerhafte Daten zu markieren, zu speichern und weiterzuleiten sowie die RISC-V Error Record Register Interface (RERI) zu unterstützen. Werden bestimmte Funktionen wie RERI implementiert, greifen zusätzliche verbindliche Vorgaben. Auch Fehlerkorrektur für wichtige Caches und Speicher, Single-Symbol-ECC in DRAM-Controllern sowie regelmäßiges Scrubbing werden empfohlen.
Für QoS soll ein SoC unbegründete gegenseitige Beeinträchtigungen von Arbeitslasten verringern, wenn diese Cache und Systemspeicher gemeinsam nutzen. CBQRI und verwandte Möglichkeiten zur Steuerung von Cache-Kapazität und Speicherbandbreite sind Empfehlungen; weitere MUST-Vorgaben greifen, wenn CBQRI unterstützt wird.
Bei der Verwaltung empfiehlt die Spezifikation unter anderem Unterstützung für Redfish, PLDM, MCTP und SPDM. Ebenfalls empfohlen sind eine BMC-Anbindung über eine x1-PCIe-Lane, vorzugsweise Gen 5 und mindestens Gen 3, eine I2C-basierte IPMI-SSIF-Verbindung sowie ein UART-Debuganschluss. Diese Angaben beschreiben die empfohlene BMC-Anbindung, keine allgemeine PCIe-Mindestanforderung für jedes SoC. Leistungszähler für wichtige Caches, Speichercontroller und PCIe-Ports sowie Messungen der mittleren Speicherzugriffslatenz sind ebenfalls Empfehlungen. Bei NUMA-Systemen empfiehlt die Spezifikation zusätzlich eine Unterscheidung zwischen lokalem und entferntem Speicherzugriff.
Sicherheit: Root of Trust ist Pflicht
Die primäre Vertrauensbasis muss eine Hardware-Root-of-Trust sein. PCIe IDE, eine Verschlüsselung des externen DRAM mit einem temporären Schlüssel von mindestens 256 Bit und eine Schnittstelle zu einem TPM nach TPM 2.0 sind dagegen Empfehlungen. Diese Unterscheidung ist für die Plattformbewertung entscheidend: Die Root of Trust gehört zu den verbindlichen Vorgaben, die genannten zusätzlichen Sicherheitsfunktionen zum empfohlenen Umfang.
