Co-simulación para diseños Zynq SoC: Acelerando verificación hardware-software

Dispositivos System-on-Chip (SoC) heterogéneos como Xilinx Zynq-7000 y Zynq UltraScale+ MPSoC fusionan un sistema de procesamiento de alto rendimiento con lógica programable de vanguardia. Esta integración permite a diseñadores construir sistemas que equilibran control impulsado por CPU con pipelines de baja latencia basados en PL —ideales para procesamiento de imagen, automatización industrial y procesamiento de señal en tiempo real.

La conexión PS-a-PL se construye sobre una suite de enlaces Advanced eXtensible Interface (AXI) mapeados en memoria que soportan roles tanto master como slave, permitiendo comunicación bidireccional robusta entre software corriendo en núcleos ARM y lógica personalizada en la tela FPGA.

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

Cuando el PS maneja configuración o control, un AXI Master de propósito general en el procesador escribe a registros dentro de núcleos IP de PL, dirigiendo su comportamiento. Para tareas intensivas en datos —como streaming de fotogramas de video de PL a memoria PS— se usan interfaces AXI de alto rendimiento, demandando software más sofisticado para configurar transferencias DMA y gestionar coherencia de buffers.

Verificar interacciones PS-PL es notoriamente difícil. Una Encuesta de Mercados Embebidos 2015 destacó la depuración como un desafío de diseño principal y subrayó la necesidad de mejores herramientas de verificación. Mientras los modelos bus-funcionales pueden proporcionar una verificación inicial de cordura, a menudo carecen de la profundidad requerida para validar drivers de software y aplicaciones reales. Los modelos funcionales completos existen pero pueden ser prohibitivamente costosos.

La verificación tradicional divide el flujo: cada bloque se valida aisladamente, y solo después de que llega el primer hardware se unen PS y PL. El equipo de software típicamente verifica que el kernel de Linux lleve los drivers y entradas de device-tree necesarios ejecutando QEMU, un hipervisor de código abierto que emula la arquitectura ARM. Por el contrario, el equipo de lógica secuencia comandos que imitan transacciones iniciadas por software para confirmar funcionalidad de PL.

Ambos enfoques pierden el verdadero handshake PS-PL, haciendo bugs de integración sutiles difíciles de detectar y costosos de arreglar más tarde en el ciclo. Aunque una placa de desarrollo puede proporcionar un parche, depurar en hardware real demanda insertar lógica de instrumentación, regenerar el bitstream y arriesgar deriva de comportamiento.

La co-simulación de hardware y software ofrece una solución proactiva: permite verificación concurrente antes de que existan placas de producción, reduciendo dramáticamente tiempo y costo de depuración. También da a diseñadores visibilidad completa en estados de registros y tráfico inter-dominio, acelerando detección de defectos.

Co-simulación HW & SW

La co-simulación requiere que el simulador de lógica se comunique con una plataforma de emulación de software. Riviera-PRO de Aldec (2017.10) introdujo un puente que conecta Riviera-PRO a QEMU, permitiendo que software Linux basado en Zynq corra dentro del mismo ciclo de simulación que el HDL.

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

El puente aprovecha SystemC Transaction-Level Modelling (TLM) para exponer canales AXI entre QEMU y Riviera-PRO, permitiendo intercambio de datos bidireccional. Los ingenieros pueden entonces emplear técnicas avanzadas de depuración como breakpoints HDL, trazado de flujo de datos y análisis de cobertura de código dentro de Riviera-PRO, mientras el lado de software usa GDB para paso a paso por código de kernel y drivers en QEMU.

Porque el mismo kernel de Linux que correrá en el dispositivo objetivo se ejerce en QEMU, los desarrolladores confirman temprano que todos los módulos y archivos de configuración necesarios están presentes, reduciendo sorpresas en etapas tardías.

Ejemplo PWM

Para ilustrar el flujo de trabajo, considere un núcleo IP PWM colocado en PL y conectado al PS vía una interfaz AXI de propósito general. Software configura un registro para establecer ciclo de trabajo entre 0 % y 100 %, luego dispara el núcleo. Verificar el núcleo en aislamiento pierde el camino de control iniciado por PS; la co-simulación completa asegura que el ancho de pulso se genera correctamente cuando la aplicación Linux corre.