3. RTL仿真基础：Verilog/VHDL测试平台编写、时钟与复位生成、基本断言使用

各位同学，咱们今天聊聊RTL仿真最基础的东西。说实话，很多新人一上来就急着写复杂的验证环境，结果连最基本的时钟复位都搞出问题。我见过太多因为复位时序没处理好，导致仿真结果和实际芯片行为对不上的案例了。所以这一章，咱们把地基打牢。

3.1 测试平台（Testbench）的基本结构

测试平台说白了，就是给咱们的DUT（Design Under Test）搭个舞台。它没有端口，因为它是整个仿真的顶层。我习惯把Testbench分成三个部分：激励生成、DUT实例化、结果检查。

先看一个最简单的Verilog Testbench骨架：

module tb_gpu_core();

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

// 2. DUT实例化
gpu_core u_gpu_core (
    .clk     (clk),
    .rst_n   (rst_n),
    .data_in (data_in),
    .data_out(data_out)
);

// 3. 时钟生成
initial begin
    clk = 0;
    forever #5 clk = ~clk;  // 10ns周期，100MHz
end

// 4. 复位逻辑
initial begin
    rst_n = 0;
    #20;
    rst_n = 1;
end

// 5. 激励生成
initial begin
    data_in = 0;
    #30;
    data_in = 32'hA5A5_A5A5;
    #10;
    data_in = 32'h5A5A_5A5A;
    // ... 更多激励
end

// 6. 仿真控制
initial begin
    #1000;
    $finish;
end

endmodule

嗯，这里要注意几个点。第一，initial块是并行的，别以为它们按顺序执行。第二，我习惯把时钟和复位单独放在一个initial块里，这样后期维护起来方便。第三，$finish一定要加，不然仿真会一直跑下去。

3.2 时钟生成的几种方式

时钟生成看似简单，其实门道不少。我在项目中遇到过因为时钟抖动模型没加，导致后仿时序分析通过但芯片回来却出问题的尴尬事。

常用的时钟生成方式有三种：

方式 代码示例 适用场景
固定频率 forever #5 clk = ~clk; 功能仿真，最常用
带初始相位 initial begin clk=0; #2; forever #5 clk=~clk; end 多时钟域仿真，对齐相位
带抖动模型 forever #(5 + $random%2) clk = ~clk; 后仿或时序分析

我个人建议，功能仿真阶段用第一种就够了。但如果你在做GPU这种高频设计，最好在后期加上抖动模型。你想想看，实际芯片的时钟哪能那么完美？

3.3 复位信号的正确姿势

复位，这是个老生常谈但总有人踩坑的话题。我曾经见过一个同事，复位信号只拉了2个时钟周期，结果异步复位同步释放的逻辑根本没复位干净，仿真跑了一周才发现问题。

正确的复位做法是这样的：

// 异步复位，同步释放（推荐）
reg rst_n_sync;
always @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
        rst_n_sync <= 1'b0;
    end else begin
        rst_n_sync <= 1'b1;
    end
end

// 复位时长至少保持4个时钟周期
initial begin
    rst_n = 0;
    #40;  // 4个时钟周期 @100MHz
    rst_n = 1;
    #10;
    // 开始正常操作
end

这里有个避坑指南：我曾经在验证GPU的纹理单元时，复位只拉了3个周期，结果内部状态机有个状态没复位干净，导致纹理映射偶尔出错。后来花了整整两天才定位到这个问题。所以，复位时长宁长勿短，至少4个周期起步。

3.4 基本断言的使用

断言这东西，说白了就是给仿真加个自动检查器。你不用它也能干活，但用了它能让你少掉很多头发。

SystemVerilog断言（SVA）有三种基本类型：

  • 立即断言：写在过程块里，实时检查
  • 并发断言：基于时钟周期，检查时序关系
  • 属性断言：定义复杂的时序行为

看个实际例子，这是我在验证GPU的FIFO时用的断言：

// 立即断言：检查FIFO满时不能写
always @(posedge clk) begin
    if (fifo_full && wr_en) begin
        $error("FIFO满时写入数据！时间：%0t", $time);
    end
end

// 并发断言：读使能后2个周期数据必须有效
property p_read_data_valid;
    @(posedge clk)
    rd_en |=> ##2 data_valid;
endproperty
assert property (p_read_data_valid) else
    $fatal("读数据超时！");

// 覆盖断言：检查某种情况是否发生过
cover property (@(posedge clk) fifo_full && fifo_empty);
    // 这种情况理论上不会发生，如果发生了说明设计有bug

为什么断言这么重要？你想想看，如果不用断言，你得手动去波形里找问题。一个GPU设计动辄几百万门，波形文件几十个GB，你手动找？找到猴年马月去。

核心要点：断言不是可选项，是必需品。我建议每个模块至少加3-5个关键断言，覆盖输入输出协议、状态机跳转、FIFO满空等关键点。

3.5 实战中的小技巧

最后分享几个我在实际项目中积累的小技巧：

技巧一：用$display打印关键信息时，加上时间戳。比如$display("[%0t] data_out = %h", $time, data_out);。这样定位问题快得多。

技巧二：写Testbench时，把参数化做好。比如时钟周期、复位时长、数据位宽都用parameter定义。后期改参数时，改一处就行，不用满世界找。

警告：千万别在Testbench里用#0这种零延迟赋值。它会让仿真出现竞争冒险，结果每次跑都不一样。我见过有人因为这个，仿真结果时好时坏，折腾了一周才发现是#0惹的祸。

好了，这一章的内容就这些。记住，Testbench写得好不好，直接决定了你的验证效率。别嫌基础，基础打牢了，后面写复杂的验证环境才能得心应手。下一章咱们聊聊如何搭建一个可复用的验证框架，到时候你会感谢今天认真学基础的自己。

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