约束随机验证两条路：SystemVerilog constraint 与 cocotb random 写法对照

更新时间：2026-10-28。本文是「集成电路大类 · 芯片设计」中间层（intermediate）的一篇对照实验文。约束随机验证（Constrained Random Verification，CRV）的思想本身在 SystemVerilog 约束随机验证入门里已经讲过：与其手写一条条定向激励，不如声明「合法激励长什么样」，让随机源在规则内大量撒点，靠覆盖率收敛信心。问题是「声明规则」这件事有两条截然不同的工程路径：一条是 SystemVerilog 的 constraint 块，把规则交给求解器；另一条是 cocotb 里直接用 Python random 手写分布，验证工程师自己当裁判。两条路解决的是同一个需求，写法、成本、可控性却完全不同。本篇把同一个随机激励需求（给异步 FIFO 打随机读写压力）分别用两种风格写出来对照，并实跑 cocotb 一侧的完整回归——因为开源工具链（Icarus Verilog）不支持约束求解，SV 一侧给写法讲解，cocotb 一侧给真实运行结果，这个边界本篇会始终诚实标注。

本文要回答的问题

同一个「随机读写压力」需求，SV constraint 块与 cocotb random 分别怎么写？
约束求解器帮你做的、Python 里要自己写的，各是哪一部分？
没有商业仿真器和 UVM 环境时，开源栈能把约束随机做到什么程度？
cocotb 侧这次真实回归跑出了什么结果，覆盖了哪些边界？

先把两条路的全貌摆出来：

读这张对比卡抓住中缝：左右两边做的是同一件事——定义「合法随机激励的空间」再在里面撒点；区别只在「空间由谁维护」。左边 input 蓝的 SV 路线是声明式的，你只描述空间边界，采样这个空间是求解器的事；右边 execute 橙的 cocotb 路线是过程式的，空间边界藏在你的控制流里，每一拍发不发激励、发什么值，都是 Python 代码现算出来的。这个哲学差异决定了后面所有的工程取舍。

一、需求先行：我们到底要随机什么

对照之前先把需求写死，否则两边写法没法比。以异步 FIFO 的随机读写压力为例，需求拆开是四条：

发不发是随机的：写侧每拍以约 0.8 的概率发起写，读侧每拍以约 0.7 的概率发起读——不是匀速流，是有停顿的突发流；
发了必须合法：FIFO 满时不许写、空时不许读（由 DUT 的 full/empty 反压决定）；
数据是随机的：写入值在 8 位空间内均匀取；
可复现：随机序列由固定种子驱动，回归翻红时能逐拍重放。

注意这四条里没有一条提「SystemVerilog」或「Python」——约束随机验证的需求描述本来就该是语言中立的。这也解释了为什么两条路能对照：它们竞争的是同一个生态位。下面这张图把「从需求到激励」的生成流程画出来，左右两条泳道分别是两种实现：

这张图的主线是从上往下的汇合：灰色需求块往下分成两条泳道，蓝色 SV 泳道是「约束 → 求解 → 事务」三段式，绿色 cocotb 泳道是「随机源 → 合法性分支 → 拍级赋值」三段式，最后都落到橙色同一台 DUT 上。值得盯着看的差异在中间一段：SV 的合法性（不满才写、不空才读）要么由约束在生成时保证、要么由 driver 在驱动前检查；cocotb 则把合法性检查直接写进激励协程的 if 条件里——没有独立的「事务」层，激励生成和信号驱动是同一个协程。这正是过程式路线的特点：层数更少，但规则与执行缠在一起。

二、SV 侧写法：constraint 块把规则声明出来

SystemVerilog 的约束随机以「事务类」为单位。同一个需求写成 SV 大概是这样（讲解用代码，不在本次开源环境实跑——Icarus Verilog 11.0 不支持约束求解，这句边界后文还会展开）：

systemverilog

