Hoe maak je een zelfcontrolerende testbank aan
Een self-checking testbench is een VHDL-programma dat de juistheid van het te testen apparaat (DUT) verifieert zonder afhankelijk te zijn van een operator om de output handmatig te inspecteren. De zelfcontrolerende testbench werkt volledig zelfstandig en drukt uiteindelijk een bericht "OK" of "Mislukt" af.
Elke VHDL-module moet een bijbehorende autocontrole-testbank hebben. Het is belangrijk om op elk moment te kunnen controleren of alle modules het beoogde gedrag hebben. Bijvoorbeeld wanneer u wijzigingen aanbrengt in de TU Delft, een submodule of een interfacemodule. We weten allemaal dat dingen kapot kunnen gaan, en je beste hulpmiddel om deze problemen op te lossen is de zelfcontrole-testbank.
Het te testen apparaat
Laten we meteen beginnen en een voorbeeld maken van een zelfcontrolerende testbank. Eerst hebben we iets nodig om te testen, een DUT. Daarvoor heb ik de module in de onderstaande code gemaakt. Het is een binaire naar grijze code converter.
library ieee;
use ieee.std_logic_1164.all;
entity gray_converter is
port (
bin : in std_logic_vector;
gray : out std_logic_vector
);
end gray_converter;
architecture rtl of gray_converter is
begin
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;
end process;
end architecture;
Grijze code is een alternatief nummercoderingsschema, dat verschilt van gewone binaire codering. De belangrijkste eigenschap en het doel van Gray-code is dat er slechts één bit verandert bij het tellen tussen aangrenzende getalwaarden.
| Decimaal | Binair | Grijs |
|---|---|---|
| 0 | 0000 | 0000 |
| 1 | 0001 | 0001 |
| 2 | 0010 | 0011 |
| 3 | 0011 | 0010 | 4 | 0100 | 0110 | 5 | 0101 | 0111 | 6 | 0110 | 0101 | 7 | 0111 | 0100 | 8 | 1000 | 1100 | 9 | 1001 | 1101 | 10 | 1010 | 1111 | 11 | 1011 | 1110 | 12 | 1100 | 1010 | 13 | 1101 | 1011 | 14 | 1110 | 1001 | 15 | 1111 | 1000 |
De bovenstaande tabel laat zien hoe Gray-code verschilt van binaire code.
De testbank
We beginnen met het maken van de basistestbank en het instantiëren van de DUT erin. De onderstaande code toont het testbench-bestand met de DUT geïnstantieerd en alle benodigde importen.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
use std.env.finish;
entity gray_converter_tb is
end gray_converter_tb;
architecture sim of gray_converter_tb is
signal bin : std_logic_vector(3 downto 0) := (others => '0');
signal gray : std_logic_vector(3 downto 0);
begin
DUT : entity work.gray_converter(rtl)
port map (
bin => bin,
gray => gray
);
end architecture;
Let op:we importeren std.env.finish waarvoor VHDL-2008 vereist is. Als je de testbench in ModelSim probeert te compileren zonder iets te veranderen, krijg je de volgende foutmelding:
# ** Warning: gray_converter_tb.vhd(6): (vcom-1516) Package "STD.ENV" does not exist in this language version.
Gelukkig kan dit eenvoudig worden opgelost door de VHDL-versie voor het testbench-bestand in te stellen op VHDL-2008. Klik met de rechtermuisknop op het testbench .vhd-bestand en selecteer Eigenschappen→VHDL→Gebruik 1076-2008->OK.
Voor de TU Delft hoef je niets te veranderen. Het is normaal om voor testbanken een hogere versie van VHDL te gebruiken dan voor de RTL-modules. Je wilt altijd de nieuwste VHDL-constructies in je testbench kunnen gebruiken, maar de meeste synthesetools ondersteunen ze niet.
De invoer genereren
Onze volgende toevoeging aan de testbench is het proces dat input genereert voor de TU Delft. Het is altijd het beste om een uitgebreide test te maken, een test die alle mogelijke invoerwaarden probeert. Hoewel, als er te veel permutaties zijn, je misschien beperkt bent tot het doen van alleen hoekgevallen.
De in- en uitgangen van onze TU Delft hebben een niet-gespecificeerd bereik. Ik zal echter een weloverwogen gok doen dat testen met vectorlengtes van vier bits voldoende is om een mogelijk probleem met deze module aan het licht te brengen.
De onderstaande code bevat het hele proces voor het genereren van de invoerreeks.
PROC_SEQUENCE : process
begin
-- Test all possible input values
for i in 0 to 2**bin'length - 1 loop
bin <= std_logic_vector(to_unsigned(i, bin'length));
wait for 10 ns;
end loop;
-- Finally, test the wrapped value
bin <= (others => '0');
wait for 10 ns;
report "Test: OK";
finish;
end process;
Het eerste codeblok is een For-lus die de telreeks genereert van de laagst mogelijke waarde naar de hoogst mogelijke waarde. Tussen de waarden door wachten we 10 nanoseconden om de TU Delft te laten reageren. Hoewel elke nanosecondewaarde groter dan 0 zou hebben gewerkt, omdat de logica in de DUT puur combinatorisch is.
Het tweede stuk code is voor het testen van de situatie waarin de invoerteller teruggaat naar 0, wat de oorspronkelijke invoerwaarde was. Daarna is verder testen niet nodig, omdat de TU Delft gewoon steeds weer dezelfde resultaten blijft geven.
De laatste twee coderegels in het proces zijn bedoeld om de test netjes af te sluiten. De tekst "Test:OK" wordt afgedrukt naar de console en vervolgens wordt de simulatie gestopt door het VHDL-2008-trefwoord "finish" te gebruiken.
Merk op dat als u ModelSim uitvoert met de standaard Run-knop, ModelSim u zal vragen om het stop-dialoogvenster nadat de testbench succesvol is voltooid. Dit gedrag kan worden gewijzigd bij het starten van Vsim vanuit een script of vanaf de opdrachtregel. Voeg de schakeloptie "-onfinish stop" toe aan de Vsim-opdracht, zoals beschreven in de ModelSim-opdrachtreferentie.
De uitvoer controleren
Nu voorzien we de TU Delft van inputs, maar er is helemaal geen controle op de output. De testbench zal "Test:OK" afdrukken, ongeacht of de uitvoer correct is of niet. Laten we daar iets aan doen.
Probeer bij het maken van een verificatie-algoritme altijd de test anders uit te voeren dan in de TU Delft. Anders kan een fundamentele fout in de logica onopgemerkt blijven, omdat deze zowel in het DUT als in het testbench-algoritme aanwezig is.
Volgens dit principe gaan we de DUT-uitvoer testen, niet door te controleren of de Gray-code correct is, maar eerder dat slechts één bit van het ene getal naar het andere verandert. Dat is tenslotte de hele reden om Gray-code in de eerste plaats te gebruiken. De onderstaande code toont een proces dat dit soort controle uitvoert.
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;
Het proces is gevoelig voor de bin signaal, de ingang naar de TU Delft. We hadden een gevoeligheidslijst kunnen gebruiken met hetzelfde resultaat, maar ik gebruik liever alleen Wait-instructies in testbench-code. Het is een conventie die het gemakkelijk maakt om te weten of je te maken hebt met een testbench of een RTL-module, gewoon door te kijken hoe de code is geschreven.
Op de tweede regel kopiëren we de vorige DUT-uitvoer. Onthoud dat dit de eerste delta-cyclus is na de bin signaal is veranderd en de TU Delft kan nog niet reageren. Het is dus veilig om de DUT-uitvoer te kopiëren in de veronderstelling dat dit de oude waarde is.
Daarna wachten we 1 nanoseconde om alle combinatorische logica in de DUT te voltooien. Nu zou de DUT-output stabiel moeten zijn, en we kunnen de waarde ervan veilig onderzoeken.
In het volgende stuk code gebruiken we een For-lus om het aantal gewijzigde bits op de DUT-uitvoer te tellen.
Ten slotte komt de Assert-instructie die controleert of het aantal gewijzigde bits precies 1 is. Assert-instructies werken door de voorwaarde te controleren, wat in dit geval count = 1 is. . Als de voorwaarde resulteert in false , er wordt een bewering opgeworpen en de simulator stopt voordat het bericht "Test:OK" wordt afgedrukt.
Het is verstandig om de optionele rapportverklaring bij de beweringverklaring op te nemen. Deze tekst wordt afgedrukt als de bewering mislukt. In ons voorbeeld geef ik een korte uitleg van de gebeurtenis waardoor de testbank faalde.
De testbank draaien
Het is tijd om onze testbench uit te voeren om te controleren of de TU Delft correct werkt. Na het starten van de simulatie in ModelSim en het indrukken van de "run -all"-knop, zien we dat het bericht "Test:OK" naar de console wordt afgedrukt.
VSIM 1> run -all # ** Note: Test: OK # Time: 170 ns Iteration: 0 Instance: /gray_converter_tb
De testbank testen
Ik vind het altijd leuk om een falende conditie in de TU Delft te creëren om te zien of de testbank werkt. Soms komt dit natuurlijk door daadwerkelijke fouten in de TU Delft terwijl u deze aan het ontwikkelen bent. Maar als dat niet het geval is, maak dan een korte fout om de testbench te testen.
Om dit te bereiken, zal ik de DUT-code bewerken om een vastgelopen op 0-fout op bit nummer 3 te creëren. Na deze test zal ik de fout verwijderen met de wetenschap dat de testbank dergelijke fouten kan detecteren. De onderstaande code toont het DUT-proces met de extra coderegel.
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;
Wanneer we de testbench nu uitvoeren, kunnen we zien dat de testbench stopt en de fout wordt afgedrukt voordat de regel "Test:OK" wordt bereikt. Het transcript van de ModelSim-console wordt hieronder weergegeven.
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
Aan de slag met zelfcontrolerende testbanken
Je zou in staat moeten zijn om een zelfcontrolerende testbank te maken met behulp van wat je in dit artikel hebt geleerd. Maak er een gewoonte van om altijd zelfcontrolerende testbanken te maken voor al uw VHDL-modules. Het zal u op de lange termijn tijd besparen.
Het is oké om creatief te zijn bij het schrijven van testbanken. Meer nog dan bij het schrijven van RTL-modules, omdat niet alle VHDL-constructies kunnen worden gesynthetiseerd, maar de testbench hoeft niet synthetisch te zijn. Verwacht minstens evenveel tijd te besteden aan het schrijven van toetsen als aan het schrijven van de TU Delft.
Als je serieus aan de slag wilt met testen, ben je misschien geïnteresseerd in mijn * aankomende VHDL- en FPGA-cursus. In de cursus zal ik je door het volledige ontwerpproces leiden, van idee tot het fysiek werkende FPGA-prototype. We zullen meerdere zelfcontrolerende testbanken maken.
Bijgewerkt op 12 oktober 2020: Ik heb de cursus afgerond. Klik op de afbeelding hieronder voor meer informatie.
Ik leer je de best practices voor het succesvol maken van VHDL- en FPGA-ontwerpen op de juiste manier. Kennis die ik gedurende vele jaren in de academische wereld heb opgedaan en die ik na het werken als hardware-ingenieur in de defensie-industrie aan jou heb doorgegeven.
Lees hier meer over de Dot Matrix VHDL- en FPGA-cursus!
Opent:
Te bepalen .
VHDL
- Een CloudFormation-sjabloon maken met AWS
- Hoe creëer je een cloud center of excellence?
- Een zorgvuldig ontworpen cloudstrategie maken
- Hoe maak je een wrijvingsloze UX
- Een lijst met strings maken in VHDL
- Hoe maak je een Tcl-gestuurde testbench voor een VHDL-codeslotmodule?
- Simulatie stoppen in een VHDL-testbench
- Een PWM-controller maken in VHDL
- Een gekoppelde lijst maken in VHDL
- Hoe maak je mensgerichte slimme steden
- Hoe een array van objecten in Java te maken