Fallstudie: Entwicklung einer SystemVerilog-Testbench
Synopsys-Ingenieure benötigten insgesamt sechs Mannwochen zur Erstellung der Constrained-Random-Testbench für einen Bus-Control- Block, der für ein Projekt vonnöten war. Dieser wurde durch gezielte Tests verifiziert und ist nun Teil eines in der Produktion befindlichen Chips. Die bei der Verifikation verwendeten „zufälligen“ Testläufe spürten drei neue, zuvor unentdeckte Fehler auf, die sich von einem fehlenden Latch bis hin zu Protokollfehlern in mehreren Byte-Transfers erstreckten.
Synopsys-Ingenieure benötigten insgesamt sechs Mannwochen zur Erstellung der Constrained-Random-Testbench für einen Bus-Control- Block, der für ein Projekt vonnöten war. Dieser wurde durch gezielte Tests verifiziert und ist nun Teil eines in der Produktion befindlichen Chips. Die bei der Verifikation verwendeten „zufälligen“ Testläufe spürten drei neue, zuvor unentdeckte Fehler auf, die sich von einem fehlenden Latch bis hin zu Protokollfehlern in mehreren Byte-Transfers erstreckten.
Jobangebote+ passend zum Thema
INHALT: |
Eine europäische Firma für Konsumelektronik stand vor der Aufgabe, zur Verbesserung der Designqualität ihren Verifikationsprozess auszuweiten. Sie arbeitete mit Synopsys zusammen, um unter Verwendung des Verification-Methodology- Manuals (VMM) und der VCS-Lösung zur funktionalen Verifikation eine SystemVerilog- Testbench zu entwerfen. Die folgenden Ausführungen zeigen, auf welche Weise Features wie objektorientierte Programmierung und Constrained-Random-Stimulus in Testbenches interessierter Anwender eingesetzt werden können.
Der Design-Under-Test
Der Bus-Control-Block (Bild 1) bildet die Schnittstelle zwischen einem Mikrocontroller sowie dem Digital-Satellite- Equipment-Control-Bus (DiSEqC) und ermöglicht einem Satellitenempfänger die Steuerung externer Geräte. Der Mikrocontroller liest und schreibt Werte in ein Register-File, welches wiederum die Empfangs- und Sendemodule steuert. Die Schnittstelle des DiSEqCBusses besteht aus zwei Pins: „tone_out“ für das Senden und „tone_in“ für den Empfang.
Der Mikrocontroller schreibt die vollständige Nachricht in das Register-File. Dieses Modul bricht die Nachricht herunter in acht Bytes, die über die „tone_out“- Leitung zu einem Slave-Device geschickt werden. Der Slave sendet seine Antwort, falls nötig, über die „tone_in“-Leitung, in der die einzelnen Bytes zu einer vollständigen Nachricht zusammengefügt und im Register-File abgelegt werden. Das Modul sendet einen Interrupt zum Mikrocontroller, der daraufhin die Antwort auswertet.
Die Testbench-Blöcke sind in einer Umgebungsklasse (environment) enthalten. Das VMM spezifiziert neun Schritte hin zu einer kompletten Simulation:
- Erzeugung einer zufälligen Konfiguration. Durch zufällige Definition der gesamten Umgebung – sowohl des DUT als auch umgebender Blöcke – können Chipdesigner zuversichtlich sein, dass sie den Baustein so getestet haben, wie er im produktiven Einsatz genutzt wird. Die Anzahl an Transaktionen wird ebenfalls zufällig bestimmt.
- Aufbau der Umgebung: Instanziierung der zur Testbench gehörigen Objekte wie Generatoren, Checker, Treiber und Monitore.
- Rücksetzen des DUT.
- Konfiguration des DUT. Herunterladen der Konfigurationsinformation aus Schritt 1 in das DUT.
- Starten des Tests.
- Warten auf das Testende. Nach der Generierung aller Transaktionen müssen die Anwender warten, bis die Transaktionen durch das Design und die Scoreboards geflossen sind.
- Stoppen der Testbench-Komponenten.
- Aufräumen der Testbench.
- Generieren eines Reports bezüglich der Anzahl erfolgreicher und fehlgeschlagener Transaktionen.
- Prüfen des Scoreboards auf nicht beanspruchte Transaktionen.
Durch die vielen Schritte kann der Anwender noch „feiner abgestuft“ als bisher auf die Testbench Einfluss nehmen. Darüber hinaus ruft die Basisklasse „vmm_env“ automatisch die ausgelassenen Schritte auf. Der grundlegendste Testcase jedenfalls sieht aus, wie in Listing 8 zusammengefasst. Chipdesigner können zudem einen neuen Stil von Nachrichten in den Generator einbringen, indem sie die originale Stimuli-Klasse erweitern und dann die Kopie im Generator ersetzen (siehe Listing 9).
- Fallstudie: Entwicklung einer SystemVerilog-Testbench
- Autor:
- Verifikation mit System-Verilog und VMM
