4. SystemVerilog中的随机化：rand与randc关键字、随机化类、约束块

好，咱们进入随机化这个环节。说实话，做数字验证这么多年，我最大的体会就是：没有随机化，你根本测不干净你的设计。你想想看，靠手写几百个定向测试用例，能覆盖多少种情况？我当年刚入行时，就吃过这个亏——一个简单的FIFO，我写了50个测试，结果流片回来，某个边界条件没测到，直接挂掉。从那以后，我对随机化就特别上心。

4.1 为什么需要随机化？

说白了，芯片验证的核心目标就是用有限的测试，覆盖无限的可能。手动写测试，你只能覆盖你想到的场景。而随机化，能帮你自动生成你没想到的场景。

我个人习惯把随机化分成两类：

• 数据随机化：比如随机生成地址、数据、配置参数
• 时序随机化：比如随机插入延迟、随机改变握手信号时序

这两者在SystemVerilog里，都靠rand和randc这两个关键字来实现。

4.2 rand vs randc：到底有啥区别？

很多初学者搞不清这两个东西。我直接给你一个最直白的解释：

什么时候用randc？ 我举个例子。你在验证一个仲裁器，有8个请求源。如果你用rand，可能连续100次都随机到同一个源，其他7个源根本没被测试到。这时候用randc，就能保证每个源都被公平地测试到。

4.3 随机化类：把随机变量封装起来

在实际项目中，我们不会把随机变量散落在各个地方。我习惯的做法是：定义一个专门的随机化类，把所有需要随机的东西封装在一起。

来看一个我常用的模板：

class Transaction;
    rand bit [31:0] addr;
    rand bit [7:0]  data;
    rand bit        write_en;
    randc bit [3:0] burst_len;  // 循环随机，保证每种长度都被测到

    // 约束块，后面会细讲
    constraint addr_range {
        addr inside {[32'h0000_0000 : 32'h0000_FFFF]};
    }
endclass

嗯，这里要注意：类里的变量必须声明为rand或randc，才能被随机化。普通变量是不能被randomize()函数影响的。

4.4 约束块：让随机变得可控

随机化不是瞎随机。你想想看，如果地址随机到0xFFFFFFFF，而你的设计只支持0x0000-0xFFFF，那这个随机就是废的。所以我们需要约束块来限定随机范围。

约束块的语法很简单，但用起来有很多门道。我把自己踩过的坑总结一下：

4.4.1 基本约束写法

class MyPacket;
    rand bit [7:0] len;
    rand bit [7:0] payload [];

    // 约束1：长度范围
    constraint len_c {
        len inside {[10:100]};
    }

    // 约束2：动态数组大小与长度一致
    constraint payload_c {
        payload.size() == len;
    }

    // 约束3：避免全0或全1
    constraint avoid_extreme {
        len != 0;
        len != 255;
    }
endclass

4.4.2 我曾经踩过的坑：约束冲突

有一次，我写了两个约束块，一个要求len > 50，另一个要求len < 30。结果随机化一直失败，我查了半天才发现是约束冲突。所以记住：所有约束必须同时满足，否则随机化会返回0（失败）。

4.4.3 实用约束技巧

• inside运算符：指定范围或集合，比如addr inside {[0:255], 1024, 2048}
• dist运算符：控制概率分布，比如len dist {10 := 1, [20:30] := 5, 100 := 2}（权重控制）
• 条件约束：用if-else或->（蕴含操作符）实现动态约束

举个例子，条件约束的写法：

class Config;
    rand bit mode;  // 0: 低功耗, 1: 高性能
    rand int freq;

    constraint freq_c {
        if (mode == 0) {
            freq inside {[10:50]};  // 低功耗模式，频率低
        } else {
            freq inside {[100:500]}; // 高性能模式，频率高
        }
    }
endclass

4.5 随机化流程：从类到测试

在实际验证环境中，随机化的流程一般是这样的：

1. 定义随机类：把需要随机化的信号封装成类
2. 编写约束：用约束块限定合法范围
3. 实例化并调用randomize()：生成随机值
4. 驱动到DUT：把随机值通过接口驱动到待测设计

我习惯在测试用例里这样写：

class test_base;
    Transaction tr;
    function void run();
        tr = new();
        repeat (1000) begin
            assert(tr.randomize()) else $fatal("随机化失败");
            // 把tr里的值驱动到DUT
            driver.send(tr);
        end
    endfunction
endclass

注意这里用了assert——如果随机化失败，直接报fatal。我个人强烈建议这么做，因为随机化失败往往意味着约束写错了，早点发现比后面debug强得多。

4.6 本章知识体系

下面这张图，是我自己总结的随机化知识结构，你可以对照着复习：

好了，关于随机化的核心内容就这些。记住：rand和randc是工具，约束块是灵魂。没有约束的随机化，就像没有缰绳的野马——跑得欢，但不知道会跑到哪里去。