第三课：Testbench结构——DUT实例化、时钟与复位生成、initial与always块、仿真时间尺度

各位同学，欢迎来到第三课。上一讲我们聊了验证环境的整体框架，今天咱们把目光聚焦到最基础、也最容易被忽视的部分——Testbench的结构。

说白了，Testbench就是给DUT（Design Under Test）搭的一个“测试台”。你得给它供电（时钟）、给它复位（清零）、给它喂数据（激励），然后看它怎么干活。我见过不少新手，一上来就急着写复杂的验证用例，结果连最基本的时钟都生错了，仿真跑出来一堆X态，还以为是DUT的bug。嗯，这里要注意，基础不牢，地动山摇。

一、DUT实例化——把被测模块“请”进来

DUT实例化，就是把你的设计模块“嵌入”到Testbench中。这步做不好，后面全是白搭。

我个人习惯，在实例化时把端口连接写得清清楚楚，哪怕多写几行也不怕。你想想看，如果端口连错了，仿真结果就是错的，你花再多时间debug也是白费。

核心要点：

  • 使用.port_name(signal_name)的显式连接方式，别用位置映射
  • 所有输入端口必须驱动，不能悬空
  • 输出端口要接到reg或wire上，方便后续检查
// 一个典型的DUT实例化示例
module tb_top;

  // 声明信号
  reg        clk;
  reg        rst_n;
  reg  [7:0] data_in;
  wire [7:0] data_out;

  // DUT实例化——显式连接，一目了然
  my_design u_dut (
    .clk     (clk),
    .rst_n   (rst_n),
    .data_in (data_in),
    .data_out(data_out)
  );

endmodule

我曾经遇到过一个项目，同事用位置映射实例化，结果模块端口顺序改了，他那边没同步更新，仿真跑了三天才发现数据全是乱的。从那以后，我坚持只用显式连接，多写几个字，省下三天debug时间，这笔账怎么算都划算。

二、时钟与复位生成——Testbench的“心跳”

时钟和复位，是Testbench里最基础的两个信号。它们要是出问题，整个仿真就没法玩了。

时钟生成

时钟生成其实很简单，但写法上有讲究。我推荐用always块配合#delay来实现，这样最直观。

// 50MHz时钟，周期20ns
parameter CLK_PERIOD = 20;  // 单位ns

initial begin
  clk = 0;
  forever #(CLK_PERIOD/2) clk = ~clk;
end

// 或者用always块
always #(CLK_PERIOD/2) clk = ~clk;

小技巧：我习惯把时钟周期定义成parameter，这样换频率时改一个地方就行。别把数字写死在代码里，否则后期维护会想哭。

复位生成

复位信号的设计，直接关系到DUT能否正确初始化。我见过有人把复位和时钟搞成同步关系，结果仿真时复位释放的时机不对，DUT一直处于复位状态，啥活都不干。

// 异步复位，同步释放（推荐做法）
initial begin
  rst_n = 0;          // 先拉低复位
  #(CLK_PERIOD * 10); // 保持10个时钟周期
  @(posedge clk);     // 在时钟上升沿释放
  rst_n = 1;
end

为什么要在时钟上升沿释放复位？说白了，就是为了避免复位释放时出现亚稳态。我在项目中吃过这个亏，复位释放刚好在时钟边沿附近，导致DUT内部状态机初始化失败，仿真结果时好时坏。后来改成同步释放，问题就再没出现过。

三、initial与always块——仿真的“两条腿”

Verilog里，initial和always是两大基本过程块。它们就像人的两条腿，缺一不可。

initial块——只跑一次

initial块在仿真开始时执行一次，适合做初始化、生成激励、控制仿真流程。

initial begin
  // 初始化信号
  data_in = 8'h00;
  
  // 等待复位完成
  @(posedge rst_n);
  #100;
  
  // 发送第一个数据
  data_in = 8'hA5;
  #(CLK_PERIOD);
  data_in = 8'h5A;
  
  // 仿真结束
  #1000;
  $finish;
end

always块——循环执行

