Disminución de la duración del ciclo de diseño en SoC co-diseñados con Renode

En este artículo, explicamos cómo el uso de simuladores funcionales de código abierto como Renode de Antmicro puede ser una parte integral de los esfuerzos de diseño conjunto de hardware y software. .

En este artículo, explicamos cómo el uso de simuladores funcionales de código abierto como Renode de Antmicro puede ser una parte integral de los esfuerzos de diseño conjunto de hardware y software.

A medida que los mercados exigen más de sus sistemas integrados, los SoC de próxima generación se vuelven más complejos, lo que lleva a ciclos de diseño más largos y costos crecientes, según Semico Research.

La frustrante realidad para los fabricantes de dispositivos es que la única forma de ofrecer las funciones nuevas e innovadoras, una mayor seguridad y un mejor rendimiento que sus clientes están pidiendo es participar en el codiseño "completo", el hardware en evolución, el firmware y el tiempo de ejecución. (SO) y la cadena de herramientas de desarrollo en conjunto. Hacerlo permite a los equipos de hardware y software abordar complejas compensaciones en torno al lugar de la pila para implementar la funcionalidad y las optimizaciones.

Desafortunadamente, el co-diseño es a menudo el factor clave para alargar los ciclos de diseño, y por lo tanto, los costos, cuando no se cuenta con las herramientas de simulación adecuadas.

En este artículo, explicamos cómo el uso de simuladores funcionales de código abierto como Renode de Antmicro puede ser una parte integral de los esfuerzos de diseño conjunto de hardware y software. Además, le mostraremos un ejemplo de cómo los usuarios de Renode pueden aprovechar la herramienta para reducir drásticamente la duración de sus ciclos de diseño, proporcionar un medio simple y eficaz para que los clientes evalúen sus soluciones y comenzar a adaptar la garantía de software en paralelo. con esfuerzos de integración de hardware.

Donde los simuladores de software pueden fallar

La importancia de elegir la herramienta de simulación adecuada se ilustra mejor en el caso de Dover Microsystems.

La tecnología CoreGuard® de Dover es la única solución que evita la explotación de las vulnerabilidades del software y permite a los procesadores defenderse de los ataques basados ​​en la red. Dover pudo lograr esto a través de ocho años de investigación y desarrollo, primero como el actor más grande en el Programa Crash de DARPA y luego en Draper Labs, lo que resultó en una solución híbrida de hardware / software única para sistemas integrados.

Esta solución híbrida requiere una estrecha integración entre los componentes de hardware y software. CoreGuard silicon IP es un procesador centinela que actúa como guardaespaldas y protege los sistemas integrados de los ciberataques. Supervisa cada instrucción ejecutada por el procesador host para asegurarse de que cumple con un conjunto definido de reglas de seguridad, protección y privacidad llamadas micropolíticas, el componente de software de CoreGuard. Si una instrucción viola una regla existente, CoreGuard evita que se ejecute antes de que se pueda dañar.

Para lograr esto, CoreGuard necesita mantenerse al día con la ejecución del procesador host. Es decir, en promedio, debe poder retirar (aprobar mediante micropolíticas) instrucciones al mismo ritmo que el procesador host protegido. También es deseable que CoreGuard minimice la cantidad de memoria necesaria para la gestión de metadatos.

Por lo tanto, satisfacer las demandas de rendimiento, potencia y área requiere una interacción compleja de optimizaciones de las capas de hardware y software.

El equipo de hardware de Dover utiliza un proceso y una cadena de herramientas estándar basados ​​en SystemVerilog. Los prototipos iniciales del sistema CoreGuard se basan en SoC basados ​​en RISC-V. Debido a que CoreGuard tiene un componente de software sustancial además de la IP del hardware, era importante que el equipo de software pudiera comenzar mucho antes de que los prototipos de hardware estuvieran disponibles.

