4. RTL设计与仿真基础：Verilog HDL核心语法回顾、模块化设计方法、Testbench编写技巧、Vivado Simulator使用

这一章，我们回到最基础的东西。别觉得基础就简单，我见过太多项目翻车，都是因为RTL写得不严谨，或者仿真没做透。咱们今天就把地基夯实。

4.1 Verilog HDL核心语法回顾

说实话，Verilog语法用熟了，翻来覆去就那么几个核心结构。我平时写RTL，90%的代码都在用下面这些。

4.1.1 模块与端口

模块是Verilog的基本单元。每个模块就是一个硬件块，端口就是它的引脚。

module counter #(
    parameter WIDTH = 8
)(
    input  wire             clk,
    input  wire             rst_n,
    input  wire             en,
    output reg  [WIDTH-1:0] count
);
    // 内部逻辑
endmodule

这里有个小细节：#(parameter WIDTH = 8) 是可参数化的。我在项目中经常用这个，同一个计数器模块，8位、16位、32位都能复用，省事得很。

4.1.2 阻塞赋值与非阻塞赋值

这是新手最容易踩的坑。我简单总结一下：

  • 阻塞赋值 (=)：顺序执行，用于组合逻辑。比如 always @(*) 里面。
  • 非阻塞赋值 (<=)：并行执行，用于时序逻辑。比如 always @(posedge clk) 里面。
我曾经犯过一个错：在时序逻辑里混用了阻塞赋值，结果仿真波形对，上板就跑飞。查了两天才发现是赋值方式的问题。记住一个原则：写寄存器，就用 <=；写组合逻辑，就用 =。

4.1.3 常用结构：always、assign、if-else、case

这些是基本功，但写法上有讲究。

// 组合逻辑：用 assign 或 always @(*)
assign data_out = (sel) ? data_a : data_b;

// 时序逻辑：用 always @(posedge clk)
always @(posedge clk or negedge rst_n) begin
    if (!rst_n)
        count <= 0;
    else if (en)
        count <= count + 1;
end

// 多分支：用 case
always @(*) begin
    case (state)
        2'b00: next_state = IDLE;
        2'b01: next_state = RUN;
        2'b10: next_state = DONE;
        default: next_state = IDLE;
    endcase
end

你想想看，case 语句如果不写 default，综合出来会多一堆锁存器。我每次代码评审都会盯着这个看。

4.2 模块化设计方法

模块化说白了就是「分而治之」。一个复杂的RISC-V处理器，你不可能在一个文件里写完。我习惯把它拆成几个功能块。

4.2.1 为什么需要模块化？

  • 可读性：每个模块只干一件事，代码清晰。
  • 可复用：写好的ALU模块，下个项目还能用。
  • 可调试：出问题了，定位到具体模块，不用大海捞针。

4.2.2 模块划分原则

我个人习惯按功能边界来切。比如一个简单的RISC-V处理器，可以分成：

模块名 功能描述 接口信号
core_top 顶层模块，连接所有子模块 clk, rst_n, instr, data
alu 算术逻辑单元，执行运算 opcode, a, b, result
regfile 寄存器堆，存储通用寄存器 raddr1, raddr2, waddr, wdata
ctrl 控制单元，生成控制信号 instr, alu_ctrl, mem_ctrl
mem_if 存储器接口，读写数据 addr, rdata, wdata, we

嗯，这里要注意：模块之间的接口信号要尽量少，耦合度越低越好。我在项目中吃过亏，一个模块改了接口，牵连了七八个模块都要改，那叫一个痛苦。

4.2.3 模块化设计示例

拿ALU模块举个例子：

module alu #(
    parameter DW = 32
)(
    input  wire [DW-1:0]    a,
    input  wire [DW-1:0]    b,
    input  wire [3:0]       alu_op,
    output reg  [DW-1:0]    result
);
    always @(*) begin
        case (alu_op)
            4'b0000: result = a + b;       // ADD
            4'b0001: result = a - b;       // SUB
            4'b0010: result = a & b;       // AND
            4'b0011: result = a | b;       // OR
            4'b0100: result = a ^ b;       // XOR
            default: result = 0;
        endcase
    end
endmodule

这个模块只做一件事：根据操作码执行运算。测试起来也简单，给不同的alu_op，看result对不对就行。

4.3 Testbench编写技巧

写Testbench，说白了就是模拟一个「测试环境」来验证你的RTL对不对。我刚开始做验证时，总觉得随便写个激励就行，后来发现根本不是那么回事。

