一、仿真脚本概述

1.1 什么是仿真脚本

仿真脚本，说白了就是一段用来控制仿真工具运行的代码。你写好了设计代码，总得验证它能不能跑对吧？仿真脚本就是干这个的。

我个人习惯把仿真脚本比作「导演」。设计代码是演员，仿真工具是摄影机，而脚本就是告诉摄影机什么时候拍、拍什么、怎么拍的指令集。没有导演，演员和摄影机就是一盘散沙。

举个例子，一个最简单的 Verilog 仿真脚本长这样：

// 仿真脚本示例：testbench.v
module tb_counter;
    reg clk;
    reg rst_n;
    wire [3:0] count;
    
    // 实例化被测试模块
    counter uut (
        .clk(clk),
        .rst_n(rst_n),
        .count(count)
    );
    
    // 生成时钟
    always #5 clk = ~clk;
    
    // 测试流程
    initial begin
        $display("开始测试...");
        rst_n = 0;
        #20 rst_n = 1;
        #100 $display("测试完成，count = %d", count);
        $finish;
    end
endmodule

这段代码干了什么？它生成了一个时钟，给了个复位信号，然后观察计数器能不能正常工作。嗯，就这么简单。

1.2 仿真脚本的应用领域

你可能觉得仿真脚本就是芯片验证用的。其实它的应用范围比你想的宽得多。我在项目中遇到过不少跨界应用，这里列几个典型的：

• 数字芯片验证——这是最传统的领域。写 testbench，跑 RTL 仿真，检查功能对不对。我刚开始做芯片时，一个模块的仿真脚本能写到上千行。
• 模拟电路仿真——用 SPICE 或 FastSPICE 跑模拟电路，脚本控制扫描参数、保存波形。记得有一次调一个 PLL，脚本跑了整整三天三夜。
• FPGA 开发——写仿真脚本验证逻辑，再烧到板子上。我曾经因为仿真没覆盖全，板子调了两个月才发现是时序问题。
• 系统级仿真——用 SystemVerilog 或 UVM 搭验证环境，跑整个 SoC 的仿真。这个规模就大了，一个仿真环境可能几十万行代码。
• 自动化测试——脚本驱动仿真工具批量跑测试用例，自动比对结果。我建议每个团队都搞一套，能省下大量重复劳动。

应用领域	典型工具	脚本语言	复杂度
数字芯片验证	VCS, Questa, Xsim	SystemVerilog, Python	高
模拟电路仿真	Spectre, HSPICE	Ocean, Skill	中
FPGA 开发	Vivado, Quartus	Tcl, Python	中
系统级仿真	UVM, SystemC	C++, Python	极高

1.3 模块化开发的核心思想

好了，重点来了。模块化开发，说白了就是「分而治之」。你想想看，一个复杂的仿真环境，如果所有代码都写在一个文件里，那维护起来得多痛苦？

我曾经接手过一个项目，前辈把整个仿真脚本写成了一个 5000 行的文件。每次改一个参数，都得全局搜索半天。更可怕的是，他用了大量的全局变量，改一个地方可能崩十个地方。嗯，那段时间我做梦都在 debug。

模块化开发的核心思想就三条：

1. 高内聚，低耦合——每个模块只做一件事，模块之间通过接口通信。比如时钟生成模块只管生成时钟，复位模块只管产生复位信号，别混在一起。
2. 可复用——写一次，到处用。我习惯把常用的功能封装成函数或任务，比如 SPI 读写、I2C 配置、DMA 传输。下次换个项目，直接拿来用。
3. 可配置——用参数控制行为，而不是硬编码。比如时钟频率、数据位宽、测试用例数量，都做成参数。这样改需求时改参数就行，不用动代码。

下面这张图展示了模块化仿真脚本的典型结构：

看到这张图了吗？从上到下依次是测试用例层、场景层、模块层和配置层。每一层只依赖下一层提供的接口，不关心内部实现。这就是模块化的精髓。

最后说一句，模块化开发的核心思想其实不限于仿真脚本。你写任何代码，都可以用这个思路。说白了，就是把复杂问题拆成简单问题，然后逐个击破。这个道理听起来简单，但真正做到位，需要大量的实践和反思。

好了，这一章就到这里。记住：好的仿真脚本，不是写出来的，是设计出来的。

可可精品资料库