第四节：SystemVerilog基础回顾：OOP、随机化与断言

各位同学，咱们今天聊点实在的。SystemVerilog 这东西，说白了就是验证工程师的吃饭家伙。很多刚入行的朋友觉得它跟 Verilog 差不多，其实差远了。我个人习惯把 SystemVerilog 看作是「带着工具箱的 Verilog」——它不光能描述硬件，更重要的是给了你一套完整的验证方法论。

这一节我们重点回顾三个核心概念：面向对象编程（OOP）、随机化与约束、以及断言。这三个东西，你玩明白了，验证工作就能事半功倍。

4.1 面向对象编程在验证中的应用

先说说 OOP。很多做设计出身的朋友一开始会不适应，觉得「我写个模块为什么要搞 class？」。嗯，我刚开始也有这个疑问。直到有一次我做了一个复杂的总线协议验证，光是 transaction 的类型就定义了十几种，如果不用 class 封装，代码根本没法维护。

OOP 在验证中的核心思想，就是把「数据」和「操作数据的方法」打包在一起。举个例子：

class Packet;
    rand bit [7:0] addr;
    rand bit [7:0] data;
    rand bit       wr;  // 1: write, 0: read

    function void display();
        $display("Packet: addr=%0h, data=%0h, wr=%0b", addr, data, wr);
    endfunction
endclass

你看，这个 Packet 类把地址、数据、读写控制都封装在一起了。你创建一个对象，它就自带这些属性和方法。我在项目中遇到过有人把 transaction 定义成一大堆散落的 wire 和 reg，结果后来要加个字段，改得想哭。

OOP 的三个基本特性——封装、继承、多态——在验证中都有用武之地：

• 封装：把数据和操作藏起来，对外只暴露接口。比如你写一个 driver，内部怎么驱动总线的细节，外界不需要知道。
• 继承：从基类派生子类，复用代码。比如你有一个通用的 Sequence，可以派生出具体的读 Sequence、写 Sequence。
• 多态：通过虚方法实现不同对象的统一处理。这在 scoreboard 里特别常见，一个 compare 函数可以处理各种类型的 transaction。

4.2 随机化与约束

随机化是 SystemVerilog 验证的灵魂。为什么？因为你要用有限的测试用例覆盖无限的可能输入。手动写测试向量？那得写到猴年马月去。

随机化的核心是 rand 和 randc 关键字。加上它们，变量就可以被随机化：

class Transaction;
    rand bit [31:0] address;
    rand bit [7:0]  data;
    randc bit [3:0] burst_len;  // 循环随机，保证所有值都会出现
endclass

但光随机还不够，你得加约束。不然随机出来的地址可能是 0xDEADBEEF，你的 DUT 根本处理不了。约束用 constraint 块来写：

class Transaction;
    rand bit [31:0] address;
    rand bit [7:0]  data;

    constraint addr_range {
        address inside {[32'h1000 : 32'h1FFF]};
        address % 4 == 0;  // 地址对齐
    }

    constraint data_valid {
        data != 8'h00;  // 避免全零数据
    }
endclass

这里要注意，约束是可以叠加的。你可以在不同的地方加约束，SystemVerilog 会帮你解这个约束方程组。说白了，你告诉它「我要什么」，它帮你生成「满足条件的值」。

随机化还有一个好兄弟叫 randomize() 函数。调用它，所有 rand 变量都会被赋随机值。如果随机化失败，它会返回 0。所以记得检查返回值：

Transaction tr = new();
if (!tr.randomize()) begin
    $error("Randomization failed!");
end

嗯，这里有个小技巧：你可以用 randomize() with { ... } 来临时加约束，不用改类定义：

if (!tr.randomize() with { address == 32'h1000; }) begin
    $error("Randomization failed!");
end

这样就能定向生成一个地址为 0x1000 的 transaction，非常灵活。

4.3 断言的基本语法

断言是什么？说白了就是「检查器」。你告诉它「某个条件应该一直成立」，它帮你盯着。如果条件不成立，它就报错。我在项目中遇到过很多 bug，都是靠断言抓出来的——有些 bug 在波形上根本看不出来，但断言一跑就现原形。

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

立即断言：用 assert 关键字，像 if 语句一样执行：

always @(posedge clk) begin
    assert (data_valid == 1'b1) else $error("Data valid is low!");
end

这种断言简单直接，适合检查组合逻辑或时序逻辑的某个瞬间状态。

并发断言：用 assert property，可以检查跨多个时钟周期的行为。这才是断言的真正威力所在：

property p_req_ack;
    @(posedge clk)
    req |=> ##[1:3] ack;  // req 拉高后，1到3个周期内 ack 必须拉高
endproperty

assert property (p_req_ack) else $error("Request not acknowledged in time!");

这里 |=> 表示「下一个时钟周期」，##[1:3] 表示「1到3个周期内」。你想想看，这种跨周期的时序检查，用手写 Verilog 得写多少状态机？断言一行就搞定了。

常用的断言操作符我列一下：

最后说一句，断言写多了也会影响仿真性能。所以建议只对关键协议行为写断言，别什么都往上堆。我曾经见过有人一个模块写了 200 个断言，仿真慢得像蜗牛爬。嗯，适度就好。

好了，这一节的内容就到这里。OOP 帮你组织代码，随机化帮你生成测试，断言帮你检查结果——这三板斧用好了，验证工作就稳了。下一节我们开始讲实际的验证策略，到时候会用到这些基础知识。