3. Testbench 基础：结构、DUT 实例化、时钟复位与 always/initial

各位同学，今天我们来聊聊 Testbench。说白了，Testbench 就是咱们验证工程师的“实验台”。你把设计好的 DUT（Design Under Test）往上一放，接上各种激励，然后观察它的反应。我刚开始学验证那会儿，总觉得写 Testbench 就是随便写写，能跑就行。结果有一次，因为时钟复位没处理好，前仿真跑得欢，后仿真直接崩了……从那以后，我再也不敢小看这个“实验台”的搭建了。

3.1 Testbench 的基本结构

一个标准的 Testbench，通常包含以下几个部分。我习惯把它想象成一个“测试夹具”：

• 模块声明：Testbench 本身没有输入输出端口，所以 module testbench; 后面直接跟内部信号声明。
• 内部信号声明：用来连接 DUT 的端口，比如 reg 类型驱动输入，wire 类型捕获输出。
• DUT 实例化：把被测模块“装”到 Testbench 里。
• 时钟与复位生成：提供最基本的时序驱动。
• 激励生成：用 initial 或 always 块产生测试序列。
• 响应监测：打印波形或自动比对结果。

嗯，这里要注意，Testbench 的顶层不应该有任何端口。它就是一个封闭的“黑盒测试环境”。

3.2 DUT 实例化——把设计“装”进来

实例化 DUT 是连接 Testbench 和设计的关键一步。我个人习惯用“名字关联”的方式，这样代码可读性更好，也不容易因为端口顺序搞错而出问题。

// 假设 DUT 是一个简单的计数器
module counter (
    input         clk,
    input         rst_n,
    input         en,
    output reg [7:0] count
);

// 在 Testbench 中实例化
module tb_counter;

    reg         clk;
    reg         rst_n;
    reg         en;
    wire [7:0]  count;

    // 实例化 DUT，使用名字关联
    counter u_dut (
        .clk    (clk),
        .rst_n  (rst_n),
        .en     (en),
        .count  (count)
    );

endmodule

3.3 时钟与复位生成——验证的“心跳”

时钟和复位，是数字电路的“心跳”和“重启键”。我见过不少新手，时钟生成写得花里胡哨，结果仿真波形里全是 X 态。其实，最常用的就那么几种写法。

时钟生成

最经典的写法是用 always 块配合取反操作。我个人偏爱这种，简单直接：

// 方法一：使用 always 块
parameter CLK_PERIOD = 10;  // 时钟周期 10ns
reg clk;

initial begin
    clk = 0;
end

always #(CLK_PERIOD/2) clk = ~clk;

还有一种是用 forever 循环，效果一样：

// 方法二：使用 forever 循环
initial begin
    clk = 0;
    forever #(CLK_PERIOD/2) clk = ~clk;
end

复位生成

复位信号通常用 initial 块来模拟上电行为。我习惯先拉低复位，等几个时钟周期后再释放：

// 异步复位，低有效
initial begin
    rst_n = 0;          // 初始复位
    #(CLK_PERIOD * 5);  // 保持 5 个时钟周期
    rst_n = 1;          // 释放复位
    #(CLK_PERIOD * 2);  // 再等 2 个周期，让系统稳定
end

你想想看，如果复位时间太短，DUT 内部的状态机可能还没初始化完，仿真结果就会出错。所以，我一般至少保持 5 个时钟周期的复位宽度。

3.4 initial 与 always 块的使用

这两个是 Verilog 中最重要的行为描述语句。简单来说：

• initial 块：只执行一次，适合做初始化、生成单次激励。
• always 块：循环执行，适合做时钟、周期性信号、持续监测。

initial 块——一次性的“启动脚本”

我通常用 initial 块来做三件事：初始化寄存器、生成复位、产生测试序列。

initial begin
    // 初始化
    en = 0;
    // 等待复位释放
    @(posedge rst_n);
    // 等待 10 个时钟周期
    repeat(10) @(posedge clk);
    // 使能计数器
    en = 1;
    // 运行 100 个周期后停止
    repeat(100) @(posedge clk);
    en = 0;
    // 结束仿真
    #100 $finish;
end

always 块——循环的“守护进程”

always 块最常用的场景就是时钟生成和信号监测。比如，我想在时钟上升沿检查输出是否正确：

always @(posedge clk) begin
    if (rst_n) begin
        // 检查计数器是否按预期递增
        if (en) begin
            if (count !== prev_count + 1) begin
                $error("Count mismatch at time %0t", $time);
            end
            prev_count <= count;
        end
    end
end

为什么会用 always @(posedge clk)？因为这样能保证检查逻辑和 DUT 的时序同步，避免竞争冒险。我在项目中吃过这个亏——用 always @(*) 去检查时序逻辑的输出，结果仿真波形里全是毛刺。

3.5 知识体系总览

为了让你更直观地理解 Testbench 的结构，我画了一张图。你可以把它当作一个“地图”，写代码时对照着看，不容易漏掉关键部分。

3.6 实战建议与避坑总结

最后，我把自己这些年踩过的坑和积累的经验，整理成了一张表。你写 Testbench 时，可以对照着检查：

组件	常见错误	我的建议
时钟生成	用 #1 写死延迟，不可配置	用 parameter 定义周期，方便修改
复位生成	复位宽度不够，或未考虑异步复位同步释放	至少保持 5 个时钟周期，后仿真时注意复位同步
DUT 实例化	使用位置关联，端口顺序容易错	一律使用名字关联（.port_name(signal)）
initial 块	多个 initial 块之间时序依赖混乱	用事件（@(posedge clk)）同步，避免时间
always 块	敏感列表不全，导致仿真与综合不一致	时序逻辑用 @(posedge clk)，组合逻辑用 @(*)