Testbench w Verilogu: podstawy weryfikacji modułu

Czym naprawdę jest testbench

Testbench to po prostu moduł w Verilogu. Od modułu syntezowalnego różni się zawartością:

• Nie ma portów, bo jest na szczycie hierarchii symulacji.
• Tworzy instancję testowanego projektu.
• Steruje wejściami DUT z bloków initial i always.
• Obserwuje wyjścia DUT przez $display, $monitor albo zapis do pliku VCD.
• Kończy symulację przez $finish.

To cała jego rola. Nie ma specjalnego słowa kluczowego "testbench": to, że coś jest testbenchem, poznajesz po tym, co robi.

Standardowy szkielet

// Design under test: a tiny module we'll test.
module adder(
    input  wire [7:0] a,
    input  wire [7:0] b,
    output wire [8:0] sum
);
    assign sum = a + b;
endmodule

// Testbench: the rest of this file.
module test;
    // -----------------------------------------------------------------
    // 1. Signals to drive the DUT and observe its outputs.
    // -----------------------------------------------------------------
    reg  [7:0] a;
    reg  [7:0] b;
    wire [8:0] sum;

    // -----------------------------------------------------------------
    // 2. Instantiate the DUT.
    // -----------------------------------------------------------------
    adder dut(.a(a), .b(b), .sum(sum));

    // -----------------------------------------------------------------
    // 3. Stimulus + lifecycle.
    // -----------------------------------------------------------------
    initial begin
        $dumpfile("dump.vcd");
        $dumpvars(0, test);

        // Drive some interesting input combinations.
        a = 8'd0;   b = 8'd0;   #1 $display("%0d + %0d = %0d", a, b, sum);
        a = 8'd1;   b = 8'd2;   #1 $display("%0d + %0d = %0d", a, b, sum);
        a = 8'd200; b = 8'd100; #1 $display("%0d + %0d = %0d", a, b, sum);
        a = 8'hFF;  b = 8'h01;  #1 $display("%h + %h = %h",   a, b, sum);

        $finish;
    end
endmodule

To cały wzorzec. Pięć sekcji, łatwych do skopiowania i dostosowania.

Dla kombinacyjnych DUT (takich jak ten sumator) zegar nie jest potrzebny. Dla sekwencyjnych DUT jest, a to kolejna warstwa.

Generowanie zegara dla sekwencyjnych DUT

Gdy DUT ma wejście clk, testbench musi generować zegar. Standardowa jednolinijkowa wersja:

reg clk = 0;
always #5 clk = ~clk;

To przełącza clk co 5 jednostek czasu. Każde przełączenie to połowa okresu zegara, więc pełny okres to 10 jednostek (jeden cykl = 5 w stanie wysokim + 5 w niskim). Jeśli timescale to 1ns / 1ps (domyślna wartość w większości symulatorów), daje to zegar 100 MHz.

Dobierz połowę okresu do tego, co chcesz modelować. Dla zegara 10 MHz przy tym samym timescale użyj #50. Dla zegara 200 MHz użyj #2.5 (albo zmień timescale).

Sekwencja resetu

Projekty synchroniczne potrzebują resetu trzymanego w stanie wysokim przez kilka cykli po chwili 0, a potem zwalnianego. Konwencjonalny kształt:

reg reset = 1;     // start asserted

initial begin
    // Hold reset for a few clocks.
    #20 reset = 0;
end

To trzyma reset w stanie wysokim do chwili 20, a potem go opuszcza. Zanim reset spadnie, zegar wykona kilka cykli, każdy przerzutnik zapamięta wartość resetu, a projekt znajdzie się w znanym stanie.

Dla resetu aktywnego stanem niskim (reset_n zamiast reset) odwróć wartość początkową:

reg reset_n = 0;   // active-low: 0 means asserted

initial begin
    #20 reset_n = 1;
end

Kompletny testbench sekwencyjny

Połączenie zegara, resetu i pobudzenia:

module counter(
    input  wire       clk,
    input  wire       reset,
    input  wire       enable,
    output reg  [3:0] count
);
    always @(posedge clk) begin
        if (reset)       count <= 4'd0;
        else if (enable) count <= count + 4'd1;
    end
endmodule

