SystemVerilog-Testbenches protokollieren
Fortsetzung des Artikels von Teil 1
SystemVerilog-Testbenches protokollieren
Diese lassen sich dann beispielsweise filtern und konfigurieren. Spezialfunktionen wie erweiterte Filterfunktionen oder die Möglichkeit. Codezeilen mit Farbe zu hinterlegen können darüber hinaus dabei helfen, Meldungen zu identifizieren bzw. zu markieren, wenn diese bestimmte Bedingungen erfüllen. Die automatische Erfassung des Call-Stack während des Protokolliervorgangs eröffnet völlig neue Möglichkeiten für eine weitergehende Automatisierung des Debugprozesses. So lässt sich eine aufgezeichnete Meldung beispielsweise mit dem Quellcode in Beziehung setzen, indem der Anwender sie mit Hilfe von Drag&Drop einfach von der Waveform-Darstellung auf die Quellcodedarstellung zieht. Die Software springt dann automatisch zu der Stelle, welche die Meldung ausgelöst hat. Sie kann auch dazu verwendet werden, schnell Breakpoints an passender Stelle zu setzen, um eine interaktive Simulation aus der Debug-Umgebung heraus anzustoßen, wie im nächsten Abschnitt näher erläutert wird.
Jobangebote+ passend zum Thema
Interaktivität beim Protokollieren
Während das Protokollieren nur einen recht groben High-Level-Überblick über die Testbench-Aktivitäten vermittelt, liefert eine interaktive Simulation von Testbenches GDB-ähnliche Daten, etwa Werte von Variablen zu einem bestimmten Zeitpunkt und detaillierte Informationen zum Thread, die fallweise zum Verständnis des Testbench-Verhaltens erforderlich sind. Durch die Verknüpfung der Protokollfunktion mit einem integrierten Design-Testbench-Debug-Flow können Entwickler die Funktion zur Aufzeichnung von Meldungen schon frühzeitig im Designprozess nutzen, um den Testbench-Code (Ort und Zeit) zu identifizieren, der einer genaueren Überprüfung bedarf. Die Möglichkeit, eine interaktive Testbench-Simulation aus der Debug-Umgebung heraus aufzurufen, erleichtert dem Anwender das Setup, die Visualisierung und die Analyse des Designverhaltens sowie der aufgezeichneten Testbench-Meldungen und der Testbench selbst.
Strategien, wie sie in der Softwarewelt üblich sind, können sich auch bei der Verifikation und dem Debuggen von Testbenches als nützlich erweisen. Es liegt auf der Hand, dass es nicht reicht oder sogar unmöglich ist, traditionelle Hardware-Debug-Techniken einfach auf Testbenches zu übertragen. Um Einblicke in die Testbench-Vorgänge während der Simulation zu erhalten, ist ein neues Vorgehen erforderlich, das auf dem oben gezeigten Konzept fußt. Der Schlüssel zum Erfolg ist es, den Protokolliervorgang so zu verbessern und zu automatisieren, dass der Großteil des Debugging und der Analyse von Testbench-Aktitiväten auf dieser Ebene erledigt werden kann. Das Ziel ist es, einen fortschrittlichen Protokolliermechanismus zu verwenden, mit dem sich der Ursprung eines Problems ermitteln lässt. Stellt sich dabei heraus, dass das Problem auf Seiten der Testbench liegt und weitergehende Informationen erforderlich sind, können die Ingenieure in einen interaktiven Modus wechseln.
Protokollieren – so geht’s richtig
Daten zu protokollieren, ist in Systemen und Software ein übliches Verfahren. Beispielsweise sichern Betriebssysteme und die meisten Softwaresysteme Informationen in Log-Dateien, um im Bedarfsfall eine Analyse oder Fehlerbehebung zu erleichtern. Es kann daher nicht überraschen, dass den protokollierten Daten auch bei dem Debuggen und der Analyse von SystemVerilog-Testbenches eine entscheidende Rolle zukommt.
Die heute vorherrschenden SystemVerilog-Methoden stellen einige Basisbibliotheken zur Verfügung, mit denen Anwender Informationen der Testbench protokollieren können. Allerdings ist dabei die Visualisierung mit Hilfe einfacher Bestandteile der SVTB-Syntax, wie $display und printf, oder spezieller Basisklassen eine Schwachstelle. Die aufgezeichneten Daten werden bei diesen Mechanismen üblicherweise in Form von Textdateien abgelegt. Soll das Debuggen des Designs und der Textbenches ein zweckmäßiger und effizienter Vorgang sein kann, muss die Protokollierfunktion flexibel in der Verwendung sein und die mitgeschriebenen Daten in ein geeignetes Format bringen (z.B. FSDB), damit sie auch in der Debugging-Umgebung zur Verfügung stehen. Dies ist eine Grundvoraussetzung, um fortschrittliche Visualisierungs-, Debug- und Analysefunktionen realisieren zu können. Wie so ein Flow aussehen kann, zeigt Bild 1.
Ein Task wie $fsdbLog für das Protokollieren von Informationen muss so flexibel gestaltet sein, dass die Ingenieure ihn an jeder beliebigen Stelle im Code – auch in vorhandene Basisklassenbibliotheken, die für das Protokollieren vorgesehen sind – einfügen können. Der Protokollier-Task muss dabei in der Lage sein, nicht nur Meldungen mitzuschreiben, sondern auch Informationen wie die Stati und Variablenwerte als Eigenschaften oder Attribute der Meldung. Zusätzlich ist es sinnvoll, den Call-Stack automatisch mit aufzuzeichnen, um die weitere Debug-Automatisierung zu erleichtern.
- SystemVerilog-Testbenches protokollieren
- SystemVerilog-Testbenches protokollieren
- SystemVerilog-Testbenches protokollieren
- ...zum besseren Verständnis
- Autoren:
