Verilog Testbench Basics: Como verificar um module

O que um testbench de fato é

Um testbench é apenas um module Verilog. A diferença em relação a um module sintetizável é o que está dentro:

• Não tem ports - é o topo da hierarquia de simulação.
• Instancia o design under test.
• Aciona as entradas do DUT a partir de blocos initial e always.
• Observa as saídas do DUT com $display, $monitor ou dumpando um VCD.
• Termina a simulação com $finish.

Esse é o trabalho inteiro. Não há palavra-chave especial "testbench" - a forma de saber que algo é um testbench é lendo o que ele faz.

O esqueleto padrão

// Design under test: um module minusculo que vamos testar.
module adder(
    input  wire [7:0] a,
    input  wire [7:0] b,
    output wire [8:0] sum
);
    assign sum = a + b;
endmodule

// Testbench: o resto deste arquivo.
module test;
    // -----------------------------------------------------------------
    // 1. Sinais para acionar o DUT e observar suas saidas.
    // -----------------------------------------------------------------
    reg  [7:0] a;
    reg  [7:0] b;
    wire [8:0] sum;

    // -----------------------------------------------------------------
    // 2. Instancia o DUT.
    // -----------------------------------------------------------------
    adder dut(.a(a), .b(b), .sum(sum));

    // -----------------------------------------------------------------
    // 3. Estimulo + ciclo de vida.
    // -----------------------------------------------------------------
    initial begin
        $dumpfile("dump.vcd");
        $dumpvars(0, test);

        // Aciona algumas combinacoes interessantes de entrada.
        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

Esse é o padrão inteiro. Cinco seções, fácil de copy-paste, fácil de adaptar.

Para DUTs combinacionais (como o adder), você não precisa de um clock. Para DUTs sequenciais, sim - e essa é a próxima camada acima.

Geração de clock para DUTs sequenciais

Quando o DUT tem uma entrada clk, o testbench tem que produzi-la. A one-liner padrão:

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

Isso alterna clk a cada 5 unidades de tempo. Cada toggle é meio período de clock, então o período inteiro é 10 unidades (um ciclo = alto por 5 + baixo por 5). Se seu timescale é 1ns / 1ps (padrão na maioria dos simuladores), isso é um clock de 100 MHz.

Escolha o meio-período com base no que quer modelar. Para um clock de 10 MHz no mesmo timescale, use #50. Para um clock de 200 MHz, #2.5 (ou mude o timescale).

Sequência de reset

Designs síncronos precisam de um reset que fica alto por alguns ciclos depois do tempo 0 e depois é liberado. A forma convencional:

reg reset = 1;     // comeca asserido

initial begin
    // Segura reset por alguns clocks.
    #20 reset = 0;
end

Isso mantém reset alto até o tempo 20, depois abaixa. Quando reset cai, o clock já deu alguns ciclos, cada flip-flop capturou o valor de reset e o design está em um estado conhecido.

Para reset active-low (reset_n em vez de reset), inverta o valor inicial:

reg reset_n = 0;   // active-low: 0 significa asserido

initial begin
    #20 reset_n = 1;
end

Um testbench sequencial por inteiro

Combinando clock, reset e estímulo:

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;
    // -- Sinais do DUT --
    reg  clk = 0;
    reg  reset = 1;
    reg  enable = 0;
    wire [3:0] count;

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

    // -- Gerador de clock (periodo de 10 unidades) --
    always #5 clk = ~clk;

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

        #20 reset = 0;        // libera reset apos 2 ciclos
        #5  enable = 1;       // comeca a contar
        #80 enable = 0;       // pausa
        #20 enable = 1;       // retoma
        #20 $finish;          // simulacao total: ~145 unidades
    end

    // -- Monitoramento em cada borda de subida --
    always @(posedge clk) begin
        $display("t=%0t reset=%b enable=%b count=%0d",
                 $time, reset, enable, count);
    end
endmodule

Esse é um testbench completo para um contador de 4 bits. Pressione Run e você verá o contador sair do reset, contar enquanto habilitado, pausar quando enable cai, retomar quando sobe e depois parar.

Três coisas para notar sobre a estrutura:

1. Três locais distintos de atividade: o gerador de clock (um always), o estímulo (um initial) e o monitor (outro always). Cada um tem um trabalho.
2. Os delays # no bloco de estímulo são medidos em unidades de tempo - não em ciclos de clock. Se seu período de clock é 10 unidades, então #10 é exatamente um ciclo. Alguns testbenches usam @(posedge clk) no lugar, que avança um ciclo independente do período.
3. O monitor usa $display a partir de um bloco always @(posedge clk). Isso imprime a cada ciclo. Para saída mais sofisticada, troque para $monitor (coberto a seguir).

Estímulo baseado em ciclos

Às vezes "esperar N ciclos" lê melhor que "esperar N unidades de tempo":

initial begin
    @(posedge clk);     // espera proxima borda de clock
    reset = 0;

    repeat (5) @(posedge clk);   // espera mais 5 ciclos
    enable = 1;

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

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

@(posedge clk) bloqueia até a próxima borda de subida de clock. repeat (N) @(posedge clk); espera N ciclos. Esse estilo é independente do período do clock - se você mudar a frequência do clock, o estímulo ainda faz a mesma coisa em termos de ciclos.

Para testbenches iniciais, delays # são mais simples. Para testbenches de produção que podem rodar em múltiplas velocidades de clock, baseado em ciclos é o estilo mais seguro.

Testes auto-verificáveis

O testbench até agora imprime o que aconteceu, deixando você ler a saída. Um testbench auto-verificável em vez disso verifica a saída e reporta pass/fail:

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

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

Use !== (o operador case-inequality) por segurança - ele não retorna x quando um operando tem bits desconhecidos. O padrão: acionar entradas, esperar coisas se estabilizarem, comparar com esperado, reportar pass ou fail.

Auto-verificação é inestimável em suítes de regressão: milhares de testes podem rodar sem atendimento, e só falhas precisam de atenção.

O que vem a seguir

Você agora tem a forma de testbench que basta para qualquer module. Os próximos docs cobrem as ferramentas que vão dentro do testbench: Display and Monitor para saída de texto mais rica, Dumpfile and VCD para debug visual com forma de onda, e Timescale and Delays para controlar exatamente como o tempo de simulação se relaciona com tempo de relógio.