module test;
    // -- DUT signals --
    reg  clk = 0;
    reg  reset = 1;
    reg  enable = 0;
    wire [3:0] count;

    // -- DUT instance --
    counter dut(.clk(clk), .reset(reset), .enable(enable), .count(count));

    // -- Clock generator (10-unit period) --
    always #5 clk = ~clk;

    // -- Stimulus --
    initial begin
        $dumpfile("dump.vcd");
        $dumpvars(0, test);

        #20 reset = 0;        // release reset after 2 cycles
        #5  enable = 1;       // start counting
        #80 enable = 0;       // pause
        #20 enable = 1;       // resume
        #20 $finish;          // total simulation: ~145 units
    end

    // -- Monitoring on every rising edge --
    always @(posedge clk) begin
        $display("t=%0t reset=%b enable=%b count=%0d",
                 $time, reset, enable, count);
    end
endmodule

To kompletny testbench dla 4-bitowego licznika. Kliknij Run, a zobaczysz, jak licznik wychodzi z resetu, liczy w górę, gdy jest włączony, zatrzymuje się, gdy enable spada, wznawia liczenie, gdy rośnie, i się kończy.

Trzy rzeczy, na które warto zwrócić uwagę w strukturze:

1. Trzy odrębne ośrodki aktywności: generator zegara (jeden always), pobudzenie (jeden initial) i monitor (kolejny always). Każdy ma jedno zadanie.
2. Opóźnienia # w bloku pobudzenia są mierzone w jednostkach czasu, a nie w cyklach zegara. Jeśli okres zegara to 10 jednostek, #10 to dokładnie jeden cykl. Niektóre testbenche używają zamiast tego @(posedge clk), które przesuwa o jeden cykl niezależnie od okresu.
3. Monitor używa $display z bloku always @(posedge clk). To wypisuje coś w każdym cyklu. Do bardziej rozbudowanego wyjścia przejdź na $monitor (omówiony dalej).

Pobudzenie liczone w cyklach

Czasem "poczekaj N cykli" czyta się lepiej niż "poczekaj N jednostek czasu":

initial begin
    @(posedge clk);     // wait for next clock edge
    reset = 0;

    repeat (5) @(posedge clk);   // wait 5 more cycles
    enable = 1;

    repeat (8) @(posedge clk);
    enable = 0;

    repeat (10) @(posedge clk);
    $finish;
end

@(posedge clk) blokuje do następnego zbocza narastającego zegara. repeat (N) @(posedge clk); czeka N cykli. Ten styl nie zależy od okresu zegara: jeśli zmienisz częstotliwość zegara, pobudzenie nadal robi to samo w przeliczeniu na cykle.

W pierwszych testbenchach prostsze są opóźnienia #. W produkcyjnych testbenchach, które mogą działać przy różnych częstotliwościach zegara, bezpieczniejszy jest styl oparty na cyklach.

Testy samosprawdzające

Dotychczasowy testbench wypisuje, co się stało, a czytanie wyjścia zostawia tobie. Testbench samosprawdzający zamiast tego sprawdza wyjście i zgłasza wynik pozytywny albo negatywny:

initial begin
    #1;
    a = 10; b = 20;
    #1;
    if (sum !== 30) begin
        $display("FAIL: 10 + 20 = %0d (expected 30)", sum);
        $finish;
    end
    a = 250; b = 5;
    #1;
    if (sum !== 255) begin
        $display("FAIL: 250 + 5 = %0d (expected 255)", sum);
        $finish;
    end

    $display("PASS");
    $finish;
end

Dla bezpieczeństwa używaj !== (operatora nierówności dokładnej): nie zwraca x, gdy jeden z argumentów ma nieznane bity. Wzorzec: podaj wejścia, poczekaj na ustabilizowanie, porównaj z oczekiwaną wartością, zgłoś wynik.

Samosprawdzanie jest bezcenne w zestawach testów regresyjnych: tysiące testów mogą działać bez nadzoru, a uwagi wymagają tylko niepowodzenia.

Co dalej

Masz już kształt testbencha, który wystarczy dla każdego modułu. Kolejne artykuły omawiają narzędzia używane wewnątrz testbencha: Display i Monitor do bogatszego wyjścia tekstowego, Dumpfile i VCD do graficznego debugowania przebiegów oraz Timescale i opóźnienia do dokładnego kontrolowania, jak czas symulacji odnosi się do czasu rzeczywistego.