Co-Simulation für Zynq SoC Designs: Hardware-Software-Verifikation beschleunigen

Heterogene System-on-Chip (SoC) Devices wie Xilinx Zynq-7000 und Zynq UltraScale+ MPSoC verschmelzen ein High-Performance Processing System mit modernster programmierbarer Logik. Diese Integration lässt Designer Systeme bauen, die CPU-getriebene Kontrolle mit PL-basierten, Low-Latency-Pipelines balancieren – ideal für Bildverarbeitung, Industrieautomation und Echtzeit-Signalverarbeitung.

Die PS-zu-PL Verbindung basiert auf einer Suite memory-mapped Advanced eXtensible Interface (AXI) Links, die sowohl Master- als auch Slave-Rollen unterstützen und robuste bidirektionale Kommunikation zwischen Software auf den ARM Cores und Custom Logic im FPGA Fabric ermöglichen.

Abbildung 1. Zynq Architektur mit AXI Interconnect zwischen PS und PL (Quelle: Xilinx)

Wenn die PS Konfiguration oder Control handhabt, schreibt ein General-Purpose AXI Master auf dem Prozessor zu Registern inside PL IP Cores und steuert deren Verhalten. Für datenintensive Tasks – wie Streaming Video Frames von PL zu PS Memory – werden High-Performance AXI Interfaces genutzt, die anspruchsvollere Software für DMA Transfers und Buffer Coherency Management verlangen.

Verifizierung von PS-PL Interaktionen ist notorisch schwierig. Ein 2015 Embedded Markets Survey hob Debugging als Top Design Challenge hervor und unterstrich Bedarf an besseren Verifikationstools. Während Bus-Functional Models initialen Sanity Check bieten, fehlt ihnen oft Tiefe, um echte Software-Treiber und Applikationen zu validieren. Full Functional Models existieren, können aber prohibitiv teuer sein.

Traditionelle Verifikation splittet den Flow: Jeder Block wird isoliert validiert, und erst nach Ankunft der ersten Hardware werden PS und PL zusammengefügt. Das Software-Team prüft typischerweise, ob der Linux Kernel notwendige Treiber und Device-Tree Entries trägt, indem QEMU läuft, ein Open-Source Hypervisor, der ARM Architektur emuliert. Umgekehrt sequenziert das Logic Team Commands, die Software-iniziierte Transaktionen mimiken, um PL Funktionalität zu bestätigen.

Beide Ansätze verpassen den wahren PS-PL Handshake, was subtile Integrations-Bugs schwer zu entdecken und kostspielig später im Zyklus zu fixen macht. Während ein Development Board Stop-Gap bieten kann, verlangt Debugging auf echter Hardware Instrumentations-Logic-Einbau, Bitstream-Regenerierung und riskiert Verhaltensdrift.

Co-Simulation von Hardware und Software bietet eine proaktive Lösung: Sie ermöglicht concurrente Verifikation vor Existenz von Production Boards, dramatisch schneidend Debug-Zeit und -Kosten. Sie gibt Designern auch volle Sichtbarkeit in Register-States und Inter-Domain-Traffic, beschleunigt Defekt-Detektion.

HW & SW Co-Simulation

Co-Simulation erfordert, dass der Logic Simulator mit einer Software-Emulations-Plattform kommuniziert. Aldecs Riviera-PRO (2017.10) führte eine Bridge ein, die Riviera-PRO mit QEMU verbindet, erlaubend Linux-basierte Zynq Software im selben Simulationszyklus wie HDL zu laufen.

Abbildung 2. Bridging HW und SW Verifikationsumgebungen (Quelle: Aldec)

Die Bridge nutzt SystemC Transaction-Level Modelling (TLM), um AXI Channels zwischen QEMU und Riviera-PRO zu exponieren, was two-way Datenaustausch ermöglicht. Ingenieure können dann advanced Debugging-Techniken einsetzen wie HDL Breakpoints, Data-Flow Tracing und Code-Coverage-Analyse innerhalb Riviera-PRO, während die Software-Seite GDB nutzt, um durch Kernel und Driver Code in QEMU zu steppen.

Da derselbe Linux Kernel, der auf dem Target Device laufen wird, in QEMU exercised wird, bestätigen Entwickler früh, dass alle notwendigen Module und Config Files präsent sind, was Late-Stage-Überraschungen reduziert.

PWM Beispiel

Zur Illustration des Workflows betrachten Sie ein PWM IP Core im PL, verbunden zur PS via General-Purpose AXI Interface. Software konfiguriert ein Register für Duty Cycle zwischen 0 % und 100 %, dann triggert den Core. Verifikation des Cores in Isolation verpasst den PS-initiierten Control-Pfad; volle Co-Simulation stellt sicher, dass Pulsbreite korrekt generiert wird, wenn die Linux Applikation läuft.