So erstellen Sie eine selbstüberprüfende Testbench

Die letzten beiden Codezeilen innerhalb des Prozesses dienen dazu, den Test ordnungsgemäß zu beenden. Der Text „Test:OK“ wird auf der Konsole ausgegeben, und dann wird die Simulation mit dem VHDL-2008-Schlüsselwort „finish“ beendet.

Beachten Sie, dass, wenn Sie ModelSim mit der standardmäßigen Run-Schaltfläche ausführen, ModelSim Sie mit dem Beenden-Dialog auffordert, nachdem die Testbench erfolgreich abgeschlossen wurde. Dieses Verhalten kann geändert werden, wenn Vsim über ein Skript oder über die Befehlszeile gestartet wird. Fügen Sie den Schalter „-onfinish stop“ zum Vsim-Befehl hinzu, wie in der ModelSim-Befehlsreferenz beschrieben.

Überprüfen der Ausgabe

Jetzt versorgen wir das DUT mit Eingängen, aber es findet überhaupt keine Überprüfung des Ausgangs statt. Die Testbench druckt „Test:OK“, unabhängig davon, ob die Ausgabe korrekt ist oder nicht. Lassen Sie uns etwas dagegen unternehmen.

Beim Erstellen eines Verifikationsalgorithmus sollte man immer versuchen, den Test anders zu implementieren als im DUT. Andernfalls kann ein grundlegender Fehler in der Logik unbemerkt bleiben, da er sowohl im DUT als auch im Testbench-Algorithmus vorhanden ist.

Nach diesem Prinzip testen wir den DUT-Ausgang nicht, indem wir prüfen, ob der Gray-Code korrekt ist, sondern dass sich nur ein Bit von einer Zahl zur nächsten ändert. Schließlich ist das der ganze Grund für die Verwendung von Gray-Code überhaupt. Der folgende Code zeigt einen Prozess, der diese Art von Überprüfung durchführt.

