Debugging komplexer Systeme Fehlersuche und Monitoring von FPGA-Designs

FPGAs werden heute immer komplexer, um so anspruchsvolle Applikationen zu adressieren. Damit haben sich die Methoden zum Debuggen und Monitoring großer FPGA-Systeme verändert.

Anbieter zum Thema

MicroConsult Academy GmbH

Cadlog Group

Bicker Elektronik GmbH

Ein Großteil der FPGA-Designs kann grundsätzlich in zwei unterschiedliche Kategorien eingordnet werden: Designs mit Embedded-Soft-Prozessorkernen und Designs ohne diese Soft-Cores. Diese verschiedenen Architekturen benötigen eine vollkommen unterschiedliche Debug- und Monitoring-Infrastruktur innerhalb des FPGA-Systems. Dabei handelt es sich um einen Bereich, in dem der Systementwickler wirklich Mehrwert für die gesamte Entwicklung leisten kann.

Ingenieure müssen Design-Techniken für die Datenerfassung verwenden, die sie in die Lage versetzen, dass sie einerseits die Hauptursache eines Problems bestimmen und andererseits auch die Systemleistung unter realen Lastbedingungen überwachen können. Hier wird gezeigt, wie einfach solch eine Datenerfassung in einem FPGA-Design realisiert werden kann, was den Debug-Prozess deutlich beschleunigt.

Debuggen von Systemen ohne Prozessor

In Designs ohne Prozessor verwenden Entwickler typischerweise einen Embedded-Logik-Analysator, um die entsprechenden Laufzeitdaten zu sammeln. Tools wie der Embedded-Logik-Analysator SignalTap II von Altera (in der Quartus-II-Design-Software enthalten) sind nützlich, um sich diverse Signale und ihr taktmäßiges Verhalten anzusehen. Wenn ein Design-Fehler vermutet wird, kann der Entwickler neue Signale auswählen, um das Design zu untersuchen und neu zu kompilieren und dann den FPGA-Baustein zu rekonfigurieren. Dieser Prozess ist iterativ, bis der Fehler gefunden und beseitigt ist. Das kann unter Umständen sehr zeitaufwändig sein. Wird diese Debug-Infrastruktur auch nach der Auslieferung der Bausteine benötigt, ist dafür eine Menge an Logik-Ressourcen notwendig.

In Designs mit einem Soft-Core kann der Entwickler Steuerungs- und Debug-Signale/Schnittstellen im Speicher abbilden, um sie für den Prozessor sichtbar zu machen. Auf dem Prozessor läuft die Debug-Software, die auf Befehle aus einem Kommunikationskanal des Systems, wie beispielsweise UART oder Ethernet, antwortet.

Debuggen eines Systems mit Prozessor

Damit kann der Entwickler das System über diesen Kanal debuggen. Dazu greift er auf eine eigene, in der Prozessor-Software implementierten Befehlssprache zum Debuggen zurück; je nachdem was der Designer in der Debug-Befehlssprache implementiert hat, kann er damit das System mehr oder weniger steuern, überwachen und untersuchen.

Manchmal fügen Entwickler einen Soft-Core ausschließlich für Testzwecke hinzu. Das hat aber zwei entscheidende Nachteile: Zum einen dauert es eine gewisse Zeit, um die Befehlssprache zu erzeugen. Zum anderen kann diese Methode aufgrund der Natur des Kommunikationskanals typischerweise nicht in der Simulation genutzt werden. Außerdem kann in Systemen, in denen auch noch andere Verarbeitungs-Tasks laufen, die Interaktion mit der Befehlssprache dazu führen, dass ein Fehler im System maskiert/versteckt wird.

Anforderungen an moderne Debug-Systeme

Nachdem heute FPGAs zunehmend in die Systemdomäne wandern, brauchen Entwickler moderne Debugging-Tools auf Systemebene. Denn nur dann können sie folgende Punkte beurteilen:

• Stimmt die Systemleistung mit der erwarteten Leistung überein?

• Gibt es irgendwelche Engpässe?

• Wie viel Verarbeitungskapazität steht zur Verfügung?

Die Debug-Infrastruktur sollte Mittel zur Verfügung stellen, mit denen diese und andere Fragen, die vielleicht erst nach Auslieferung auftreten, beantwortet werden können. Dafür sollten keine oder nur minimale Veränderungen des Designs notwendig und der Bedarf an Logikressourcen begrenzt sein.

(ID:30605640)