Una plataforma de servidor RISC-V necesita mucho más que núcleos compatibles: también debe integrar temporización, interrupciones, acceso controlado a dispositivos, PCIe, gestión y seguridad. La especificación Server SoC Requirements v1.0 de RISC-V International establece requisitos obligatorios, recomendaciones y condiciones para esos componentes del sistema en chip (SoC).
La cobertura de NeoTeo sobre las fechas de la cumbre RISC-V de Shenzhen aporta contexto sobre el encuentro; la especificación aborda una cuestión distinta: qué capacidades debe reunir el SoC de un servidor.
Qué fuerza tiene cada disposición
La especificación distingue entre MUST, que indica una obligación, y SHOULD, que expresa una recomendación. Algunas obligaciones dependen de las funciones que implemente el SoC: si incorpora una interfaz o un componente determinado, también debe cumplir los requisitos asociados a esa opción.
| Área | Disposición | Carácter |
| Temporización | El registro time usa unidades de 1 ns y se actualiza a una frecuencia constante de al menos 100 MHz. | MUST |
| Interrupciones | Se exige AIA y las interrupciones externas deben usar MSI. | MUST |
| IOMMU | Los periféricos con DMA y los puertos raíz PCIe accesibles por software deben quedar bajo una IOMMU, con excepciones especificadas. | MUST, con excepciones |
| PCIe | Los componentes aplicables deben cumplir las reglas visibles por software de PCIe Specification 6.0; los puertos raíz deben admitir AER, DPC y controles RP PIO. | MUST |
| Fiabilidad y calidad de servicio | Se recomiendan capacidades RAS, mecanismos de QoS y monitorización del rendimiento; algunas obligaciones dependen de las funciones implementadas. | SHOULD y requisitos condicionales |
| Seguridad | La raíz de confianza de hardware debe ser la raíz principal de confianza. | MUST |
La norma completa, Server SoC Requirements v1.0, cubre también gestión y otros requisitos de seguridad. La tabla resume disposiciones representativas; los detalles dependen del subsistema y, en algunos casos, de las opciones de diseño.
Temporizadores e interrupciones
El registro time debe avanzar en unidades de 1 nanosegundo y actualizarse a una frecuencia constante de al menos 100 MHz. También debe permanecer activo y conservar su cuenta durante los estados de bajo consumo de los harts, salvo estados de energía del sistema como G3, S3 y S4.
Para las interrupciones, el SoC debe admitir la RISC-V Advanced Interrupt Architecture (AIA) y entregar las interrupciones externas mediante MSI, es decir, interrupciones señalizadas por mensajes. Cada hart debe disponer de al menos un archivo de interrupciones IMSIC en modo S y cinco en modo VS. El archivo S debe admitir al menos 255 identidades de interrupción; cada archivo VS, al menos 63.
Si el SoC implementa dispositivos que generan interrupciones por señal eléctrica, debe incluir un APLIC que las convierta en MSI, sujeto a las condiciones que fija la especificación. Así, el diseño de interrupciones no termina en el procesador: también abarca cómo el sistema entrega y enruta esos eventos.
IOMMU y PCIe: controlar el acceso a los dispositivos
Una IOMMU debe gobernar los periféricos capaces de realizar acceso directo a memoria (DMA) y los puertos raíz PCIe accesibles por software. La especificación exceptúa, entre otros, controladores de interrupciones, las propias IOMMU, ciertos bloques del módulo de depuración y controladores de gestión cuando acceden a recursos reservados para su uso. No fija un número de IOMMU para el SoC.
Todas las IOMMU deben admitir la especificación RISC-V IOMMU. La que gobierna un puerto raíz PCIe debe admitir identificadores de dispositivo de al menos 16 bits y todos los modos y extensiones de memoria virtual basados en páginas que implementen los harts de aplicación del SoC.
En el root complex PCIe, los puertos raíz, los puentes de host y los componentes RCRB y RCEC aplicables deben implementar las reglas de PCIe Specification 6.0 que sean visibles por software. Se requiere MSI y no se debe admitir señalización de interrupciones virtuales INTx. Los puertos raíz también deben admitir AER, DPC y controles RP PIO.
RAS, QoS, gestión y monitorización
La especificación no fija un nivel general obligatorio de RAS, sigla de fiabilidad, disponibilidad y capacidad de servicio. Sí recomienda que el SoC pueda generar, almacenar y reenviar datos envenenados, y que admita RERI, la interfaz de registros de errores de RISC-V. Si se implementa RERI, se aplican requisitos adicionales para el registro y la comunicación de errores. También se recomienda detección y corrección de errores en memorias y cachés importantes, ECC de símbolo único en los controladores DRAM y limpieza periódica de memoria.
Para reducir interferencias injustificadas entre cargas de trabajo que comparten cachés y memoria, se recomiendan mecanismos de QoS. CBQRI y los controles asociados de capacidad de caché y ancho de banda de memoria son opciones recomendadas; si se implementa CBQRI, entran en juego requisitos adicionales.
En gestión, la norma recomienda compatibilidad con protocolos como Redfish, PLDM, MCTP y los relacionados con SPDM. También recomienda una conexión de gestión BMC mediante un enlace PCIe x1, preferiblemente Gen 5 y como mínimo Gen 3, además de IPMI SSIF sobre I2C y una conexión UART para consola de depuración. Son recomendaciones para la conexión del BMC, no una velocidad PCIe mínima general para todo el SoC.
Los contadores HPM en cachés importantes, controladores de memoria y puertos PCIe también son recomendados. En sistemas NUMA, se recomienda además poder filtrar las mediciones para distinguir accesos locales y remotos.
Seguridad: obligación y capacidades recomendadas
La raíz de confianza de hardware debe ser la raíz de confianza principal del SoC. En cambio, la especificación recomienda PCIe IDE, el cifrado de DRAM externa con una clave transitoria de al menos 256 bits y una interfaz para un TPM conforme a TPM 2.0.
Esta diferencia ayuda a leer cualquier diseño frente a la norma: una función recomendada no tiene el mismo carácter que una obligación MUST, y una cifra de núcleos no responde por sí sola a los requisitos del sistema. Server SoC Requirements v1.0 define las condiciones de la plataforma; cada SoC debe evaluarse frente a ellas.