Co-Simulation für Zynq-basierte Designs

Heterogene System-on-Chip (SoC)-Geräte wie der Zynq 7000 von Xilinx und der Zynq UltraScale+ MPSoC kombinieren Hochleistungsverarbeitungssysteme mit modernster programmierbarer Logik. Diese Kombination ermöglicht es, das System so zu gestalten, dass es eine optimale Lösung bietet. Benutzerschnittstellen, Kommunikation, Steuerung und Systemkonfiguration können vom Prozessorsystem (PS) angesprochen werden. Inzwischen kann die Programmable Logic (PL) verwendet werden, um niedrige Latenzzeiten, deterministische Funktionen und Verarbeitungspipelines zu implementieren, die ihre Parallelität ausnutzen, wie sie beispielsweise von der Bildverarbeitung und industriellen Anwendungen verwendet werden.

Die Kommunikation zwischen dem PS und dem PL wird durch mehrere speicherabgebildete Schnittstellen bereitgestellt. Diese Schnittstellen verwenden das Advanced eXtensible Interface (AXI ), um sowohl die Master- als auch die Slave-Kommunikation in jede Richtung bereitzustellen.

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

In Fällen, in denen Konfigurations- und Steuerfunktionen vom PS ausgeführt werden, wird die universelle AXI-Master-Schnittstelle vom PS zum PL verwendet. Dadurch kann die Software (SW) Register und damit das gewünschte Verhalten von IP-Cores im PL konfigurieren. Bei komplexeren Operationen kann der Wunsch bestehen, große Datenmengen vom PL in den PS-Speicherraum zur weiteren Verarbeitung oder Kommunikation zu übertragen. Diese Übertragungen werden die Hochleistungsschnittstellen verwenden, deren Konfiguration und Verwendung erheblich komplexere Software erfordern.

Die Überprüfung der Interaktionen zwischen PS und PL stellt das Designteam vor Herausforderungen. Die Embedded Markets Survey 2015 identifizierte das Debugging als eine der größten Designherausforderungen, denen sich Entwicklungsteams gegenübersehen, und identifizierte auch den Bedarf an verbesserten Debugging-Tools. Bus-Funktionsmodelle können zwar anfänglich verwendet werden, diese Modelle sind jedoch oft vereinfacht und ermöglichen keine gleichzeitige Verifikation der entwickelten SW-Treiber und der Anwendung. Voll funktionsfähige Modelle sind verfügbar, aber diese können unerschwinglich teuer sein. Bei der Implementierung eines heterogenen SoC-Designs muss eine Verifizierungsstrategie vorhanden sein, die es ermöglicht, sowohl PL- als auch PS-Elemente zum frühestmöglichen Zeitpunkt gemeinsam zu verifizieren.

Traditionell wurde die Verifikation zunächst für jedes Element (Funktionsblock) im Design isoliert durchgeführt; das Verifizieren aller Blöcke zusammen erfolgt, wenn die erste Hardware ankommt. Das Softwareentwicklungsteam, das die Anwendungen entwickelt, die auf dem PS ausgeführt werden sollen, muss sicherstellen, dass der Linux-Kernel alle erforderlichen Module enthält, um seine Verwendung zu unterstützen, und über den richtigen Gerätebaum-Blob verfügt. Dies wird normalerweise mit QEMU (kurz für Quick Emulator) überprüft, einem kostenlosen und Open-Source-gehosteten Hypervisor, der Hardwarevirtualisierung durchführt.

Um das PL-Design korrekt zu verifizieren, muss das Logikverifizierungsteam in der Zwischenzeit Befehle wie die von der Anwendungssoftware ausgegebenen generieren und sequenzieren, um zu überprüfen, ob die Logik wie erforderlich funktioniert. Beide dieser Ansätze erfassen jedoch nicht die wahre Interaktion der Software mit der Hardware, wodurch es sehr schwierig wird, mit dieser Interaktion verbundene Fehler zu erkennen. Dies verzögert den Entwicklungsplan und erhöht die Entwicklungskosten, da später im Entwicklungsprozess aufgeworfene Probleme immer teurer zu behandeln und zu korrigieren sind.

Es ist möglich, ein Entwicklungsboard als Zwischenschritt zu verwenden, um das Zusammenspiel von HW und SW vor dem Eintreffen der endgültigen Hardware zu überprüfen. Das Debuggen auf echter Hardware kann jedoch kompliziert sein und erfordert das Einfügen zusätzlicher Instrumentierungslogik in die Hardware. Dieses Einfügen nimmt zusätzliche Zeit in Anspruch, da die Bitdatei neu generiert werden muss, um die Instrumentierungslogik einzuschließen. Natürlich kann sich diese Änderung in der Implementierung auch auf das zugrunde liegende Verhalten des Designs auswirken, wodurch Probleme maskiert oder neue Probleme eingeführt werden, die sich nur in den Debug-Builds bemerkbar machen.

