4. SystemVerilog验证基础：接口、断言、覆盖率、随机化

好，咱们今天聊聊SystemVerilog验证的四个核心支柱。说实话，这四个东西要是用好了，你的验证环境会非常灵活、可维护，而且能真正帮你找到bug。我刚开始从Verilog转向SystemVerilog时，觉得这些语法花里胡哨的，后来才发现——嗯，真香。

4.1 接口（interface）——把连线管起来

先说说接口。你想想看，传统Verilog里，模块之间通信靠什么？靠端口列表。一个AXI总线，少说几十根信号，每个模块都要写一遍端口声明，累不累？而且一旦要加个信号，所有相关模块都得改。

接口就是来解决这个问题的。它把一组相关的信号封装在一起，像一个“线束”。

interface axi_if (input clk, rst_n);
    logic [31:0] awaddr;
    logic        awvalid;
    logic        awready;
    logic [31:0] wdata;
    logic        wvalid;
    logic        wready;
    logic [1:0]  bresp;
    logic        bvalid;
    logic        bready;
    // ... 还有ar、r通道
endinterface

使用时，模块端口直接声明为接口类型：

module axi_slave (axi_if bus);
    always_ff @(posedge bus.clk or negedge bus.rst_n) begin
        if (!bus.rst_n) begin
            // 复位逻辑
        end else begin
            if (bus.awvalid && bus.awready) begin
                // 处理写地址
            end
        end
    end
endmodule

我个人习惯在接口里加上modport，用来区分不同角色的信号方向。比如master和slave看到的信号方向是相反的：

interface axi_if;
    // 信号声明...
    modport master (output awaddr, awvalid,
                    input  awready, ...);
    modport slave  (input  awaddr, awvalid,
                    output awready, ...);
endinterface

4.2 断言（assertion）——给设计上“监控”

断言是什么？说白了，就是你在代码里埋的“哨兵”。它时刻盯着关键信号，一旦出现非法情况，立刻报警。

SystemVerilog断言分两种：立即断言和并发断言。

立即断言：像if语句一样，在过程块里执行。

always_comb begin
    // 状态机不能进入非法状态
    assert (state != ILLEGAL_STATE)
        else $error("状态机进入非法状态: %0d", state);
end

并发断言：基于时钟周期，可以描述时序关系。这才是重头戏。

// 握手协议：valid有效后，ready必须在3个周期内拉高
property handshake;
    @(posedge clk) disable iff (!rst_n)
        $rose(valid) |-> ##[1:3] ready;
endproperty
assert_handshake: assert property (handshake);

我曾经在一个DDR控制器项目里，漏写了一个断言，结果仿真跑了两天发现一个地址冲突的bug。从那以后，我对断言的态度就是：能加就加，宁可错杀一千，不可放过一个。

4.3 覆盖率（covergroup）——你测了哪些角落？

验证工作最怕什么？最怕你觉得自己测全了，实际上还有一堆场景没跑到。覆盖率就是你的“体检报告”。

SystemVerilog里用covergroup来定义覆盖率模型。它可以收集功能覆盖率，而不仅仅是代码覆盖率。

covergroup fifo_cg @(posedge clk);
    wr_en_cp: coverpoint wr_en;
    rd_en_cp: coverpoint rd_en;
    fifo_level_cp: coverpoint fifo_level {
        bins low    = {[0:15]};
        bins medium = {[16:31]};
        bins high   = {[32:47]};
        bins full   = {48};
    }
    cross_wr_rd: cross wr_en_cp, rd_en_cp;
endgroup

这个例子中，我定义了写使能、读使能、FIFO深度的覆盖点，还做了交叉覆盖——看看同时读写的情况是否被测试到。

我个人习惯在验证计划阶段就定义好covergroup，而不是等仿真跑完了再补。为什么？因为提前定义能帮你理清测试思路——你到底要测哪些场景？

4.4 随机化（randomization）——让测试用例自己“长”出来

传统验证写定向测试，一个用例一个用例地写，累死累活还测不全。随机化就是让工具帮你生成大量合法且多样的测试场景。

SystemVerilog用randomize()函数实现随机化。你只需要定义好约束：

class transaction;
    rand bit [31:0] addr;
    rand bit [7:0]  data;
    rand bit        burst;
    
    // 约束：地址对齐，burst模式下地址递增
    constraint addr_aligned {
        addr % 4 == 0;
    }
    constraint burst_mode {
        if (burst) addr[1:0] == 2'b00;
    }
endclass

transaction tr = new();
repeat (100) begin
    assert(tr.randomize());
    // 驱动tr到DUT
end

你看，100个随机测试用例，一行循环就搞定了。而且约束保证了所有用例都是合法的——地址对齐、burst模式正确。

这里有个坑：随机化不是乱随机。我曾经见过一个同事，约束写得不够严格，结果生成了大量无效用例，仿真跑了一周才发现问题。所以，约束一定要仔细设计，尤其是边界条件。

4.5 四者如何协同？

接口、断言、覆盖率、随机化，这四个东西不是孤立的。它们协同起来，才能构建一个高效的验证环境。

我画了一张图，帮你理清它们的关系：

接口是骨架，把DUT和验证环境连接起来；断言是眼睛，时刻盯着信号是否违规；覆盖率是尺子，衡量你测了多少；随机化是发动机，源源不断产生测试用例。

我的经验是：先搭好接口，定义好断言，再写随机化用例，最后用覆盖率指导迭代。这个流程走下来，验证质量基本有保障。

---