always块会一直重复执行，适合生成时钟、监控信号、实现协议。

// 监控数据输出变化
always @(posedge clk) begin
  if (data_out != expected_data) begin
    $display("ERROR: data mismatch at time %0t", $time);
  end
end

警告：千万别在always块里写死循环！比如always #5 clk = ~clk;这种没问题，但如果你写always begin #5; end，仿真器会卡死。我刚开始学的时候就犯过这个错，仿真跑了一晚上，第二天发现啥结果都没有，全卡在循环里了。

四、仿真时间尺度——`timescale的“坑”

仿真时间尺度，用`timescale指令来设置。它决定了#delay中的数字代表多长时间。

`timescale 1ns / 1ps
// 时间单位是1ns，精度是1ps

这里有个容易踩的坑：时间精度必须小于等于时间单位。比如`timescale 1ns / 1ps是合法的，但`timescale 1ps / 1ns就不行，因为精度（1ns）比单位（1ps）还大，仿真器会报错。

常见设置 时间单位 时间精度 适用场景
`timescale 1ns / 1ps 1ns 1ps 数字逻辑仿真（最常用）
`timescale 1ps / 1ps 1ps 1ps 高速接口仿真（如DDR）
`timescale 1us / 1ns 1us 1ns 慢速信号仿真（如I2C）

我个人建议，整个项目统一使用`timescale 1ns / 1ps。为什么？因为大多数数字模块的工作频率在MHz到GHz之间，1ns的粒度刚刚好。精度设到1ps，又能满足时序检查的需求。我曾经在一个项目里看到不同模块用了不同的timescale，结果仿真时时间对齐出了问题，debug了整整两天才发现是timescale不统一。从那以后，我就在项目规范里强制要求统一timescale。

避坑指南：

  • 每个文件都要写`timescale，别指望编译器自动继承
  • 不同文件用不同的timescale时，仿真器会取最小精度，但容易出问题
  • $time和$realtime的输出格式受timescale影响，注意区分

五、综合示例——一个完整的Testbench骨架

好了，知识点都讲完了，咱们来拼一个完整的Testbench骨架。你把这个框架记住，以后写Testbench就往里套。

`timescale 1ns / 1ps

module tb_top;

  // 参数定义
  parameter CLK_PERIOD = 20;  // 50MHz

  // 信号声明
  reg        clk;
  reg        rst_n;
  reg  [7:0] data_in;
  wire [7:0] data_out;

  // DUT实例化
  my_design u_dut (
    .clk     (clk),
    .rst_n   (rst_n),
    .data_in (data_in),
    .data_out(data_out)
  );

  // 时钟生成
  initial begin
    clk = 0;
    forever #(CLK_PERIOD/2) clk = ~clk;
  end

  // 复位生成（异步复位，同步释放）
  initial begin
    rst_n = 0;
    #(CLK_PERIOD * 10);
    @(posedge clk);
    rst_n = 1;
  end

  // 激励生成
  initial begin
    // 初始化
    data_in = 8'h00;
    
    // 等待复位完成
    @(posedge rst_n);
    #100;
    
    // 发送测试数据
    data_in = 8'hA5;
    #(CLK_PERIOD);
    data_in = 8'h5A;
    #(CLK_PERIOD);
    data_in = 8'hFF;
    
    // 等待一段时间后结束仿真
    #1000;
    $finish;
  end

  // 结果监控
  always @(posedge clk) begin
    if (rst_n && (data_out !== 8'hxx)) begin
      // 这里可以加断言或检查逻辑
      $display("Time %0t: data_out = %h", $time, data_out);
    end
  end

endmodule

这个骨架虽然简单，但五脏俱全。你把它吃透了，再复杂的Testbench也就是在这个基础上加加减减。记住，验证工程师的核心能力不是写多炫酷的代码，而是把基础的东西做到极致，不出错。

好，这一课就到这里。下一讲我们会聊“仿真波形查看与调试技巧”，到时候我会分享一些我在项目中用到的“独门秘籍”，敬请期待。

← 上一章 📖 返回目录 下一章 →