El equipo de software de Dover utilizó inicialmente el simulador de software Spike RISC-V ISA que está disponible en los repositorios RISC-V GitHub. Encontraron dos problemas al basar su desarrollo comercial de CoreGuard en Spike:

1. Spike no proporciona ningún periférico realista; es decir, Spike es un simulador ISA, no un simulador SoC. El equipo de Dover comenzó a agregar periféricos como UART y almacenamiento persistente a Spike, y esto supuso mucho trabajo.
2. Spike, por definición, es específico de RISC-V, pero los clientes iniciales de Dover Microsystems son tanto de RISC-V como de Arm.

Estas deficiencias destacaron la necesidad de Dover de un simulador de arquitectura múltiple flexible con el concepto de modelos periféricos que se utilizarán en lugar de Spike.

Cómo aborda Renode las necesidades importantes de diseño conjunto

Enfrentando desafíos heterogéneos de ingeniería de codiseño de hardware / software similares que surgen del trabajo con softcores de código abierto, software temprano para plataformas informáticas de vanguardia, FPGA SoC y arquitecturas de CPU emergentes como RISC-V, Antmicro, un software enfocado en el código abierto proveedor de tecnología y servicios:desarrolló un marco de simulación flexible llamado Renode.

Renode es un marco de simulación modular jerárquico destinado a ejecutar firmware de producción real (es decir, sin modificar) en una variedad de sistemas complejos, incluidos sistemas interconectados de múltiples nodos, múltiples arquitecturas, heterogéneos, a nivel de MCU y compatibles con Linux.

Para abordar estos diversos niveles de complejidad, Renode se basa en una fuerte noción de abstracción y adopta un enfoque modular orientado a objetos para la simulación de sistemas. Los núcleos y periféricos se consideran bloques de construcción que se pueden conectar a través de interfaces en diferentes configuraciones, lo que refleja cómo se construyen los SoC reales.

Figura 1. Un ejemplo de un SoC RISC-V simulado.

La Figura 1 muestra un ejemplo de un SoC RISC-V simulado. Cada bloque de construcción, incluida la CPU, tiene un conjunto de propiedades y API que se pueden utilizar para construir el modelo de simulación de todo el SoC. De manera similar, los nodos individuales se pueden combinar en un sistema de múltiples nodos utilizando conexiones inalámbricas y cableadas virtualizadas (6LoWPAN, UART, Ethernet, etc.). Todo esto no requiere cambios en la base de código de Renode, sino que se realiza a través de la configuración y la secuencia de comandos, lo que reduce la curva de aprendizaje y limita la fragmentación de la base de código.

La naturaleza flexible del marco de Renode, su disponibilidad de código abierto y la existencia de soporte comercial proporcionado por sus autores facilitaron que Dover construyera primero una implementación prototipo de su flujo de trabajo deseado y luego contratara a Antmicro para implementarlo (y liberarlo en el formato abierto). dominio de origen) funcionalidades que hicieron que Renode fuera aún más adecuado para su caso de uso, como la ejecución por instrucción.

En particular, con Renode, los ingenieros de Dover ahora pueden:

• Cambie entre los esfuerzos de integración basados ​​en Arm y RISC-V utilizando la misma configuración.
• Prototipo de SoC (tanto de referencia / mínimo como definido por el cliente) en diferentes niveles de detalle / fidelidad.

Modele la especificación de la arquitectura de hardware del grupo de hardware de Dover, luego escriba y pruebe el firmware con esos modelos, todo mientras el hardware está en desarrollo.

Cómo Renode redujo significativamente el ciclo de diseño de Dover

La tecnología CoreGuard de Dover es un producto de ciberseguridad híbrido en el que están evolucionando los diseños de hardware y software. Como resultado, es importante que el proceso de desarrollo de Dover permita el desarrollo paralelo y las pruebas tanto de hardware como de software.

Figura 2. El proceso de desarrollo utilizado por Dover.

