Una de las grandes ventajas de la arquitectura RISC-V, y al mismo tiempo uno de sus desafíos, es la posibilidad de agregar instrucciones a medida. Sumarlas a un núcleo permite hacer un sistema más seguro o mejorar el rendimiento en áreas como la criptografía y la inteligencia artificial en el borde. Pero esas mismas instrucciones cargan el riesgo de la fragmentación, con núcleos que terminan siendo incompatibles entre sí.
¿Cuáles son las extensiones básicas?
Sobre los núcleos base RV32I y RV64I hay tres extensiones embebidas de uso habitual:
| Extensión | Qué hace | Efecto medido |
|---|---|---|
| C (instrucciones comprimidas) | agrega variantes de 16 bits de instrucciones comunes de 32 bits | reduce el tamaño del código entre 15% y 30% |
| E (registros reducidos) | baja de 32 a 16 registros enteros en RV32E | menos área de silicio y menor sobrecarga de cambio de contexto |
| M (multiplicación y división enteras) | soporte por hardware en vez de rutinas de software | ejecución en uno o pocos ciclos |
La reducción de código de la extensión C es crítica cuando el presupuesto de memoria flash y ROM dentro del chip es ajustado, que es la situación normal en un microcontrolador de bajo costo.
¿Qué aportan las extensiones vectoriales?
La extensión vectorial de RISC-V deja que el diseñador elija longitudes de registro de entre 128 y 2.048 bits, de modo que el área de silicio escala con los requisitos de precisión de la carga de trabajo. El último procesador de borde de Google usa estas extensiones para recortar la latencia de inferencia en un 34% frente a otros diseños embebidos.
El acelerador europeo EPAC 1.0 combina núcleos de control RISC-V con bloques específicos de inteligencia artificial y alcanza 12 TOPS por vatio, una cifra que confirma que las arquitecturas de instrucciones abiertas pueden convivir con restricciones de batería en robótica y sistemas autónomos. Los fabricantes automotrices siguen el mismo camino para monitoreo del conductor dentro de la cabina, porque la inferencia vectorizada acelera el trabajo dentro de los presupuestos estrictos de la norma ISO 26262 y sin pagar las regalías altas de los proveedores propietarios.
¿Cuánto vale el mercado RISC-V?
El mercado de tecnología RISC-V pasaría de 1.890 millones de dólares en 2026 a 10.620 millones en 2031, un crecimiento compuesto superior al 41%, según Mordor Intelligence. El financiamiento público sostenido de programas de procesadores soberanos, la adopción rápida de núcleos de estándar abierto en aceleradores de nube y la preferencia creciente por arquitecturas libres de regalías en electrónica sensible al costo sostienen esa expansión.
Los dispositivos de internet de las cosas dominan con un 34,52% de participación en ingresos de 2025, aunque los núcleos para centros de datos crecen rápido. La electrónica de consumo representó el 28,71% de los ingresos de 2025, empujada por teléfonos, dispositivos vestibles y equipamiento de hogar inteligente que priorizan bajo costo de silicio y autonomía prolongada.
Ese punto de las regalías no es menor para la región. Un desarrollo local que hoy paga licencia por núcleo propietario puede reformular el costo unitario completo de un producto al migrar a un núcleo abierto, que es exactamente el argumento que empuja la adopción en electrónica sensible al precio.
¿Se pueden correr agentes de IA en un microcontrolador?
Nuclei System Technology, en Shanghái, desplegó y verificó dos entornos de agentes de inteligencia artificial de borde, PicoClaw y OpenClaw, sobre su propiedad intelectual de procesadores RISC-V de la serie UX. La demostración muestra que la arquitectura puede alojar de forma independiente sistemas operativos complejos de agentes en el borde.
El montaje combinó el procesador UX1000H, que soporta virtualización, con la serie NI900, diseñada para aceleración de inferencia. El UX1000H cumple el estándar RVA23, alineado con los futuros ecosistemas de software de Android y Ubuntu, y admite ejecución fuera de orden con anchos de decodificación de 2 a 6 bits.
Una placa de desarrollo con chip UX900 corriendo Ubuntu 24.04 usó el conjunto de instrucciones RV64GCV para ejecutar ambos entornos en condiciones de recursos limitados. La versión precompilada de PicoClaw v0.2.4 demostró una sobrecarga de sistema muy baja y respuesta rápida. Para escenarios más complejos, OpenClaw 3.9 corrió sobre la serie UX integrando el modelo grande Kimi, de Moonshot AI.
¿Qué es CHERI y por qué importa?
CHERI es probablemente la extensión más conocida, desarrollada para entregar protección de memoria de grano fino. RISC-V International la está ratificando como extensión "Y" en RV6Y, lo que debería eliminar la fragmentación como principal barrera de adopción al entregar un diseño de referencia en SystemVerilog con licencia permisiva y listo para uso comercial.
La primera implementación comercial de CHERI se fabricó en marzo en la empresa británica SCI Semiconductor, mientras Nuvoton desarrolló una versión del núcleo abierto Ibex RV32IMCB, originalmente creado en la ETH de Zúrich, mejorado por lowRISC y usado como elemento de raíz de confianza en los Chromebook de Google. La empresa checa Codasip, en cambio, vendió su negocio principal de RISC-V a onsemi para concentrarse en implementaciones de CHERI.
Investigadores de la Universidad de Minho, en Portugal, portaron CHERI al hipervisor abierto Bao para RISC-V. La evaluación preliminar deja cifras concretas de lo que cuesta esa seguridad:
| Métrica | Sobrecosto medido |
|---|---|
| Tamaño de código | +30,2% |
| Memoria en ejecución | +1 KiB |
| Tiempo de arranque | +20% |
| Latencia de interrupción | +13,43% |
"Hasta donde sabemos, esta es la primera implementación disponible públicamente de un hipervisor que incorpora CHERI para RISC-V y que soporta tanto CHERI como la extensión de hipervisor de RISC-V", señaló Bruno Sa, investigador de Minho. El trabajo quedó publicado como artefacto de código abierto para ambas comunidades.
¿Cómo se protege un núcleo contra ataques físicos?
Dentro del grupo de trabajo Caliptra de la CHIPS Alliance, la empresa Antmicro trabaja junto a AMD, Google, Microsoft y Nvidia en mantener y mejorar el núcleo RISC-V VeeR EL2 que usa el proyecto abierto de raíz de confianza. Ya sumó protección de memoria física y, mediante extensiones a medida, agregó el modo de privilegio de usuario sobre el modo máquina que era el único soportado originalmente.
Con ese núcleo mejorado, Antmicro implementó un sistema de bloqueo de doble núcleo, una forma de redundancia modular doble. La técnica duplica componentes críticos y compara sus salidas para detectar inconsistencias, y resulta ventajosa donde las restricciones de consumo, costo y espacio hacen impracticable la triple redundancia pero la detección de fallos sigue siendo crítica.
El detalle interesante está en la defensa contra ataques con acceso físico al chip. La función es opcional en el núcleo VeeR EL2 de 32 bits y viene desactivada por defecto. Al habilitarla se instancia una copia del núcleo, llamada núcleo sombra, retrasada una cantidad constante y configurable de ciclos de reloj respecto del principal. Un atacante que quisiera alterar el comportamiento del núcleo principal necesitaría además conocer ese retraso y replicar la alteración exactamente igual, después del intervalo exacto.
¿Cómo se evita la fragmentación?
Muchas de las extensiones a medida se conectan al núcleo RISC-V mediante la interfaz Core-V eXtension Interface, conocida como CV-X-IF. El objetivo es permitir el diseño y la verificación de extensiones de instrucciones dentro de un coprocesador de manera estandarizada, sin necesidad de modificar la CPU. Tener una interfaz común permite que los diseñadores de núcleos reutilicen coprocesadores ya existentes.
La interfaz soporta extensiones estándar como B (manipulación de bits), M, F (coma flotante de precisión simple) y D (precisión doble), y también sirve para implementar extensiones propias. Las extensiones implementadas sobre ella no son privilegiadas, así que las privilegiadas como H (hipervisor) quedan fuera.
Su origen está en el proyecto europeo PULP, de la ETH de Zúrich y la Universidad de Bolonia, donde se usó para desacoplar la unidad de coma flotante del diseño de la CPU. La primera versión, llamada interfaz apu, se implementó en el núcleo CV32E40 para comunicarse con el coprocesador CVFPU, pero estaba muy acoplada a la tubería de la CPU, lo que obligaba a modificar la etapa de decodificación con cada nuevo coprocesador.
