Hardwareverificatie verbeteren met een Tcl-gebaseerde interactieve testbench

Een interactieve testbench is een simulatoropstelling waarbij invoer aan het device under test (DUT) wordt geleverd door een operator tijdens de uitvoering van de testbench. Meestal betekent dit dat je commando's in de simulatorconsole intypt om de DUT van stimulus te voorzien.

Hoewel je altijd een self-checking testbench moet maken, kan een interactieve testbench een mooie aanvulling zijn. Het is gemakkelijker om ad-hoc tests uit te voeren met een interactieve testbench dan de code van de self-checking testbench te wijzigen.

Vaak ontdek je problemen in de lab die je in de testbench wilt reproduceren. Met een interactieve testbench kan dat zo simpel zijn als de waargenomen invoerreeks intypen om het ongewenste gedrag in de simulator na te bootsen.

Tcl interactie met VHDL

De meeste VHDL-simulators gebruiken Tcl als hun consoletaal. De simulators hebben een reeks vendor-specifieke commando's, maar het goede nieuws is dat ze als elke andere Tcl-opdracht behandeld kunnen worden. Je kunt Tcl gebruiken voor het maken van complexe, grotendeels draagbare scripts voor het beheren en ondersteunen van je VHDL-testbenches.

VHDL-signalen wijzigen vanuit Tcl

Om met VHDL te interacteren, moeten we het commando vinden voor het wijzigen van een signaalwaarde. In ModelSim is dit het "force"-commando. Zoals gespecificeerd in de commandoreferentiedocumentatie, is de synopsis voor het commando:

force {<object_name> <value> [[@]<time_info>][, <value> [@]<time_info>]... [-deposit | -drive | -freeze] [-cancel [@]<time_info>] [-repeat [@]<time_info>]

De switch die je wilt gebruiken is de "-deposit"-vlag. Dit verandert de waarde van het VHDL-signaal direct, maar staat een andere VHDL- of Tcl-driver toe om het later naar iets anders te veranderen.

Door de opties die we niet gebruiken te negeren, ziet de vereenvoudigde synopsis er zo uit:

force -deposit <signal_name> <value>

De VHDL-trigger

Nu we weten hoe we VHDL-signalen vanuit Tcl kunnen controleren, moeten we een soort ontvangstproces in onze VHDL-testbench creëren. De onderstaande code toont een minimaal voorbeeld van zo'n testbench.

 library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; entity interactive is end interactive; architecture sim of interactive is -- Controlled by Tcl signal trigger : std_logic := '0'; begin process is begin wait until trigger = '1'; report "Triggered!"; end process; end architecture; 

Het proces wordt gewekt wanneer het trigger-signaal verandert van iets naar '1'. Het print "Triggered!" naar de console wanneer dit gebeurt, zodat we het concept van het besturen van VHDL-processen vanuit Tcl kunnen testen.

Ik deed net dat in de ModelSim-console. De uitgegeven commando's, evenals de output, zijn in het onderstaande transcript te zien.

VSIM 1> run 10 ns; VSIM 2> force -deposit /trigger '1' VSIM 3> run 0 ns; # ** Note: Triggered! # Time: 10 ns Iteration: 0 Instance: /interactive VSIM 4> force -deposit /trigger '0' VSIM 5> run 10 ns;

Ik liep de testbench 10 nanoseconden na het starten van de simulatie.

Vervolgens forceerde ik het trigger-signaal naar '1'. Op de volgende regel wacht ik 0 nanoseconden. Het doel hiervan is een delta-cyclus te creëren. Ik wil dat het proces getriggerd wordt, maar ik wil dat er geen simulatiетijd voorbijgaat.

Ten slotte forceer ik het trigger-signaal terug naar '0' voordat ik de testbench voortzet.

We kunnen zien dat het VHDL-proces opwakelde na de "run 0 ns"-regel en "Triggered!" naar de console printte.

VHDL-signaalwaarden lezen in Tcl

Om signaalwaarden in ModelSim te lezen, kun je het "examine"-commando gebruiken. We kunnen bijvoorbeeld de waarde van het trigger-signaal lezen door dit commando in de ModelSim-console te gebruiken:

VSIM 6> examine /trigger # 0

Je zou de waarde aan een Tcl-variabele willen toewijzen wanneer je "examine" in een script gebruikt. Laten we dit in de ModelSim-console proberen:

VSIM 7> set triggerVal [examine /trigger] # 0

Dan kunnen we de variabele bijvoorbeeld afdrukken met het "puts" Tcl-commando:

VSIM 8> puts "triggerVal: $triggerVal" # triggerVal: 0

De simulator stoppen na elke test

De makkelijkste manier om de test lang genoeg te laten lopen voor de DUT om te reageren, is om de simulator voor een vaste tijdwaarde te laten lopen. Als de DUT na twee klokcycli zou moeten reageren, en de klokperiode is 10 nanoseconden, zouden we het commando "run 20 ns" in ons Tcl-script gebruiken.

Als de DUT geen vaste reactietijd heeft, kan een VHDL-assertie gebruikt worden om de simulatie te stoppen en controle over te dragen aan een Tcl-callback-functie. In ModelSim zou dit betekenen dat je een breakpoint instelt vanuit je Tcl-script met het "when"-commando:

when [[-fast] [-id <id#>] [-label <label>] {<when_condition_expression>} {<command>}]

Je moet ook een "onBreak"-callback-functie in Tcl definiëren die uitgevoerd wordt wanneer de breakpoint wordt getriggerd. De "onBreak"-functie is gespecificeerd in de ModelSim-commandoreferentie.

Nadelen van Tcl-gestuurde tests

Er zijn nadelen aan testbenches die zwaar op Tcl-scripts vertrouwen. De meest voor de hand liggende zijn snelheids- en draagbaarheidsproblemen.

Tcl-gestuurde testbenches werken door de simulator meerdere keren te starten en stoppen om met de VHDL-code te interacteren. Het starten en stoppen van de simulatie om een Tcl-functie ertussen te laten lopen, is tijdrovender dan een VHDL-testbench continu te laten lopen. Terwijl Tcl een geïnterpreteerde taal is, wordt VHDL in de simulator gecompileerd en loopt veel sneller dan Tcl.

Hoewel Tcl draagbaar is naar andere simulators, zijn de vendor-specifieke commando's die je moet gebruiken, dat niet. Zelfs als je de equivalente commando's in de andere simulator vindt, kunnen ze anders werken. Simulatorleveranciers bedenken hun eigen regels voor de commando's die ze ondersteunen. Daarom moet een Tcl-gestuurde testbench als minder draagbaar worden beschouwd dan een zuivere VHDL-testbench.

Nieuwe VHDL- en FPGA-cursus

* Ik ben een nieuwe VHDL- en FPGA-cursus aan het maken die diepgaand ingaat op testbenches. Je leert hoe je een FPGA-ontwerp vanaf nul maakt. Na afloop van de cursus weet je hoe je self-checking testbenches maakt en hoe je de code hergebruikt om een interactieve testbench te maken.

* Bijgewerkt 12 oktober 2020: Ik heb de cursus voltooid. Klik op de afbeelding hieronder voor meer informatie.

Het product dat we gaan maken is een dot-matrix LED-controller-module. We zullen het $49 Lattice iCEstick-ontwikkelbord gebruiken. Aan het eind zullen we het ontwerp op een breadboard implementeren. Je kunt op het toetsenbord van je computer typen, en de karakters verschijnen op het dot-matrix LED-scherm dat door de FPGA wordt bestuurd.

Lees meer over de Dot Matrix VHDL- en FPGA-cursus hier!

Opent:

Nog te bepalen.