4.3.1 Testbench的基本结构

一个标准的Testbench包含这几部分：

  • DUT实例化：把待测模块接进来。
  • 时钟和复位生成：给DUT提供基本时序。
  • 激励生成：模拟输入信号。
  • 结果检查：自动比对输出是否正确。
module tb_alu();
    // 信号声明
    reg  [31:0] a, b;
    reg  [3:0]  alu_op;
    wire [31:0] result;

    // DUT实例化
    alu #(.DW(32)) u_alu (
        .a(a),
        .b(b),
        .alu_op(alu_op),
        .result(result)
    );

    // 时钟生成
    reg clk = 0;
    always #5 clk = ~clk;

    // 激励生成
    initial begin
        // 测试ADD
        a = 32'h00000001;
        b = 32'h00000002;
        alu_op = 4'b0000;
        #10;
        // 检查结果
        if (result !== 32'h00000003)
            $display("ERROR: ADD failed");
        // 测试SUB
        a = 32'h00000005;
        b = 32'h00000003;
        alu_op = 4'b0001;
        #10;
        if (result !== 32'h00000002)
            $display("ERROR: SUB failed");
        $finish;
    end
endmodule

这里有个技巧：用 $display 打印错误信息，比手动看波形快多了。我习惯在Testbench里加一个「错误计数器」，跑完直接看总共有几个错误。

4.3.2 自检式Testbench

手动看波形太累了。我推荐写自检式Testbench，就是让仿真自动判断结果对不对。

reg [31:0] expected;
integer error_count = 0;

always @(posedge clk) begin
    case (alu_op)
        4'b0000: expected = a + b;
        4'b0001: expected = a - b;
        // ...
    endcase
    if (result !== expected) begin
        $display("Time=%0t: ERROR: result=%h, expected=%h", $time, result, expected);
        error_count = error_count + 1;
    end
end

initial begin
    #1000;
    if (error_count == 0)
        $display("All tests passed!");
    else
        $display("Total errors: %0d", error_count);
    $finish;
end

你想想看，这样跑完仿真，一眼就知道结果对不对，省了多少事。

4.3.3 覆盖率与随机化

光测几个固定值不够。我建议用随机化来覆盖更多场景。

initial begin
    repeat (1000) begin
        a = $random;
        b = $random;
        alu_op = $random % 5;  // 随机操作码
        #10;
    end
end

但要注意：随机化不能替代定向测试。边界情况（比如a=0, b=最大值）还是要手动测。

4.4 Vivado Simulator使用

Vivado自带的仿真器，说实话够用了。我平时做RISC-V原型验证，基本就用它。

4.4.1 仿真流程

  1. 创建仿真工程：在Vivado里添加RTL文件和Testbench。
  2. 设置仿真选项：选择仿真时间、波形保存等。
  3. 运行仿真：点击「Run Simulation」。
  4. 查看波形：在波形窗口观察信号变化。

4.4.2 常用Tcl命令

用图形界面点来点去太慢了。我习惯用Tcl命令，效率高得多。

# 启动仿真
launch_simulation

# 添加波形信号
add_wave /tb_alu/u_alu/*

# 运行指定时间
run 1000 ns

# 重新启动仿真
restart

# 退出仿真
stop_simulation

嗯，这里要注意：add_wave 可以加通配符，一下子把整个模块的信号都加进来，省得一个个点。

4.4.3 调试技巧

  • 使用$display：在RTL里加打印信息，快速定位问题。
  • 波形对比：把预期波形和实际波形叠在一起看。
  • 断点调试：在特定时间点暂停仿真，检查内部状态。
我个人习惯：在RTL里加一个「调试模式」参数。调试时打开，会打印关键信号；正式综合时关掉，不影响性能。这样既方便调试，又不会增加额外逻辑。

4.5 本章知识体系

下面这张图，把本章的核心内容串起来了。你一看就明白：RTL设计、模块化、Testbench、仿真工具，它们之间是什么关系。

RTL设计与仿真知识体系 RTL设计与仿真知识体系 RTL设计 Verilog核心语法 模块化设计方法 Testbench编写 Vivado Simulator 核心逻辑 RTL设计是基础，模块化让代码可复用，Testbench验证正确性，Vivado Simulator是验证工具。 四者环环相扣，缺一不可。

这一章的内容，说白了就是让你掌握RTL设计和仿真的基本功。后面做RISC-V处理器原型验证，这些都会反复用到。别急，慢慢来，把基础打牢了，后面就顺了。

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