PROC_CHECKER : process
    variable prev : std_logic_vector(gray'range);
    variable count : integer;
begin
  wait on bin;

  prev := gray;

  -- Wait for all delta cycles to propagate
  wait for 1 ns;
  
  -- Count the number of changed bits
  count := 0;
  for i in gray'range loop
    if gray(i) /= prev(i) then
      count := count + 1;
    end if;
  end loop;

  assert count = 1
    report integer'image(count) & " bits changed, should have been 1"
    severity failure;
  
end process;

Der Prozess ist empfindlich gegenüber bin Signal, der Eingang zum DUT. Wir hätten eine Sensitivitätsliste mit demselben Ergebnis verwenden können, aber ich ziehe es vor, nur Wait-Anweisungen im Testbench-Code zu verwenden. Es ist eine Konvention, die es einfach macht zu erkennen, ob Sie es mit einer Testbench oder einem RTL-Modul zu tun haben, indem Sie sich ansehen, wie der Code geschrieben ist.

In der zweiten Zeile kopieren wir die vorherige DUT-Ausgabe. Denken Sie daran, dass dies der erste Delta-Zyklus nach bin ist Signal hat sich geändert, und das DUT kann unmöglich noch reagieren. Daher ist es sicher, die DUT-Ausgabe mit der Annahme zu kopieren, dass dies der alte Wert ist.

Dann warten wir 1 Nanosekunde, damit die gesamte kombinatorische Logik im DUT abgeschlossen werden kann. Jetzt sollte die DUT-Ausgabe stabil sein und wir können ihren Wert sicher untersuchen.

Im nächsten Codeabschnitt verwenden wir eine For-Schleife, um die Anzahl der geänderten Bits am DUT-Ausgang zu zählen.

Schließlich kommt die Assert-Anweisung, die überprüft, ob die Anzahl der geänderten Bits genau 1 ist. Assert-Anweisungen funktionieren, indem sie die Bedingung überprüfen, die in diesem Fall count = 1 ist . Wenn die Bedingung zu false ausgewertet wird , wird eine Assertion ausgelöst und der Simulator stoppt, bevor die Meldung „Test:OK“ ausgegeben wird.

Es ist ratsam, die optionale Report-Anweisung in die Assertion-Anweisung aufzunehmen. Dieser Text wird ausgedruckt, wenn die Assertion fehlschlägt. In unserem Beispiel erkläre ich kurz das Ereignis, das zum Fehlschlagen der Testbench geführt hat.

Laufen der Testbench

Es ist an der Zeit, unsere Testbench auszuführen, um zu überprüfen, ob das DUT ordnungsgemäß funktioniert. Nach dem Starten der Simulation in ModelSim und dem Drücken der Schaltfläche „run -all“ sehen wir, dass die Meldung „Test:OK“ auf der Konsole ausgegeben wird.

VSIM 1> run -all
# ** Note: Test: OK
#    Time: 170 ns  Iteration: 0  Instance: /gray_converter_tb

Testen der Testbench

Ich erzeuge immer gerne eine fehlerhafte Bedingung im DUT, nur um zu sehen, dass die Testbench funktioniert. Manchmal ist dies ganz natürlich auf tatsächliche Fehler im DUT zurückzuführen, während Sie es entwickeln. Sollte dies nicht der Fall sein, erstellen Sie einfach kurz einen Fehler, um die Testbench zu testen.

Um dies zu erreichen, werde ich den DUT-Code bearbeiten, um einen „Steh bei 0“-Fehler auf Bit Nummer 3 zu erzeugen. Nach diesem Test werde ich den Fehler mit dem Wissen entfernen, dass die Testbench solche Fehler erkennen kann. Der folgende Code zeigt den DUT-Prozess mit der zusätzlichen Codezeile.

process(bin) is
begin
  gray(gray'high) <= bin(bin'high);

  for i in bin'high - 1 downto bin'low loop
    gray(i) <= bin(i + 1) xor bin(i);
  end loop;

  -- Emulate a stuck at zero error
  gray(3) <= '0';

end process;

Wenn wir die Testbench jetzt ausführen, können wir sehen, dass die Testbench stoppt und der Fehler ausgegeben wird, bevor die Zeile „Test:OK“ erreicht wird. Das Transkript von der ModelSim-Konsole ist unten gezeigt.

VSIM 2> run -all
# ** Failure: 0 bits changed, should have been 1
#    Time: 81 ns  Iteration: 0
Process: /gray_converter_tb/PROC_CHECKER File: gray_converter_tb.vhd
# Break in Process PROC_CHECKER at ray_converter_tb.vhd line 61

Erste Schritte mit selbstprüfenden Testbenches

Sie sollten in der Lage sein, eine selbstüberprüfende Testbench zu erstellen, indem Sie das verwenden, was Sie in diesem Artikel gelernt haben. Machen Sie es sich zur Gewohnheit, immer selbstüberprüfende Testbenches für alle Ihre VHDL-Module zu erstellen. Es wird Ihnen langfristig Zeit sparen.

Es ist in Ordnung, beim Schreiben von Testbenches kreativ zu sein. Mehr als beim Schreiben von RTL-Modulen, da nicht alle VHDL-Konstrukte synthetisiert werden können, aber die Testbench nicht synthetisierbar sein muss. Rechnen Sie damit, mindestens so viel Zeit mit dem Schreiben von Tests zu verbringen wie mit dem Schreiben des DUT.

Wenn Sie sich ernsthaft mit dem Testen befassen möchten, könnten Sie an meinem * interessiert sein kommender VHDL- und FPGA-Kurs. In diesem Kurs begleite ich Sie durch den gesamten Designprozess von der Idee bis zum physisch funktionierenden FPGA-Prototypen. Wir werden mehrere selbstprüfende Testbenches erstellen.

Aktualisiert am 12. Oktober 2020: Ich habe den Kurs abgeschlossen. Klicken Sie auf das Bild unten, um mehr zu erfahren.

Ich werde Ihnen die Best Practices für die erfolgreiche Erstellung von VHDL- und FPGA-Designs auf die richtige Weise beibringen. Wissen, das ich mir in vielen Jahren in der Wissenschaft und nach meiner Tätigkeit als Hardware-Ingenieur in der Verteidigungsindustrie angeeignet habe, gebe ich an Sie weiter.

Lesen Sie hier mehr über den Dot-Matrix-VHDL- und FPGA-Kurs!

Öffnet:

Noch zu entscheiden .