class fifo_txn;
  rand bit       do_write;   // 本拍是否发起写
  rand bit       do_read;    // 本拍是否发起读
  rand bit [7:0] wdata;      // 写入数据

  // 需求 1：发不发的概率分布
  constraint c_prob {
    do_write dist { 1 := 8, 0 := 2 };  // 80% 写
    do_read  dist { 1 := 7, 0 := 3 };  // 70% 读
  }
  // 需求 3：数据均匀分布（rand 默认即均匀，显式写出仅供阅读）
  constraint c_data { wdata inside {[8'h00:8'hFF]}; }
endclass

读这段代码注意三件事。第一，dist { 1 := 8, 0 := 2 } 这种权重分布就是需求 1 的直接翻译——你没有写「每拍掷骰子」，而是声明「do_write 取 1 的权重是 8」；怎么采出符合这个权重的序列是求解器的事。第二，inside 声明取值区间，越界值在数学上就被排除了，不存在「生成了再检查再丢弃」的浪费。第三，也是最关键的：合法性与激励正交。满不写、空不读这类时变约束没法写死在类里（它们依赖 DUT 当前状态），SV 里的标准做法是 driver 每拍先采样 full/empty，只在条件满足时才消费一个 do_write==1 的事务——或者更高级一点，用 constraint_mode 动态开关约束。无论哪种，「规则」和「驱动」在代码里是两个对象。

这种声明式风格的威力在需求变复杂时才真正显现。假设需求加一条「连续写不超过 4 拍，避免突发撑爆记分板」——SV 里加一行软约束即可：

systemverilog

  constraint c_burst { soft burst_len <= 4; }  // 软约束可被覆盖

求解器会全局协调所有约束，产出的每个事务同时满足概率分布、区间、突发上限。cocotb 里实现同一条，你得在协程里维护一个计数器、手动退避——能写，但规则越叠越多时，命令式代码的可读性会快速劣化。这就是 SystemVerilog 约束随机验证入门强调的：CRV 的核心资产是「规则库」，声明式让规则库成为一等公民。而当约束写冲突、求解失败时，排查本身也有一套方法论，见约束求解失败怎么调——那种「randomize() 返回 0」的痛苦是 cocotb 路线完全没有的。

代价也很直白：约束求解器是商业仿真器的核心卖点之一。Icarus Verilog 11.0 只支持到 SV 的很小一个子集，dist、求解器、covergroup 都不在其内；Verilator 近年才开始逐步支持 randomize 基础能力。也就是说纯开源栈走不通声明式这条路，这是本篇必须实跑 cocotb 侧的直接原因。

三、cocotb 侧写法：Python 把规则写成控制流

同一需求在 cocotb 里的实现，是本次真实运行的代码（完整源码见文末代码获取）。writer 协程长这样：

python

rng = random.Random(20261020)   # 需求 4：固定种子，回归可复现

async def writer():
    sent = 0
    while sent < n_tx:
        await FallingEdge(dut.wclk)          # 负沿采样/驱动，避开 NBA 竞争
        if int(dut.full.value) == 0 and rng.random() < 0.8:   # 需求 1+2
            v = rng.randrange(256)           # 需求 3：均匀分布
            dut.wdata.value = v
            dut.wr_en.value = 1
            written.append(v)
            sent += 1
        else:
            dut.wr_en.value = 0

与上一节的 SV 代码逐条对照，能看到过程式路线把同样的四条需求翻译成了什么：

需求	SV constraint（声明式）	cocotb random（过程式）
发不发 0.8/0.7	`dist {1:=8, 0:=2}` 权重声明	`rng.random() < 0.8` 每拍现掷
满不写/空不读	driver 采样标志后才消费事务	`if full==0 and ...` 写进激励协程
数据均匀	`rand bit [7:0]` 默认均匀	`rng.randrange(256)`
可复现	`+ntb_random_seed` 命令行种子	`random.Random(20261020)` 显式种子源
记分板	scoreboard 组件/UVM analysis port	Python 两个 list 末尾一句 assert