Die Möglichkeit, sowohl das SW- als auch das HW-Design mittels Co-Simulation zu verifizieren, bietet daher mehrere bedeutende Vorteile. Es kann zu einem früheren Zeitpunkt im Entwicklungszyklus durchgeführt werden und erfordert kein Warten auf das Eintreffen der Entwicklungshardware, wodurch die Kosten und die Auswirkungen des Debuggings reduziert werden. Darüber hinaus bietet ein solcher Ansatz auch mehr Transparenz in Bezug auf Register und Interaktionen zwischen PS und PL, was alles dazu beiträgt, Fehler früher im Prozess zu entdecken und zu entfernen.

HW- und SW-Co-Simulation

Die Co-Simulation zwischen SW und HW erfordert, dass das Logiksimulationstool, das zum Verifizieren des HW-Designs verwendet wird, mit einer SW-Simulationsemulationsumgebung interagieren kann.

Die Veröffentlichung von Riviera-PRO (2017.10) von Aldec ermöglicht genau diese HW- und SW-Co-Simulation durch die Bereitstellung einer Brücke zwischen Riviera-PRO und QEMU und ermöglicht so die Ausführung der entwickelten Software für Linux-basierte Zynq-Entwicklungen.

Abbildung 2. Überbrückung der HW- und SW-Verifizierungsumgebungen (Quelle:Aldec)

Diese Brücke wurde mit SystemC Transaction Level Modeling (TLM) erstellt, um die Kommunikationskanäle zwischen QEMU und Riviera-PRO zu definieren. Die gleichzeitige Überprüfung von SW und HW wird durch die Fähigkeit der Brücke erleichtert, Informationen in beide Richtungen zu übertragen.

Innerhalb dieser integrierten Simulationsumgebung kann das Engineering-Team Standard- und erweiterte Debug-Methoden verwenden, um alle Probleme zu beheben, die im Verlauf der Verifizierung auftreten können. Im Fall von Riviera-PRO umfasst dies Funktionen wie das Setzen von Breakpoints innerhalb des HDL, das Untersuchen des Datenflusses und sogar das Analysieren der Codeabdeckung und der Pfade, die von der in QEMU ausgeführten SW-Anwendung ausgeführt werden. Im Fall von QEMU kann das SW-Team Gnu DeBugger (GDB) verwenden, um sowohl den Kernel als auch den Treiber zu instrumentieren, um den Code mithilfe von Breakpoints schrittweise durchzuarbeiten.

Dieser Co-Simulationsansatz hat den Vorteil, dass er nicht nur eine bessere Sichtbarkeit und Debugging-Fähigkeit innerhalb der Hardware-Simulationsumgebung bietet, sondern auch die Verwendung desselben Linux-Kernels, der für die Zielhardware entwickelt wurde, innerhalb von QEMU ermöglicht. Dies ermöglicht wiederum eine frühere Überprüfung, ob der Kernel alle erforderlichen Pakete und Elemente korrekt enthält, um die in Entwicklung befindliche Anwendung zu unterstützen.

PWM-Beispiel

Um diese Co-Simulationsumgebung zu demonstrieren, wurde ein einfaches Beispiel erstellt. In diesem Beispiel wird ein IP-Core innerhalb des PL platziert und über eine universelle AXI-Schnittstelle mit Zynq PS verbunden. Wenn der IP-Core durch einen AXI-Zugriff auf seinen Registerraum aktiviert wird, erzeugt er einen pulsweitenmodulierten (PWM) Signalausgang. Die Dauer des PWM-Signals ist in einem Bereich von 0 bis 100 % wählbar und wird wiederum durch ein Register im Registerraum des IP-Cores definiert. Ein typischer Anwendungsfall für diesen Kern erfordert daher, dass Software auf dem Zynq PS ausgeführt wird, um den IP-Kern zu aktivieren und zu konfigurieren. Eine einfache isolierte Simulation des IP-Cores führt nicht dazu, dass der gewünschte Betrieb des Cores ausreichend demonstriert wird. Um den IP-Core korrekt zu verifizieren, müssen wir in der Lage sein, die Ausgangsimpulsbreite vom PS zu aktivieren und auszuüben, wenn ein Linux-Betriebssystem ausgeführt wird.