Desmitificando las extensiones personalizadas en el diseño de SoC RISC‑V

La conversación sobre configurar un procesador base o añadir extensiones personalizadas para resolver compromisos de diseño hardware-software en un system-on-chip (SoC) ha sido durante mucho tiempo una piedra angular de la propuesta de valor de la comunidad RISC‑V. Artículos recientes, como Una guía para acelerar aplicaciones con instrucciones personalizadas RISC‑V just-right, destacan los beneficios tangibles de extender la ISA de código abierto.

Los SoCs de IA y aprendizaje automático de hoy están limitados por potencia, rendimiento y área de die, haciendo que las extensiones de ISA sean una palanca a menudo pasada por alto pero poderosa para cumplir estas demandas.

Un reciente seminario web de Quantum Leap Solutions, titulado Flexibilidad RISC‑V – El poder de las extensiones personalizadas, tuvo como objetivo desmitificar cómo la ISA RISC‑V puede adaptarse para el diseño moderno de SoC. La sesión atrajo a más de 100 asistentes y contó con un panel de expertos de la industria.

La discusión se centró en cómo una ISA modificada puede acelerar aplicaciones emergentes y cómo los diseñadores evalúan extensiones para la arquitectura RISC‑V.

Moderado por Mike Ingster, fundador y presidente de Quantum Leap Solutions, los panelistas fueron:

• John Min, Director de FAE en Andes Technology
• Larry Lapides, Vicepresidente de Ventas en Imperas Software
• Taek Nam, Ingeniero Senior de Aplicaciones en Mentor

Mike Ingster: ¿Por qué RISC‑V es una mejor opción para aplicaciones de IA y ML que otras arquitecturas de CPU?

John Min: RISC‑V fue concebido cuando la IA se volvió mainstream, y su conjunto de instrucciones vectoriales fue diseñado con cargas de trabajo de IA y VR en mente.

Larry Lapides: En un sistema de IA con un array multiplexado de procesadores heterogéneos, una arquitectura que hemos visto implementada en múltiples ocasiones, un diseñador puede combinar núcleos escalares y vectoriales. RISC‑V le permite eliminar características innecesarias manteniendo instrucciones vectoriales, entregando un PPA (rendimiento, potencia, área) superior.

Ingster: ¿Los núcleos RISC‑V con extensiones vectoriales también pueden extenderse con instrucciones personalizadas?

Min: Sí. Un ejemplo típico es un núcleo vectorial que incorpora extensiones del cliente para añadir buffers extra, evitando paradas por inanición de datos.

Lapides: Tanto Imperas como Andes tienen clientes que han implementado tales funciones personalizadas para mejorar el rendimiento.

Ingster: En un array multiprocesador, ¿todos los CPUs necesitan la misma configuración, o pueden tener diferentes instrucciones personalizadas?

Lapides: Los procesadores heterogéneos son comunes. Las instrucciones personalizadas pueden variar entre núcleos, e incluso el conjunto de instrucciones base puede diferir: un núcleo puede soportar instrucciones vectoriales mientras otro permanece escalar, permitiendo ejecución intercalada.

Min: En un array multiplexado, tanto las CPUs como los simuladores pueden ser heterogéneos, permitiendo simulación multicore eficiente.

Ingster: ¿Ve un procesador RISC‑V de clase servidor en el mercado?

Min: La trayectoria es clara: mayor frecuencia, pipelines más anchos, ejecución out-of-order y multicores masivamente paralelos. Estos elementos ya aparecen en núcleos RISC‑V de próxima generación para cargas de trabajo de IA empresarial.

Lapides: Históricamente, RISC‑V comenzó con SoCs de prueba de concepto de 32 y 64 bits. Hace unos dos años vimos un auge de SoCs enfocados en seguridad e IoT. Hoy estamos viendo procesadores de clase aplicación: núcleos RISC‑V de 64 bits corriendo RTOS reales y pipelines out-of-order tempranos. Los primeros chips de clase servidor se esperan en los próximos dos o tres años.