这张表最右边一列的共性是「全部显式」：概率是显式的比较运算，合法性是显式的 if，种子是显式的对象。好处是没有黑盒——激励怎么来的，读代码一眼到底，调试时不用理解求解器行为；坏处是规则多了之后缠在控制流里，改一条约束要动协程逻辑，且这套代码无法被覆盖率工具反向利用（SV 的 covergroup 能直接对 constraint 采样统计命中，cocotb 侧覆盖率要自己记账）。

rng = random.Random(20261020) 这一行值得单独说。cocotb 本身每次运行也会播一个全局种子（本次日志里是 Seeding Python random module with 1793122009），但测试代码里自建一个固定种子的 Random 实例，意味着激励序列与全局种子解耦——重跑同一仓库同一命令，200 笔激励逐拍一致。可复现性在两条路线里都是回归的保命绳，只是 SV 靠命令行传种子、cocotb 靠代码里写种子源。

四、实测：cocotb 侧随机回归全绿

铺垫到此为止，下面是 cocotb 侧在 async-fifo 上的真实回归结果。被测 DUT 是 8 位宽、16 深度的异步 FIFO（格雷码指针 + 两级同步，结构原理见异步 FIFO 的 cocotb 验证实测），回归含两条用例：single_write_read 冒烟与 random_back_to_back 随机压力——后者就是本文第三节那段 writer/reader 协程，写侧 0.8 概率、读侧 0.7 概率、200 笔 token 背靠背穿越 6 ns / 9 ns 两个异步时钟域。

这段实录自上而下读三层：开头两行版本行确认运行环境是 Icarus Verilog 11.0 加 cocotb 1.8.1；随后 Seeding Python random module with 1793122009 是框架级种子，而本文的激励由代码里独立的固定种子源驱动，两层互不干扰；中间 200 tokens delivered in order across async clocks OK 是 Python 断言通过后打的一句话——200 笔数据在两个异步时钟域之间搬运，顺序与内容逐笔全等；最下面的汇总表 TESTS=2 PASS=2 FAIL=0 SKIP=0 给出最终判定，随机用例仿真 2623.50 ns、真实耗时 0.10 秒。

把关键的用例执行链原样摘录一段：

exp-log

0.00ns INFO     cocotb.regression                  Found test test_async_fifo.single_write_read
0.00ns INFO     cocotb.regression                  Found test test_async_fifo.random_back_to_back
0.00ns INFO     cocotb.regression                  running single_write_read (1/2)
99.00ns INFO     cocotb.regression                  single_write_read passed
99.00ns INFO     cocotb.regression                  running random_back_to_back (2/2)
2722.50ns INFO     cocotb.async_fifo                  200 tokens delivered in order across async clocks OK
2722.50ns INFO     cocotb.regression                  random_back_to_back passed
** TESTS=2 PASS=2 FAIL=0 SKIP=0                      2722.50           0.18      15448.91  **

这次回归对「约束随机」这个主题证明了什么？写比读快（0.8 对 0.7）意味着 FIFO 会被逐渐填满、full 反压反复生效；读侧随机停顿又让 FIFO 反复回到接近空——空满两个边界在一次回归里被随机流量反复穿越，这正是定向序列难以系统性覆盖的工况。200 笔零丢失零乱序，说明过程式随机在这个规模上完全够用：激励质量不输，成本是零（Icarus 开源），耗时 0.18 秒。

五、怎么选：边界说清楚

两条路不是替代关系，按团队栈和验证规模选：

