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.

Druckversion

Von Chris Spear

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.

INHALT:
Der Design-Under-Test
Verifikation mit System-Verilog und VMM
OOP und Random-Stimulus
Layered Testbench – der Schlüssel zum Erfolg?
Schnittstellen-Konstrukt modelliert Kommunikationsabläufe
Vielschichtiger Aufbau der Umgebung
Autor

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.