Ingster: ¿Pueden las extensiones personalizadas proporcionar seguridad de dispositivo y gestión de ciclo de vida?

Min: Absolutamente. Una instrucción personalizada puede realizar comprobaciones en tiempo de ejecución para forzar compatibilidad de software, o un puerto de memoria dedicado puede aislar datos críticos, mejorando seguridad y control de ciclo de vida.

Taek Nam: Los diseñadores también pueden aprovechar IP de analítica embebida Tessent para incrustar seguridad y gestión de ciclo de vida directamente en SoCs con extensiones personalizadas.

Ingster: ¿Por qué el enfoque de RISC‑V a instrucciones personalizadas es diferente de otros proveedores como ARC o Tensilica?

Min: El mecanismo formal de extensión de RISC‑V permite que las instrucciones personalizadas se incorporen formalmente al estándar, proporcionando un camino claro hacia una adopción más amplia.

Ingster: ¿Cómo puede un desarrollador compartir instrucciones personalizadas con clientes o socios?

Min: Existen tres opciones: mantenerlo propietario, enviarlo a RISC‑V International para inclusión (p. ej., extensiones DSP de Andes que se convirtieron en P-extensiones), o compartir los intrínsecos y archivos de cabecera mientras se protege la implementación bajo NDA.

Lapides: Un modelo de extensión personalizada puede ofrecerse como código abierto o binario, o como modelo de procesador instruction-accurate, facilitando el desarrollo de software pre-silicio temprano.

Ingster: ¿Llevarán las extensiones personalizadas a problemas de compatibilidad dentro de la comunidad RISC‑V?

Min: Las extensiones propietarias permanecen aisladas; si una extensión gana uso generalizado, puede proponerse para inclusión en la ISA base, previniendo fragmentación.

Ingster: ¿El procesador vectorial es soportado por un compilador en su versión actual?

Min: Las Extensiones Vectoriales RISC‑V 0.8 son estables y soportadas por GCC y LLVM. El soporte final del compilador seguirá la finalización de la especificación oficial.

Ingster: ¿Cómo se soportan las extensiones personalizadas en la cadena de herramientas de software?

Lapides: Los diseñadores incrustan extensiones en sus modelos RISC‑V, generando simuladores de conjunto de instrucciones para desarrollo de software. GCC y LLVM pueden extenderse para soportar nuevas instrucciones, y los diseñadores pueden proporcionar implementaciones macro.

Ingster: ¿Cómo se hace consciente al compilador de una instrucción personalizada recién creada?

Lapides: El equipo de software debe implementar la instrucción en el backend del compilador.

Min: Alternativamente, trate la instrucción como una biblioteca: proporcione un archivo de cabecera y una implementación propietaria opcional, minimizando el esfuerzo de desarrollo mientras se gana rendimiento.

Ingster: ¿Qué SOs son soportados en RISC‑V, y hay soporte para Android?

Lapides: Linux, Zephyr RTOS y otros sistemas operativos en tiempo real son objetivos principales. Android no ha sido verificado oficialmente en RISC‑V, pero los esfuerzos de porting están en marcha. El sitio web de RISC‑V International lista todos los SOs soportados.

Ingster: ¿Cómo se verifican las extensiones personalizadas?

Lapides: La verificación implica añadir extensiones al RTL y al modelo del procesador. Los simuladores de conjunto de instrucciones permiten validación temprana de software.

Taek: Un cliente reciente usó nuestra IP de analítica embebida para rastrear y cuantificar ganancias de rendimiento de instrucciones personalizadas, confirmando los beneficios mediante validación basada en datos.

Ingster: ¿Cuánta área se requiere para añadir la IP de analítica embebida?

Taek: Típicamente alrededor del 1 % del die, dependiendo de la configuración. Cada diseño se evalúa para optimizar área mientras se entrega máximo valor.

Estos aspectos destacados se extraen de la discusión completa del panel, organizada por Quantum Leap Solutions.