Co-simulación para diseños basados ​​en Zynq

Los dispositivos heterogéneos System-on-Chip (SoC) como Xilinx Zynq 7000 y Zynq UltraScale + MPSoC combinan sistemas de procesamiento de alto rendimiento con lógica programable de última generación. Esta combinación permite diseñar el sistema para proporcionar una solución óptima. Las interfaces de usuario, la comunicación, el control y la configuración del sistema pueden ser abordados por el Sistema Procesador (PS). Mientras tanto, la lógica programable (PL) se puede utilizar para implementar funciones deterministas de baja latencia y tuberías de procesamiento que explotan su naturaleza paralela, como las que se utilizan en el procesamiento de imágenes y las aplicaciones industriales.

La comunicación entre el PS y el PL es proporcionada por varias interfaces mapeadas en memoria. Estas interfaces utilizan la Interfaz extensible avanzada (AXI) para proporcionar comunicaciones tanto maestro como esclavo en cada dirección.

Figura 1. Arquitectura Zynq que muestra la interconexión AXI entre PS y PL (Fuente:Xilinx)

En los casos en los que el PS realiza las funciones de configuración y control, se utiliza la interfaz AXI Master de uso general desde el PS al PL. Esto permite que el software (SW) configure los registros y, por lo tanto, el comportamiento deseado de los núcleos IP en el PL. En operaciones más complejas, puede existir el deseo de transferir grandes cantidades de datos desde el PL al espacio de memoria del PS para su posterior procesamiento o comunicación. Estas transferencias utilizarán interfaces de alto rendimiento, que requerirán un software considerablemente más complejo para configurar y usar.

Verificar las interacciones entre el PS y el PL presenta desafíos para el equipo de diseño. La Encuesta de mercados integrados de 2015 identificó la depuración como uno de los principales desafíos de diseño que enfrentan los equipos de ingeniería y también identificó la necesidad de mejorar las herramientas de depuración. Si bien los modelos funcionales de bus se pueden usar inicialmente, estos modelos a menudo se simplifican y no permiten la verificación de los controladores de software desarrollados y la aplicación al mismo tiempo. Hay disponibles modelos completamente funcionales, pero estos pueden ser prohibitivamente costosos. Cuando se implementa un diseño de SoC heterogéneo, es necesario que exista una estrategia de verificación que permita que los elementos PL y PS se verifiquen juntos lo antes posible.

Tradicionalmente, la verificación se ha realizado inicialmente para cada elemento (bloque funcional) en el diseño de forma aislada; La verificación de todos los bloques juntos ocurre cuando llega el primer hardware. El equipo de ingeniería de software que desarrolla las aplicaciones para ejecutarse en el PS debe asegurarse de que el Kernel de Linux contenga todos los módulos necesarios para admitir su uso y tenga el blob de árbol de dispositivos correcto; esto normalmente se verifica usando QEMU (abreviatura de Quick Emulator), que es un hipervisor alojado gratuito y de código abierto que realiza la virtualización de hardware.

Mientras tanto, para verificar correctamente el diseño del PL, el equipo de verificación lógica debe generar y secuenciar comandos como los emitidos por el software de la aplicación para verificar que la lógica funcione como se requiere. Sin embargo, ambos enfoques no capturan la verdadera interacción del software con el hardware, por lo que los errores asociados con esta interacción son muy difíciles de detectar. Esto retrasa el cronograma de desarrollo y aumenta los costos de desarrollo, ya que los problemas que surgen más adelante en el proceso de desarrollo siempre son más costosos de abordar y corregir.

Es posible utilizar una placa de desarrollo como paso intermedio para verificar la interacción HW y SW antes de la llegada del hardware final. Sin embargo, la depuración en hardware real puede ser complicada y requiere la inserción de lógica de instrumentación adicional en el hardware. Esta inserción lleva más tiempo, ya que el archivo de bits debe regenerarse para incluir la lógica de instrumentación. Por supuesto, este cambio en la implementación también puede afectar el comportamiento subyacente del diseño, enmascarando problemas o introduciendo nuevos problemas que se hacen evidentes solo en las compilaciones de depuración.

Ser capaz de verificar tanto el diseño de SW como el de HW usando co-simulación, por lo tanto, proporciona varios beneficios significativos. Se puede realizar antes en el ciclo de desarrollo y no requiere esperar a que llegue el hardware de desarrollo, lo que reduce el costo y los impactos de la depuración. Además, este enfoque también proporciona más visibilidad con respecto a los registros y las interacciones entre el PS y el PL, todo lo cual ayuda en el descubrimiento y eliminación de errores al principio del proceso.

Co-simulación de HW y SW

La co-simulación entre SW y HW requiere la herramienta de simulación lógica utilizada para verificar el diseño de HW para poder interactuar con un entorno de emulación de simulación de SW.

El lanzamiento de Riviera-PRO de Aldec (2017.10) permite solo esta co-simulación de HW y SW mediante la provisión de un puente entre Riviera-PRO y QEMU, lo que permite la ejecución del software desarrollado para desarrollos de Zynq basados ​​en Linux.

Figura 2. Conectando los entornos de verificación de HW y SW (Fuente:Aldec)

Este puente ha sido creado utilizando el Modelado de Nivel de Transacción (TLM) de SystemC para definir los canales de comunicación entre QEMU y Riviera-PRO. La verificación simultánea del SW y el HW se ve facilitada por la capacidad del puente para transferir información en ambas direcciones.

Dentro de este entorno de simulación integrado, el equipo de ingeniería puede utilizar metodologías de depuración estándar y avanzadas para abordar cualquier problema que pueda surgir a medida que avanza la verificación. En el caso de Riviera-PRO, esto incluye capacidades como establecer puntos de interrupción dentro del HDL, examinar el flujo de datos e incluso analizar la cobertura del código y las rutas que ejerce la aplicación de software que se ejecuta en QEMU. En el caso de QEMU, el equipo de software puede usar Gnu DeBugger (GDB) para instrumentar tanto el kernel como el controlador para recorrer el código usando puntos de interrupción.

Este enfoque de co-simulación tiene la ventaja de no solo proporcionar mayor visibilidad y capacidad de depuración dentro del entorno de simulación de hardware, sino que también permite que el mismo kernel de Linux desarrollado para el hardware de destino se utilice dentro de QEMU. Nuevamente, esto proporciona una verificación previa de que el Kernel contiene correctamente todos los paquetes y elementos necesarios para admitir la aplicación en desarrollo.

Ejemplo de PWM

Para demostrar este entorno de co-simulación, se creó un ejemplo simple. Este ejemplo coloca un núcleo IP dentro del PL y lo conecta al Zynq PS a través de una interfaz AXI de uso general. Cuando se habilita mediante un acceso AXI a su espacio de registro, el núcleo IP generará una salida de señal modulada por ancho de pulso (PWM). La duración de la señal PWM se puede seleccionar dentro de un rango de 0 a 100% y nuevamente se define mediante un registro dentro del espacio de registro del núcleo IP. Un caso de uso típico para este núcleo, por lo tanto, requiere software que se ejecute en Zynq PS para habilitar y configurar el núcleo IP. La simple simulación del núcleo IP de forma aislada no resultará en la demostración adecuada del funcionamiento deseado del núcleo. Para verificar correctamente el núcleo de IP, necesitamos poder habilitar y ejercitar el ancho de pulso de salida desde el PS cuando se ejecuta un sistema operativo Linux.