SystemVerilog-Testbenches protokollieren

SystemVerilog ist nicht nur eine relativ neue Sprache zur Beschreibung komplexer Strukturen, sondern kann auch als Ausgangspunkt für einen effizienteren und realistischeren Test des Designs dienen. Allerdings existiert eine Lücke, wenn es um das Debuggen und die Analyse...

SystemVerilog ist nicht nur eine relativ neue Sprache zur Beschreibung komplexer Strukturen, sondern kann auch als Ausgangspunkt für einen effizienteren und realistischeren Test des Designs dienen. Allerdings existiert eine Lücke, wenn es um das Debuggen und die Analyse von SystemVerilog-Testbench-Code geht. Die üblichen »dumpvars«-basierten Techniken sind im Falle eines objektorientierten Testbench-Codes, der sich in Stil und Aufbau kaum von Applikationssoftware unterscheidet, unpraktisch und ihr Nutzen zudem fragwürdig. Trotzdem benötigen Entwickler ein Hilfsmittel, mit dem sie ermitteln können, was in einer Testbench zu einem bestimmten Zeitpunkt gerade vorgeht. Bislang waren sie dabei auf textbasierte Low-level-Datenprotokollierwerkzeuge angewiesen und mussten zur Analyse der Ausgabedateien auf weitgehend manuelle Analyseverfahren zurückzugreifen.

Das Aufzeichnen von Daten (History) gehörte in vielen Systemen und Softwareumgebungen zum Standardrepertoire und die meisten heute üblichen SystemVerilog-Bibliotheken bieten auch einige eingebaute Hilfswerkzeuge zum Protokollieren von Testbench-Informationen. Die Daten werden dabei in eine simple Textdatei geschrieben, die dann nach Abschluss der Simulation analysiert werden kann. Die Ingenieure korrelieren dazu die Testbench-Daten mit den Schaltungsaktivitäten zu den jeweiligen Zeitpunkten. Dies ist ein mühsamer Low-tech-Prozess mit inhärenten Abweichungen gegenüber den Design- und Testbench-Debug-Flows, in denen oft der Texteditor »vi« aus der »emacs«-Suite zur Visualisierung dient.

Der im Folgenden vorgestellte neue und automatisierte Datenprotokoll-Task auf Systemebene erfasst nicht nur die Meldungen selbst, sondern auch den Status und die Variablenwerte als Eigenschaften oder Attribute der Meldung ebenso wie den Call-Stack – Informationen, die sich später im Debug-Durchgang als nützlich erweisen können. Da diese Daten alle in ein und derselben Debug-Datenbank abgelegt werden, in der auch die HDL-Daten gespeichert sind, lassen sich die protokollierten Informationen zusammen mit anderen Daten, wie Signalwechsel oder Assertions, visualisieren. Zudem ermöglichen moderne Visualisierungstechniken es den Entwicklern, alle Aktivitäten in der Umgebung in Standard-Waveforms oder speziellen Anwendungsprogrammen, wie zeitsynchronisierten Tabellenansichten, darzustellen.