Kampis Elektroecke

Fehlersuche mit dem ILA

Zynq FPGA

Während der Arbeit mit dem ZYNQ (oder einem anderen FPGA) kommt man irgendwann an den Punkt, wo die entwickelte Hardware und/oder die Software getestet werden muss. Damit das erfolgreich geligt, ist der ZYNQ mit einem kompletten CoreSight-Modul der Firma ARM ausgestattet, welches es dem Entwickler erlaubt, sowohl die Hardware über einen integrierten Logic Analyzer, als auch die Software über Haltepunkte zu debuggen. Gesteuert wird das komplette Modul über das JTAG-Interface des Chips. Schauen wir uns mal an wie das geht…

Um das Debugging vorzuführen, habe ich ein einfaches Projekt mit einem Processing System und einem AXI-GPIO Block, der für die Ansteuerung der LEDs und Schalter auf dem Zybo genutzt werden soll, und einem System ILA angelegt.

Der System Integrated Logic Analyzer (ILA) zeichnet die angeschlossene Signale auf und speichert die erfassten Informationen im Block-RAM (BRAM) des FPGAs. Diese Daten werden am Ende des Messvorgangs über das JTAG-Interface an Vivado übertragen und anschließend angezeigt.

Als zusätzliche Unterstützung kann der Entwickler das sogenannte Cross Trigger Interface des Processing Systems aktivieren, wodurch Debugsignale, die z. B. beim Erreichen eines Haltepunktes erzeugt werden, an andere Hardwarekomponenten weitergeleitet werden können. In dieser Anwendung sollen Triggersignale vom Processing System an das FPGA und andersrum gesendet werden. Daher wird sowohl der Triggereingang, wie auch der Triggerausgang für Debugsignale von CPU0 aktiviert.

Diese Signale können dann als Trigger für den ILA genutzt oder vom ILA als Trigger für eine externe Logik genutzt werden. Dazu muss beim ILA der Triggereingang aktiviert werden.

Von dem fertigen Design wird nun der Bitstream generiert und ins SDK exportiert.

Im nächsten Schritt wird die Anwendungssoftware für das Testdesign geschrieben. In diesem Beispiel sollen die Positionen der Schalter eingelesen und, entsprechend der Schalterpositionen, die LEDs geschaltet werden. Der Code dafür ist recht überschaubar:

Bevor das Codedebugging gestartet werden kann, muss das Cross Trigger Interface in den Debugeinstellungen aktiviert werden. Dazu werden die Debug Configurations des aktuellen Projektes geöffnet und ein neuer Eintrag angelegt. Bei dem neu angelegten Eintrag wird zusätzlich ein Haken bei Enable Cross-Triggering gesetzt. Anschließend muss das Interface über den Button konfiguriert werden.

Dazu wird mit Create eine neue Konfiguration angelegt und anschließend werden die Signale CPU0 DBGACK und FTM (Fabric Trace Module) trigger 0 – 3 als Eingang und die Signale CPU0 debug request und FTM trigger 0 – 3 als Ausgänge deklariert. Das FTM dient dabei als Schnittstelle zur Logik im FPGA und sammelt die angeschlossenen Signale, die dann gemeinsam mit anderen Debugsignalen über den JTAG versendet werden.

Zusätzlich werden noch die Optionen Programm FPGA und Reset entire System aktiviert, damit das System vor jedem Debugvorgang gelöscht und das FPGA neu beschrieben wird.

Durch einen Klick auf OK und Apply, sowie auf Debug werden erst die Konfiguration gespeichert und anschließend ein Debugprozess gestartet. Zuerst wird das FPGA beschrieben und dann die Software in den Prozessor geladen und ausgeführt. Der Debugger hält das Programm dann automatisch an, sobald die Resetadresse angesprungen wird. Durch einen Klick auf Resume (F8) wird die Programmausführung bis zur main fortgesetzt.

Jetzt wird in Vivado der Hardwaremanager geöffnet und sich mit dem FPGA verbunden. Vivado erkennt automatisch den verwendeten ILA und wechselt nur entsprechenden Werkzeugansicht. 

Beim Öffnen der Ansicht sind zudem die vorhandenen Signale des ILA in die Ansicht kopiert und anschließend gruppiert worden.

  • AR – AXI Read Address Channel: Adresse für den Lesezugriff mittels AXI-Interface
  • R – AXI Read Channel: Lesekanal des AXI-Interfaces
  • AW – AXI Write Address Channel: Adresse für den Schreibzugriff mittels AXI-Interface
  • W – AXI Write Channel: Schreibkanal des AXI-Interfaces
  • B – AXI Write Response: Kanal für die Schreibbestätigung des AXI-Interfaces

Als erstes wird der Trigger mode des ILA auf TRIG_IN_ONLY geändert. In diesem Modus wartet der ILA nach der Aktivierung auf ein externes Triggersignal am TRIG_IN-Eingang. Sobald dieses Signal anliegt, wird eine neue Messung gestartet. Soll der ILA nicht nach jeder Messung händisch neu gestartet werden, kann der Re-trigger mode aktiviert werden.

Jetzt muss noch der ILA aktiviert, ein Haltepunkt in der Software gesetzt (z. B. bei der for-Schleife) und die Ausführung der Software fortgesetzt werden.

Sobald der Haltepunkt angesprungen wurde und der ILA alle benötigten Datenpunkte gesammelt hat, wird die komplette Messung übertragen und in Vivado angezeigt. Der System-ILA

Gültige AXI-Übertragungen werden vom ILA automatisch markiert und in entsprechende Blöcke unterteilt. In diesem Beispiel wurden also zwei Übertragungen erkannt:

  • Ein Lesezugriff
  • Ein Schreibzugriff

Der Lesezugriff stammt vom Auslesen der Schalter durch die Codezeile

und der Schreibzugriff stammt dem entsprechend von der Codezeile

Die einzelnen Übertragungen können zudem aufgeklappt werden um sich so die Signalverläufe des AXI-Interfaces während der Übertragung anzuschauen.

Eine weitere Möglichkeit des Debuggens besteht darin, dass der ILA das Processing System anhält, weil z. B. ein bestimmtes Paket über den AXI-Bus gesendet worden ist. In diesem Beispiel soll der ILA die Software anhalten, wenn der Wert 0x07 vom GPIO-IP gelesen wird. 

Dazu wird der ILA angehalten und der Trigger mode auf BASIC_ONLY und der TRIG_OUT mode auf TRIGGER_ONLY geändert.

Nun müssen noch die Triggerbedingungen definiert und im Fenster Trigger Setup eingetragen werden. Dazu wird über den “+”-Button eine Probe für das Signal RDATA hinzugefügt und über das Feld Value wird dann der Wert für die Triggerbedingung gesetzt.

Die Eingabe wird mit OK bestätigt. Anschließend werden die Haltepunkte im SDK entfernt und die Ausführung der Software fortgesetzt. Zum Schluss wird der Re-trigger mode deaktiviert und der ILA aktiviert. Über die Schalter am Board wird nun der Wert 0x07 eingestellt und sobald der Wert ausgelesen wird, wird der ILA getriggert und die Ausführung der Software pausiert.

Das komplette Projekt steht in meinem GitLab-Repository zum Download bereit.

Last Updated on

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.