Fallstudie: Entwicklung einer SystemVerilog-Testbench #####
Fortsetzung des Artikels von Teil 3
Fallstudie: Entwicklung einer SystemVerilog-Testbench
Jobangebote+ passend zum Thema
Layered Testbench – der Schlüssel zum Erfolg?
Als Hardwarebeschreibungssprachen wie VHDL oder Verilog zum ersten Mal zum Einsatz kamen, wurde der RTL-Code durch Anlegen von Einsen und Nullen an das DUT getestet. Dies hat sich bald als derart langwierig herausgestellt, dass spezielle Routinen entwickelt wurden, welche immer wiederkehrende Aufgaben ausführen – beispielsweise das Senden einer Nachricht auf einen Bus.
Die VMM-Methodik erweitert diese fundamentale Idee, indem sie eine aus mehreren Schichten bestehende Testbench definiert und verwendet (siehe Bild 2). Die unterste Schicht ist die Signalschicht, welche „atomare“ Kommandos empfängt, das DUT ansteuert und die Ausgabe des DUT aufzeichnet. In dieser Schicht gibt es ferner Assertions, die die Signale des DUT und seiner Peripherie laufend überwachen, um sicherzustellen, dass sie dem zugehörigen Protokoll entsprechen. Im Bus-Control-System liest und beschreibt das Bus-Functional- Model (BFM) des Mikrocontrollers die jeweiligen Register im DUT. Die nächsthöhere Schicht ist die Kommandoschicht. Sie bricht High-Level-Kommandos herunter in kleinere Kommandos. Im Bus-Control-System wird eine Nachricht in Register-Lese- und Schreibzugriffe zerlegt. Die Kommandoschicht umfasst außerdem das Scoreboard, das die erwarteten Ausgaben des DUT enthält, sowie einen Checker zum Vergleich der erwarteten mit den tatsächlichen Ausgaben. Der Generator erzeugt einen Strom zufälliger Transaktionen (Nachrichten), welche den Transactor speisen.
Im Sinne maximaler Flexibilität sollte eine Testbench unter Verwendung von Objekten erstellt werden. Die Alternative ist, Module zu verwenden, aber diese können nicht dynamisch instanziiert werden. Außerdem ist eine Testbench in einem Modul anfällig für Race-Conditions, wie im nächsten Abschnitt erläutert wird. Die meisten der Blöcke in Bild 2 sind durch eine einfache Schleife modelliert, welche eine Transaktion vom jeweils vorhergehenden Block liest, eine grundlegende Transformation ausführt und sie dann zum nächsten Block sendet. Die Kommunikation zwischen Blöcken wird mit Hilfe eines VMMChannels bewerkstelligt. Dies ist ein FIFO, welches Transaktionen beinhaltet. In der Testbench des Bus-Control- Blocks erhält der Transactor Nachrichten vom Generator, zerlegt sie in individuelle Bytes und sendet sie zum Driver (siehe Listing 2). ?? Der „program“-Block enthält die Testbench In Verilog-Simulationen werden manchmal Race-Conditions verursacht, wenn die Testbench und das Design Signale gleichzeitig lesen und schreiben. SystemVerilog eliminiert dieses Problem durch Einführung des „program“-Blocks, welcher die Testbench enthält. Während eines Timeslots werden zuerst alle Design-Events ausgeführt, solche innerhalb von Modulen, und erst dann die vom Programm hervorgerufenen Events. Die Trennung der zwei Event-Typen stellt sicher, dass Testbench-Events nicht mit denen des Designs vermischt werden.
- Fallstudie: Entwicklung einer SystemVerilog-Testbench #####
- Fallstudie: Entwicklung einer SystemVerilog-Testbench
- Fallstudie: Entwicklung einer SystemVerilog-Testbench
- Fallstudie: Entwicklung einer SystemVerilog-Testbench
- Fallstudie: Entwicklung einer SystemVerilog-Testbench
