Nadie lanza un trabajo de verificación a un emulador sin antes asegurarse de que los casos de prueba sean eficientes y hagan un buen uso de estos preciados recursos. En mi blog anterior, pasé de un modelo de estímulo portátil y usé tecnología de síntesis de banco de pruebas para mover esa prueba de un entorno de metodología de verificación universal transaccional (UVM) a uno que genera código que se ejecuta en el procesador integrado del diseño. Estos procesadores se pueden instanciar en emuladores. Aquí es donde escuchas la aguja rayando el disco.
Mucho más complicado que eso, pero es por eso que se creó Portable Stimulus (PSS). Fue muy difícil migrar un banco de pruebas desarrollado para el simulador al emulador. El estándar no dice nada sobre cómo se debe hacer esto. Esto sigue siendo un problema para los desarrolladores de herramientas PSS. PSS define un lenguaje en el que se pueden definir escenarios, lo que permite que la tecnología de síntesis de banco de pruebas apunte a múltiples plataformas y abstracciones. Estos objetivos tienen algunos requisitos específicos. Vamos a tomar esto paso a paso.
Los emuladores se dimensionan según el número de puertas que pueden manejar. Esto es como decir que un FPGA tiene tanta capacitancia de puerta. Hay un proceso de conversión que hace que el código de nivel de transferencia de registro (RTL) sea adecuado para emuladores o FPGA. Cada proveedor puede ser más o menos eficiente en su tipo particular de diseño. Aumentar el tamaño del emulador lleva mucho tiempo y es costoso, por lo que debe tener cuidado con el uso que hace de estos recursos de emulación. Si tengo 4 procesadores en mi diseño, ¿los asignaré al emulador aunque el código RTL para ellos esté disponible?
Aquí es donde entra en juego el concepto de emulación híbrida. Debe dividir su diseño en uno que use la estructura del emulador y otro que se ejecute en un modelo de comportamiento. Los procesadores suelen ser el objetivo de esto, ya que utilizan el mismo modelo de comportamiento que se utilizó en el simulador. La emulación híbrida es una característica que tienen los proveedores de emuladores y deberían tener las herramientas adecuadas para hacer que esa parte del sistema sea eficiente. Sin embargo, esta situación se puede revertir. ¿Qué sucede si está desarrollando su propio procesador RISC-V y desea validarlo? Ahora desea crear un modelo virtual de uno o más entornos y ejecutar el código RTL de su procesador dentro de esos entornos.
La mayoría de los sistemas no son autónomos y requieren algún estímulo externo y resultados para ser vistos. La comunicación entre el emulador y la máquina host se puede habilitar mediante un software externo o como el estándar SCE-MI de Accellera, que define el protocolo de comunicación entre el banco de pruebas y el emulador. No todos los proveedores usan este estándar y algunos tienen variaciones. Todos trabajan sobre el mismo concepto. Primero, divida el modelo de propiedad intelectual de validación (VIP) en dos. El lado que se conecta al emulador convierte las transacciones en transiciones de señales lógicas. El otro lado se ocupa de los protocolos de nivel superior. En el medio hay un protocolo de comunicación que optimiza cuándo y cómo fluye el tráfico entre las dos partes. Una vez más, su proveedor de emulación debería poner a disposición una biblioteca de estos modelos de transacciones o indicarle cómo crear una.
La falta de comunicación puede degradar el rendimiento del emulador. Considere un emulador que se ejecuta a 10 MHz (una velocidad típica para los emuladores basados en FPGA sin rastreo o depuración excesivos habilitados) conectado a un modelo de comportamiento. Cada vez que estos dos modelos necesitan intercambiar datos, se debe detener el emulador, introduciendo latencia en el sistema de comunicación físico (PCIe en algunos casos) y capas de software, y la necesidad de ejecutar un simulador o banco de pruebas. Si eso sucede en cada ciclo, rastreará el emulador y le costará mucho dinero. Es por eso que no quiero ejecutar un emulador usando UVM donde tengo que pensar en el siguiente vector cada vez que necesito datos. En este ejemplo, significa al menos una vez por ciclo de bus del procesador. Cuanto más eficiente sea el emulador, mayor será el costo de ralentizarlo.
La compilación para la emulación lleva mucho tiempo, por lo que debe evitarse la recompilación a menos que sea absolutamente necesario. Más adelante en el proceso de verificación, se encuentran la mayoría de los errores, por lo que volver a compilar el diseño es menos frecuente. Sin embargo, el banco de pruebas cambia con frecuencia y se ejecuta casi siempre. Si el banco de pruebas está escrito en el lenguaje de descripción de hardware de Verilog, desencadenará una recompilación e incurrirá en una sobrecarga significativa. Usando Test Suite Synthesis para la emulación, la salida de la herramienta es código C y transacciones de E/S que se ejecutan en el procesador. Estas pruebas se almacenan en la memoria de diseño y se cargan como archivos de objetos en tiempo de ejecución. Los cambios no provocan la recompilación, solo una recarga rápida de la memoria. Esto puede cambiar drásticamente la dinámica de compilación.
El estímulo portátil también puede marcar una gran diferencia, ya que genera previamente todos los estímulos antes de ejecutarse. Si bien es posible que no sea posible almacenar todos los estímulos dentro del emulador, es posible detener el emulador solo cuando se necesita reponer el búfer y utilizar la memoria para transferir grandes cantidades de estímulos en lotes.
Al mismo tiempo, se pueden realizar cambios similares para garantizar que los datos para la verificación de resultados también se almacenen en el búfer hasta que se requiera un lavado o se detenga el emulador para una mayor estimulación. En ese momento, puede descargar los datos de respuesta para ver si ha habido fallas hasta el momento. Si existe, puede terminar de ejecutar el emulador. Es posible que ya tenga suficiente información para comenzar a depurar. De lo contrario, sabrá cuándo ocurrió la falla y la ejecución de depuración en el emulador solo necesitará ejecutarse hasta la primera falla (Figura 1).
Breker se ha asociado con varios proveedores de emulación para dar vida a esta solución. A continuación, están trabajando en una emulación híbrida completa y ahora pueden agregarle la solución Breker Test Synthesis. Continuaremos trabajando juntos para mejorar la solución combinada y realizar el concepto original del estándar Accellera. Ahora se puede usar un solo modelo para apuntar a múltiples plataformas de ejecución. Esto le ahorra molestias y le permite usar el emulador de manera más eficiente. Como siempre, no dude en contactarnos con cualquier pregunta o comentario.