选 SV constraint：有商业仿真器、验证环境基于 UVM（见 UVM 组件与 phase 机制）、规则复杂到需要声明式管理（几十上百条约束互相作用）、需要 covergroup 做覆盖率闭环。规则库资产化的团队没有第二条路。
选 cocotb random：开源栈或个人项目、DUT 规模中小、激励规则用几页 Python 写得清、团队 Python 比 SV 熟。本实验证明它在 FIFO 级 DUT 上能做到严肃的可复现随机回归。
诚实的能力缺口：cocotb 路线缺三样东西——约束求解（复杂约束组合靠手写枚举不现实）、功能覆盖率原生支持（要自行统计或借助第三方）、事务层抽象（激励与驱动缠在协程里）。这些缺口在 SoC 级验证里是致命的，在模块级验证里大多可以忍。

本次实验自身的边界也要交代：SV 侧的 constraint 代码是写法讲解，未在开源环境实跑（Icarus 不支持求解器，前文已述）；cocotb 侧回归覆盖的是功能正确性（数据完整性、空满反压），不覆盖亚稳态这类仿真器不可见的物理效应，也不做拍级时序契约的断言检查。

这一篇在知识体系里的位置

方法论前导：SystemVerilog 约束随机验证入门（CRV 思想与 covergroup 闭环）与约束求解失败怎么调（声明式路线特有的排错面）；
同 DUT 深文：异步 FIFO 的 cocotb 验证实测（本文复用其 RTL 与测试骨架，那篇讲 FIFO 验证本身，本文讲随机激励的两条实现路线）；
横向同类：AXI-Lite 从机的 cocotb 自检回归（总线协议侧的 cocotb 写法）；
环境框架：UVM 组件与 phase 机制（声明式路线所依托的商业验证环境骨架）。

一句话总结

约束随机验证的需求是语言中立的——发不发随机、发了必须合法、数据均匀、序列可复现。SystemVerilog 用 constraint 块把规则声明给求解器，适合规则库资产化的商业验证环境；cocotb 用 Python random 把规则写进协程控制流，开源栈零成本可跑。本篇在 async-fifo 上实跑 cocotb 侧回归：固定种子驱动 200 笔随机背靠背读写穿越 6/9 ns 异步时钟，空满边界被随机流量反复穿越，TESTS=2 PASS=2；SV 侧因开源工具链不支持约束求解，只做写法对照，边界如实标注。

实验环境

机器/系统：云主机 16C32G / Ubuntu 22.04（eda-golden-v1 镜像）
工具版本：cocotb 1.8.1 + Icarus Verilog version 11.0 (stable)（版本行照抄日志：Running on Icarus Verilog version 11.0、Running tests with cocotb v1.8.1）
日期：2026-10-28
完整命令：

cd labs/async-fifo
PATH=/opt/eda-venv/bin:$PATH PYTHONPATH=testbench \
  make -f $(/opt/eda-venv/bin/cocotb-config --makefiles)/Makefile.sim \
  SIM=icarus WAVES=1 TOPLEVEL_LANG=verilog \
  VERILOG_SOURCES=rtl/async_fifo.v TOPLEVEL=async_fifo \
  MODULE=test_async_fifo COMPILE_ARGS=-g2012

代码获取

完整 RTL、cocotb 测试与 Makefile 已同步到公开仓库：geek-doc.cn/experiments/sv-constraint-random-vs-cocotb，克隆后进入该目录执行 make run（需 iverilog 与装好 cocotb 的 Python 环境，Makefile 默认假设 cocotb 在 /opt/eda-venv，本地按实际 venv 路径调整）即可复现本文全部结果。

入门

进阶

专家

约束随机验证两条路：SystemVerilog constraint 与 cocotb random 写法对照 ​

本文要回答的问题 ​

一、需求先行：我们到底要随机什么 ​

二、SV 侧写法：constraint 块把规则声明出来 ​

三、cocotb 侧写法：Python 把规则写成控制流 ​

四、实测：cocotb 侧随机回归全绿 ​

五、怎么选：边界说清楚 ​

这一篇在知识体系里的位置 ​

一句话总结 ​

实验环境 ​

代码获取 ​