SystemVerilog-Testbenches protokollieren

8. Juli 2009, 8:26 Uhr |
Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

SystemVerilog-Testbenches protokollieren

Der Vorteil dieses Ansatzes liegt darin, dass die Visualisierungsfunktion des Debug-Systems verwendet werden kann, um die protokollierten Informationen zusammen mit anderen Daten wie Signalwechsel oder Assertions zu analysieren, da alle Daten in der Debug-Datenbank abgelegt werden, in der auch die HDL-Daten abgespeichert sind. Im Ergebnis liegt ein durchgängiges System vor, mit dem Ingenieure das Verhalten der Gesamtumgebung untersuchen können. Die Daten werden in Form von Standard-Waveforms sowie in speziellen Präsentationsformen dargestellt, wie zeitsynchronisierten Tabellenansichten, die sich, wie aus Tabellenkalkulationsprogrammen bekannt, filtern, konfigurieren und anderweitig manipulieren lassen.

Brücken schlagen zur Interaktivität...

Eine interaktive Simulation ist häufig der einzig verfügbare Mechanismus, der einen tieferen Einblick in den Testbench-Code gewährt. Während das Protokollieren einen recht groben High-Level-Überblick über die Testbench-Aktivitäten vermittelt, liefert eine interaktive Simulation von Testbenches GDB-ähnliche Daten, die zum Verständnis des Testbench-Verhaltens erforderlich sind. Dazu gehören Werte von Variablen zu einem bestimmten Zeitpunkt und detaillierte Informationen zum Thread. Die meisten Simulatoren haben im interaktiven Modus üblicherweise einen wenn auch einfach gehaltenen Zugriff auf diese Informationen.

Durch den Brückenschlag zwischen der Protokollfunktionalität und einer integrierten Design-Testbench-Debug-Umgebung können Entwickler die Funktion zur Aufzeichnung von Meldungen bereits frühzeitig im Designprozess nutzen, um den Testbench-Code (Ort und Zeit) zu identifizieren, der einer genaueren Überprüfung bedarf. So ein Flow, wie er in Bild 2 zu sehen ist, erlaubt, eine protokollierte Meldung mit einfachem Drag&Drop in das Fenster mit der Quellcodedarstellung zu ziehen, so dass der Anwender dort einen Breakpoint setzen kann. Anschließend hat er die möglichkeit, eine interaktive Simulation im Hintergrund zu starten, wobei die Quellcodeansicht des Debuggers als zentrales Cockpit fungiert. Auf diese Weise kann der Ingenieur den Simulator bis zu einem bestimmten Zeitpunkt oder Breakpoint laufen lassen und dann Werte, Call-Stacks und Thread-Informationen (automatisch oder benutzergeführt) untersuchen. Dieser Betriebsmodus gleicht sehr der GDB-Nutzung von C- und C++-Programmierern.

Es gibt etliche überzeugende Vorteile, die dafür sprechen, mit dem Debugger auch den Simulator zu steuern und dessen Ergebnisse darzustellen. Entwickler können dieselbe Umgebung für das Debuggen und die Analyse des Designverhaltens sowie der protokollierten Testbench-Meldungen verwenden. Darüber hinaus bieten Debug-Umgebungen eine benutzerfreundlichere und vertraute Umgebung für das Steuern, das Betrachten und die Analyse der Testbench selbst.

Bild02_40.jpg
Bild 2: Die Verwendung eines durchgängigen und umfassenden Debug-Systems zum Steuern einer interaktiven Testbench-Simulation kann zu einem bedienerfreundlicheren Setup, einer verständlicheren Visualisierung und einer einfacheren Analyse der Ergebniss

  1. SystemVerilog-Testbenches protokollieren
  2. SystemVerilog-Testbenches protokollieren
  3. SystemVerilog-Testbenches protokollieren
  4. ...zum besseren Verständnis
  5. Autoren:

Jetzt kostenfreie Newsletter bestellen!