SystemVerilog加法器测试平台入门：从裸写TB到覆盖率与断言

1. 项目由来加法器测试平台是验证入门的“最短闭合链路”看到91.【SV】SystemVerilog Testbench Example Adder这个标题我第一反应是这又是一套SystemVerilog学习笔记里的经典章节拿加法器当测试平台Testbench的练手对象。这类例子在验证工程师圈子里叫Hello World中的Hello World但你别因为它简单就跳过。加法器是所有数字电路里功能最透明的模块输入两个数、一个进位输出和与进位任何人在三秒内能心算出正确结果。恰恰因为正确期望值太好写了它才成为学习SystemVerilog测试平台的绝佳载体。很多人第一次写SV测试平台上来就想搞复杂的DUT比如带AXI接口的DMA控制器。结果90%的时间花在理解被测设计上测试平台本身的语法反而没练到最后写出来的TB质量也不高。加法器把DUT的理解成本几乎降为零让你能把全部脑力留给SystemVerilog这套语言机制logic类型、任务封装、随机化、interface、断言、功能覆盖率一个不少全都能在这个mini例子里实际跑一遍。这篇文章要做的事很明确从一个参数化加法器DUT出发带着你写一版能自动比对结果的SystemVerilog测试平台然后逐步加上随机激励、interface、覆盖率收集和断言检查最后聊实操中会踩到的坑。适合三类人正在自学SV的学生、想从FPGA逻辑设计转向验证的工程师、以及需要给团队准备入门培训材料的人。你不需要提前懂UVM只需要有基本的Verilog基础。2. 动手前先把验证思路理顺加法器到底要测什么2.1 先写三行设计规格再动键盘我见过太多人拿到一个模块就开写TB信号连完随便跑几个用例就说仿真通过。这种验证其实是在骗自己。写测试平台的第一步永远是把被测设计的行为规格写下来哪怕只有三行。对加法器来说功能规格sum是a、b、cin三者的算术和取低WIDTH位cout是和的最高位进位。接口规格a、b为WIDTH位输入cin为单bit进位输入sum为WIDTH位输出cout为单bit进位输出。时序规格纯组合逻辑输出随输入变化立即更新无时钟。这三行写完之后你对测什么就有了清单。功能上要覆盖无进位加、有进位加、产生进位输出、最大数相加、最小数相加边界上要覆盖全0、全1、中间值、0x80这类对称点。这个清单就是你后面写定向用例、定随机约束、配覆盖率bin的出发点。2.2 测试平台的四件套最小骨架不管多简单的TB结构上都应该分成四块加法器也不例外激励生成决定下一拍给DUT喂什么数据。驱动把数据按时序打到DUT的端口上。监测采样DUT的输入输出。比对把采样结果和期望值比较记录错误。用一个生活化的类比来说被测设计是一个答题的学生测试平台就是考官。考官得先出题激励把卷子发给学生驱动等学生交卷后批改监测最后对答案、算分比对。很多初学者写TB时容易把这几件事全揉在一个initial块里出一个值立刻自己比对。小例子没问题但一旦DUT有流水线、有延迟输出这种写法立刻乱套。所以从加法器开始养成分职责的习惯后面很省事。2.3 这个例子该不该直接上UVM绕不开的问题是既然SystemVerilog最终都要走向UVM加法器测试平台为什么不直接按UVM的agent、driver、sequence那套来搭我的观点是第一遍学SV加法器就该用裸写TB练。UVM本质上是在SV上搭的一套框架它解决的是组件复用、环境可配置、回归管理而不是基本的信号驱动和比对。如果你连class、randomize、covergroup这些原生语法都没用过直接看UVM源码会非常吃力因为UVM类库里到处是参数化类、回调、工厂机制全是建立在SV语法之上的。加法器这种十几行代码的DUT用UVM就像开着卡车去楼下便利店买瓶水——能用但没必要。先用裸写TB把SV的语法点吃透等DUT复杂度上来、需要复用环境时再迁移到UVM那时候你会发现UVM的每一步设计都是有道理的。3. 代码拆解能自动比对结果的SV测试平台是怎么长出来的3.1 DUT三行代码的参数化加法器为了后面验证方便DUT写成参数化形式module adder #( parameter WIDTH 8 ) ( input logic [WIDTH-1:0] a, input logic [WIDTH-1:0] b, input logic cin, output logic [WIDTH-1:0] sum, output logic cout ); assign {cout, sum} a b cin; endmodule这里有两个细节值得讲。第一为什么用logic而不是Verilog的wire/regSV把两种类型统一成logic它既能被连续赋值驱动也能在过程块里赋值写TB时不用再纠结这里该用reg还是wire少一批低级编译错误。第二{cout, sum}这个拼接的位宽非常关键a b cin是WIDTH位的a加WIDTH位的b再加1位的cin结果最宽是WIDTH1位而拼接体正好也是WIDTH1位所以这个赋值不仅把低WIDTH位的和放进sum还把进位放进了cout。如果输入端位宽改大拼接会自动适配这就是参数化的价值——改WIDTH就能生成不同位宽的加法器而TB不需要跟着改端口验证代码的复用性就是这么来的。3.2 第一版TB定向激励、随机激励、自动比对先看完整的裸写测试平台再逐段解释timescale 1ns/1ps module tb_adder_basic; localparam WIDTH 8; logic [WIDTH-1:0] a; logic [WIDTH-1:0] b; logic cin; logic [WIDTH-1:0] sum; logic cout; // 期望值注意位宽是WIDTH1用来同时容纳sum和cout logic [WIDTH:0] expect; int error_cnt; // DUT例化 adder #(.WIDTH(WIDTH)) dut ( .a (a), .b (b), .cin (cin), .sum (sum), .cout(cout) ); // 自动比对任务 task automatic check_output(); expect a b cin; if ({cout, sum} ! expect) begin error_cnt; $error(Mismatch: a%02h b%02h cin%b got {cout,sum}{%b,%02h}, expect%03h, a, b, cin, cout, sum, expect); end endtask // 主激励 initial begin error_cnt 0; // 阶段一定向用例覆盖边界 a 8h00; b 8h00; cin 1b0; #10; check_output(); a 8h01; b 8hFE; cin 1b0; #10; check_output(); a 8hFF; b 8hFF; cin 1b0; #10; check_output(); a 8hFF; b 8hFF; cin 1b1; #10; check_output(); a 8h80; b 8h80; cin 1b1; #10; check_output(); // 阶段二随机激励大量撒网 repeat (1000) begin a $urandom; b $urandom; cin $urandom 1b1; #10; check_output(); end // 阶段三汇总报告 if (error_cnt 0) $display(TEST PASSED); else $display(TEST FAILED, total errors %0d, error_cnt); $finish; end endmodule有几个点必须搞清楚否则抄过去也不知道自己写的什么。先说期望值比较。我用WIDTH1位的expect a b cin然后拿{cout, sum}去和它比。这里有个细节如果直接把sum和abcin的低8位比你根本测不出进位输出cout有没有接错——比如DUT把cout恒接0sum只要没错你照样会报TEST PASSED。把sum和cout拼成一个整体来比较就能同时校验两个输出这才是加法器完整的功能检查。再说task automatic。task不加automatic里面的变量默认是静态的如果多个地方同时调用这个任务局部变量会互相覆盖。初学者写的TB大多只有一个initial块串行跑加不加看不出来但如果后面用fork...join并发驱动或者把任务封装到class里被多个线程调用不加automatic就会出一堆莫名其妙的问题。从第一版就养成习惯把可重入的任务全声明成automatic。然后是#10这个延时。它有两个作用一是给组合逻辑留出传播时间二是在输入变化和采样检查之间制造一个时间窗口。对纯组合的assign加法器理论上传播延迟是0但你仿真时依然要等一拍再检查因为模拟器的事件调度需要时间让输出更新。至于为什么是10ns而不是1ns其实只要大于0且够仿真器完成一轮事件更新就行10ns是我个人的习惯留的裕量比较大后面改成带锁存器的时序加法器时这个间隔也够用。最后是随机源的选择。$urandom返回无符号32位随机数$random返回有符号32位随机数。对8位加法器用$urandom直接赋值给a和b是安全的但如果用$random参与表达式计算因为可能返回负数存在符号扩展的坑。下面第4节我会专门讲这个坑。这里cin $urandom 1b1是把随机数的最低位拿出来当进位输入简单可靠。3.3 用interface把TB和DUT之间的连线管起来上面的TB里a、b、cin、sum、cout这五个信号是散着声明、散着连的。如果端口一多比如后面换成带握手协议的总线三四十根信号连接就会变成一场灾难。interface就是SV用来打包信号的机制。先定义一个加法器总线接口并用modport区分方向和身份interface adder_bus #( parameter WIDTH 8 ) (); logic [WIDTH-1:0] a; logic [WIDTH-1:0] b; logic cin; logic [WIDTH-1:0] sum; logic cout; modport TB (output a, b, cin, input sum, cout); modport DUT (input a, b, cin, output sum, cout); endinterfacemodport的作用是从某个视角声明方向从TB视角看a、b、cin是输出sum、cout是输入从DUT视角看刚好反过来。这防止了TB和DUT误接方向是一个免费的接线安全检查。DUT侧改造为使用接口端口module adder_intf #( parameter WIDTH 8 ) ( adder_bus.DUT bus ); assign {bus.cout, bus.sum} bus.a bus.b bus.cin; endmoduleTB侧可以完全通过接口实例来驱动和采样module tb_adder_if; localparam WIDTH 8; adder_bus #(.WIDTH(WIDTH)) bus(); adder_intf #(.WIDTH(WIDTH)) dut (.bus(bus)); logic [WIDTH:0] expect; int error_cnt; task automatic check_output(); expect bus.a bus.b bus.cin; if ({bus.cout, bus.sum} ! expect) begin error_cnt; $error(Mismatch: a%02h b%02h cin%b got {cout,sum}{%b,%02h}, expect%03h, bus.a, bus.b, bus.cin, bus.cout, bus.sum, expect); end endtask initial begin error_cnt 0; bus.a 0; bus.b 0; bus.cin 0; #10; check_output(); bus.a 8hFF; bus.b 8hFF; bus.cin 1b1; #10; check_output(); repeat (1000) begin bus.a $urandom; bus.b $urandom; bus.cin $urandom 1b1; #10; check_output(); end if (error_cnt 0) $display(TEST PASSED); else $display(TEST FAILED, total errors %0d, error_cnt); $finish; end endmodule这里要说实话对一个5个端口的加法器interface带来的收益不大甚至看着更啰嗦。但你要理解它的价值在扩展以后DUT改成带握手总线或AXI接口接口里的信号会越来越多modport可以区分驱动侧和监测侧的可见性TB里所有组件共享同一个interface实例不会再出现几十根信号线散落各处、改动端口就要改所有引用的情况。从加法器开始熟悉interface成本最低。3.4 让激励想学起来随机类、随机约束与边界定向前面这版TB用的是直接赋值给接口的随机方式够用但不够SystemVerilog。既然学了class就把激励封装成事务对象顺便体验约束求解器。class AdderTxn; rand logic [7:0] a; rand logic [7:0] b; rand bit cin; // 权重约束边界值各占1份中间值占6份 constraint c_a_dist { a dist { 0 : 1, 8hFF : 1, [1:254] : 6 }; } constraint c_b_dist { b dist { 0 : 1, 8hFF : 1, [1:254] : 6 }; } // 打印函数 function void print(); $display(txn: a%02h b%02h cin%b, a, b, cin); endfunction endclass使用方式AdderTxn txn new(); repeat (2000) begin // randomize()返回1表示约束求解成功0表示失败约束无解/冲突 if (!txn.randomize()) begin $error(randomize failed); break; end bus.a txn.a; bus.b txn.b; bus.cin txn.cin; #10; check_output(); end为什么用dist而不是简单inside如果你写a inside {0, 8hFF}那a只会取这两个边界值随机性没了如果写a inside {0, 8hFF, [1:254]}求解器在解空间里均匀选点边界值被中间范围稀释得概率极低中间范围有254个值边界只有2个边界覆盖率很难凑满。dist语法让你显式指定权重边界各1份中间范围6份。结果是中间值大约75%概率被取到边界值各12.5%左右既能快速铺开普通场景又能反复锤边界覆盖率一下子就好看了。这里有个初学者必踩的坑randomize()是有返回值的必须检查。如果约束写成了无解比如两个rand变量被约束成永远无法同时满足的值randomize()会返回0而你如果不检查程序会继续往下跑用的还是上一次的旧值最可怕的是它不会报任何错误你最后看到的是仿真通过实际上激励根本没生效。我的习惯是每次randomize()都用assert包裹assert(txn.randomize())让失败自动触发断言错误。3.5 覆盖率不是有covergroup就叫做了覆盖率功能覆盖率是验证工程的核心指标之一但在加法器这种例子里很多人的covergroup写得很敷衍。点开覆盖率报告a、b各一个coverpoint每个coverpoint底下自动分256个bin跑1000个随机用例一看表格全是满的然后宣布覆盖率100%。这种覆盖率对验证没有任何指导意义因为它只告诉你所有值都出现过而这靠均匀随机就能做到。真正的覆盖目标是验证计划定义的场景都发生了。对加法器边界和进位场景才是重点covergroup AdderCg (posedge clk); cp_a: coverpoint a { bins low_edge {0}; bins high_edge {8hFF}; bins mid {[1:254]}; } cp_b: coverpoint b { bins low_edge {0}; bins high_edge {8hFF}; bins mid {[1:254]}; } cp_cin: coverpoint cin; cp_cout: coverpoint cout; endgroup这样每个coverpoint只有3个bin或2个bin跑完随机激励后查覆盖率如果low_edge那行一直是0说明随机约束里边界值权重太低你还得专门加定向用例。这比看256个bin满不满有用得多。cross的坑也顺便说一下。如果你直接写cross a, b在8位加法器上会产生65536个交叉bin仿真器光建这些bin就要吃掉大量内存。正确做法是让cross建立在缩小过的bin上cross cp_a, cp_b只有9个bin含义是两个输入的边界组合是否都覆盖到了比如a0且b255这种边角组合正是加法器最需要验证的场景。覆盖率收集还有一个时机问题。covergroup声明得比较早等所有激励跑完再调用$get_coverage()拿结果。如果你的covergroup配置了(posedge clk)采样事件而前面那版TB里没有时钟编译就会报错。加法器本身不需要时钟但为了演示覆盖率采样也为了后面扩展成流水线版本我给这版TB补一个纯仿真的时钟logic clk; initial clk 1b0; always #5 clk ~clk;如果你不想引入时钟直接把采样事件改成(a or b or cin or sum or cout)也能跑但我个人不建议用信号变化做采样事件组合逻辑的中间毛刺会污染覆盖率数据统计出一堆本来想避开的过渡值数字虚高。时钟沿采样反而最干净因为驱动端在时钟沿之后才更新数据采样拿到的都是稳定值。3.6 断言组合逻辑上加断言时机比你想的敏感断言是SV里最容易被忽视的验证手段。对加法器这种纯组合模块很多人觉得反正有TB比对还写什么断言。但你仔细想想TB的检查是在固定的点做的只检查那一瞬间是否匹配断言则可以在任何时候监测将来这个加法器如果被包进一个大系统里别的模块对它的输入随时在变断言能全天候盯场。给加法器加断言第一反应是并发断言property p_adder_result; (posedge clk) {cout, sum} $past(a b cin); endproperty a_p_adder: assert property (p_adder_result);这段代码看着对跑起来大概率误报。原因在于时序方向posedge clk采样的时刻如果输入端恰好也在时钟沿附近变化采样到的输入可能是旧值而组合输出可能已经更新到新状态比出来的结果就错了。而且组合逻辑没有时钟输出什么时候稳定完全取决于输入什么时候变化并发断言的采样窗口很难卡准。更稳的做法是用立即断言放在DUT例化之后、用always_comb触发always_comb begin expect a b cin; chk_adder: assert ({cout, sum} expect) else $error(assertion failed at time %0t: a%h b%h cin%b, $time, a, b, cin); end这段写在TB里每次输入变化时SV都会重新求值。要注意一个细节如果DUT不是0延时的assign而是有内部延迟的单元组合逻辑在过渡期间会出现瞬间的不匹配这种断言会误报。解决办法是把assert放到输出稳定之后比如输入变化后固定延时#5再断言或者干脆放弃这个写法改在check任务里做比对。断言写不写、怎么写取决于DUT的实际时序这是你在真实项目中必须学会的权衡。4. 实操记录编译、运行、看波形以及真实踩过的坑4.1 跑起来需要的命令和流程这里不写具体工具名了不管用哪个仿真工具流程都差不多把DUT和TB两个文件加入工程开SystemVerilog模式对应命令行选项一般是-sv指定顶层模块编译然后运行仿真可执行文件。以开源工具链的常见用法为例示意命令长这样# 编译两个源文件顶层是tb_adder_basic输出仿真可执行文件 sim_compile -sv tb_adder_basic.sv adder.sv -s tb_adder_basic # 运行输出到终端同时导出VCD波形 sim_run vcd -o wave.vcd你用的仿真器具体选项查看各自手册但整体流程逃不出这三步编译、运行、看报告。跑完终端里应该能看到TEST PASSED如果故意在DUT里埋一个bug比如把cout连着恒为0你会看到Error: Mismatch: aff bff cin1 got {cout,sum}{0,fe}, expect1ff TEST FAILED, total errors 1看到这种输出就说明你的TB真正在起作用了——它有能力发现DUT的错误。很多新手搭的验证环境验证了半天从来没测出过bug那十有八九是检查逻辑自身有漏洞。波形查看方面跑仿真时把VCD或fsdb类型的文件导出在波形工具里把a、b、cin、sum、cout拖出来重点观察进位场景输入从aff, bff, cin1切换到下一组数据时cout和sum是否同步变化。组合逻辑的波形通常是一条竖线直接跳变如果你看到毛刺或中间态先怀疑事件调度的顺序再怀疑DUT里是不是混进了时序逻辑。4.2 最常见的三个坑位宽、随机源、断言时机这一节说的都是我实际踩过、也看别人反复踩的问题列成一张表给你自查现象根因解决办法仿真显示TEST PASSED但波形里cout一直是0检查逻辑把sum和cout分开比较或者只比了sum拼成{cout,sum}整体比对随机激励下偶尔报Mismatch重跑又消失$random返回负数参与表达式时有符号扩展统一用$urandom或者先赋给int再截位并发断言大量误报组合逻辑输出在时钟沿附近采样新旧值混叠改用立即断言或让并发断言延迟一拍采样三个坑逐个展开。位宽那个坑最隐蔽你把DUT的座改成assign sum a b cin; assign cout 0;TB如果只比较sum所有sum都对于是报了TEST PASSED。这不是TB在验证这是TB在陪DUT演戏。所以3.2里我特意强调把两个输出拼成一个期望值比这是加法器TB最重要的一个设计决策。随机源的坑在于$random虽然叫随机但返回的是32位有符号数能产生负数。如果你写a $random;而a是logic [7:0]负数的低8位会被截出来赋给a看起来也是随机值没什么问题但如果你用$random参与表达式计算比如expect a b cin;由于$random在表达式里是32位有符号整个表达式会被提升成有符号计算结果可能和预期符号不同。低8位看不出差别换成16位加法器、或者中间结果涉及符号扩展时就等着抓狂吧。结论新代码一律用$urandom和$urandom_range$random只在你明确想要有符号随机整数时才用。断言时机那个坑3.6已经提过。这里补充一个判断标准只要你的DUT里没有自己带时钟就用驱动后固定延时再做立即断言的套路如果DUT是时序逻辑才适合在时钟沿上做并发断言因为那时输入输出关系稳定。4.3 用故障注入检验你的TB是否可信这个方法我在带人的时候一定会教写完好端端的TB别急着下班先在DUT里故意植入一个bug看TB能不能抓出来。对加法器依次植入把进位输出恒接0。把sum的某一位强制取反。把a和b的加法改成减法。每次植入一个重跑一遍如果TB每次都报Mismatch、错误计数大于0说明TB的检查逻辑是灵敏的。做完之后把bug改回去再跑一遍确认TEST PASSED。这个过程只需要十分钟但能让你的测试平台可信度翻倍。为什么很多真实项目里的测试平台形同虚设就是因为没人做过这种自我体检最后测试平台和DUT共享同一个错误假设bug被两边同时掩盖。这种对的环境验出对的假结果在验证里是最要命的。5. 从加法器到真实项目这个小TB还能怎么长5.1 加时钟、加流水线TB怎么跟着变把加法器改造成带一级寄存器的流水线加法器在输出加一拍FFTB的改动很小驱动输入后等一拍再检查比对逻辑不变。真正的变化在于你要引入时钟生成并把驱动改成对齐时钟沿。如果改成两级流水线检查时就要等两拍。这时候你发现TB里驱动后#10再检查这种固定延时不再可靠了需要用等N个时钟沿的概念。这就是为什么真实TB里会有专门的时钟生成块和同步逻辑也从侧面说明SV的clocking block在时序对齐上的价值。建议你实际改一版试试在always #5 clk ~clk的时钟下把驱动改成(negedge clk)把检查放到(posedge clk)之后这样采样窗口天然对齐。5.2 事务级建模和UVM的入口你写的AdderTxn这个类其实就是UVM里uvm_sequence_item的雏形你写的check_output任务其实就是uvm_scoreboard里run_phase的缩小版你的$urandom随机驱动就是uvm_sequencer加uvm_driver在干的事。所以这个加法器例子虽然简单但你已经把UVM的核心概念都摸了个边。将来要迁移到UVM要做的事是把生成激励的部分从initial块挪到sequence里把驱动动作封装成driver的run_phase逻辑把比对逻辑放进scoreboard再用agent把这几个组件包起来。换个角度看UVM只是把你在加法器里手写的这些代码组织成了标准组件和标准时序。带着这个认知去看UVM源码你会发现每个类都不陌生。5.3 一点个人习惯和收尾经验回到开头那句话加法器测试平台是验证的最短闭合链路一个DUT、一个TB、一次编译运行、一份报告从零到通过不超过半小时但它覆盖了验证最核心的思考方式——确定规格、拆解测试点、搭建检查逻辑、收集覆盖率、反馈约束。我每次带新人不管将来做CPU验证还是做总线验证第一周都是让他把这个加法器TB亲手写一遍再自己植入几个bug抓一遍。这一遍走下来比看十篇教程都管用。如果你正在学SystemVerilog建议把这个例子里的每一段代码都亲手敲一遍不要复制粘贴。敲的过程里你会碰到上面说的那些细节问题——位宽、任务声明、断言写法——这些坑只有自己踩过一遍才会变成真经验。等这个例子跑通了再试试给它加上减法功能、改成16位或者换成带使能端口的版本你会发现自己已经能独立扩展测试平台了。