Dover está utilizando el proceso de desarrollo descrito en la Figura 2. Los equipos de hardware y software colaboran en la interfaz de hardware (que, por supuesto, seguirá evolucionando). A medida que el equipo de hardware comienza a implementar bloques en SystemVerilog, el equipo de software crea modelos de los nuevos bloques en C #, el idioma nativo subyacente a Renode. Luego, el equipo de software puede escribir firmware que se comunique con las nuevas interfaces de hardware y probar ese software bajo la simulación de Renode. Finalmente, el software se ejecuta en un emulador de FPGA.

Este proceso de desarrollo, hecho posible por Renode, ha ayudado a Dover a optimizar tanto las simulaciones de "baja fidelidad" como las de "alta fidelidad".

Si bien esta simulación de "baja fidelidad" abstrae toda la lógica del hardware de CoreGuard, Dover aún encuentra esta configuración útil en los siguientes contextos:

• Depuración de micropolíticas: Cuando se desarrollan nuevas micropolíticas de CoreGuard, queremos iterar rápidamente contra una variedad de pruebas de software para verificar el comportamiento.
• Demostraciones y vistas previas de clientes: Para las demostraciones de CoreGuard, la simulación de software puro suele ser suficiente para educar a un cliente potencial sobre las capacidades de CoreGuard® y para estimular el interés en una discusión adicional. Además, Dover a menudo entregará un "SDK" a los clientes que consiste en este simulador de "baja fidelidad" con algunas micropolíticas predefinidas, para que el cliente "juegue" con CoreGuard, incluida la posibilidad de ejecutar micropolíticas de CoreGuard contra el software del cliente.

En simulaciones de "alta fidelidad", que replican un modelo de hardware más preciso, el equipo de ingeniería de Dover ha podido reconocer una serie de beneficios con Renode, que incluyen:

• Integración con varios formatos binarios que no son ELF (p. ej., carga dispersa) utilizados por ROM de arranque de hardware.
• Desarrollar y probar el proceso de arranque; copiando desde flash a RAM, inicializando dispositivos.
• Depuración del tráfico de autobuses con instrumentación Renode.
• Depuración de periféricos (UART, PIC, la propia interfaz CoreGuard) por instrumentación.
• Jugando con el mapa de memoria.
• Implementación de firmware de video HDMI, antes de que el hardware funcionara.

Como se indicó anteriormente, existen algunas limitaciones de área y rendimiento desafiantes que las soluciones de próxima generación como CoreGuard imponen a los equipos de diseño de SoC durante la implementación.

Para aumentar el rendimiento y reducir el uso de memoria, existe una amplia gama de optimizaciones que deben realizarse, que con frecuencia cruzan la frontera del hardware / software.

Es fundamental que los equipos de diseño sean capaces de explorar una amplia gama de posibles técnicas de optimización conjunta de hardware / software y compensaciones, sin un gran proceso de desarrollo serializado "primero hardware y luego software". Un simulador funcional de software flexible como Renode permite a los ingenieros de Dover colaborar a través de la división hardware-software para encontrar compensaciones óptimas entre la complejidad del hardware y el software, lo que lo convierte en parte integral de sus esfuerzos.

Para obtener más información sobre cómo Renode puede optimizar los proyectos de codiseño, visite renode.io. Para obtener más información sobre cómo CoreGuard puede proteger los sistemas integrados de los ataques basados ​​en la red, solicite una demostración para ver CoreGuard en acción.

Este artículo fue coautor de Michael Gielda, vicepresidente de desarrollo empresarial y cofundador de Antmicro.

Los artículos de la industria son una forma de contenido que permite a los socios de la industria compartir noticias, mensajes y tecnología útiles con los lectores de All About Circuits de una manera que el contenido editorial no es adecuado. Todos los artículos de la industria están sujetos a estrictas pautas editoriales con la intención de ofrecer a los lectores noticias útiles, experiencia técnica o historias. Los puntos de vista y las opiniones expresados ​​en los artículos de la industria son los del socio y no necesariamente los de All About Circuits o sus redactores.