说实话能一路写到第九篇学习笔记的人已经不算是SystemVerilog的新手了。前几篇我们聊完了数据类型、接口、类、随机化约束、线程之间的通信基础的验证环境搭建也跑通过几个小例子。但从“会写验证代码”到“能证明设计是对的”中间其实还隔着两道大槛一个是覆盖率另一个是断言。这篇笔记我就把这两个东西放在一起讲。为什么放一起因为它们在验证流程里本来就是配套出现的——断言负责告诉你“错在哪”覆盖率负责告诉你“测够了没”。没有断言你的仿真挂了可能还要排查半天没有覆盖率你可能测了一整天都觉得虚根本不知道哪些分支从来没走到过。这篇内容适合已经能独立搭建UVM或简易验证环境、想进一步把验证做扎实的朋友。我尽量用直白的语言讲清楚原理再给一个能直接跑起来的完整小例子。1. 为什么学完基础后必须啃下覆盖率和断言1.1 覆盖率模型的本质给验证工作装上“仪表盘”你可以把功能覆盖率想象成开车时的仪表盘。你踩油门、打方向盘车到底跑了多远、还剩多少油仪表盘会告诉你。验证工作也是一样你写了激励、跑了仿真但你不能只盯着“仿真有没有报错”这一项指标。testbench跑完、没有报错只能说明现有激励没有触发致命问题这离“验证完备”还差得很远。SystemVerilog里的功能覆盖率Functional Coverage就是一种给验证过程安装仪表盘的手段。它通过covergroup、coverpoint、cross这些关键词把你关心的信号取值、信号组合、状态跳转等情况统计出来。仿真跑完后覆盖率报告会明确告诉你哪些信号取值被覆盖到了哪些没有被覆盖到哪些信号之间的交叉组合被覆盖到了哪些从来没发生过哪些状态机的状态跳转从来没进入过有了这些数据你就能针对性地补测试用例或调约束而不是盲目地加大仿真时间。我个人的经验是覆盖率收集不一定要等到环境全部搭好才做。从第一版testbench能跑通开始就把全局覆盖率开着哪怕只统计几个关键信号也能帮你尽早发现问题信号。等到UVM环境完整了之后再慢慢把covergroup补充完整也不迟。1.2 SVA断言在验证中的定位实时“裁判员”而不是事后“纪检委”断言SVASystemVerilog Assertion和覆盖率解决的问题完全不同。覆盖率回答的是“测到了吗”断言回答的是“设计行为对不对”。在实际验证里很多bug是时序性的。比如一个握手信号拉高之后必须在指定周期内被应答否则就视为超时又比如一个FIFO写使能和满信号绝对不能同时为高。这类bug如果你想通过检查最终输出来发现通常要花费大量时间追波形而且很可能被中间信号的变化掩盖掉。SVA的定位就是在仿真过程中实时监控这些信号的时序关系违反协议的那一刻立刻报错并且打印出具体的时间戳和信号值。我经常把断言比作球场上的裁判员。设计在被测的时候裁判员一直在场上盯着任何犯规动作都逃不过他的眼睛。相比之下只在仿真结束后检查打印日志的方式就像赛后看录像回放能发现问题但效率低太多了。更关键的是SVA不止能用断言assert来报错还能用覆盖cover来记录某个时序是否发生这本身就是功能覆盖率的一种补充。因此成熟验证环境里SVA和覆盖率从来不分家。2. SystemVerilog功能覆盖率的核心机制2.1 covergroup的编排思路把验证目标翻译成机器能统计的语言covergroup是SystemVerilog中收集功能覆盖率的容器。你需要把“我想验证什么”翻译成covergroup里具体的coverpoint覆盖点和cross交叉覆盖。举个例子假设你要验证一个AXI-Lite从机的写通道你关心两个信号写地址AWADDR的高两位取值以及写有效AWVALID的跳变情况。那么你的验证目标就变成两类coverpointAWADDR[1:0]的取值四种情况00、01、10、11是否都发生过AWVALID从0到1、从1到0的跳变是否都发生过这两个信号之间的交叉组合情况代码上很简单先定义covergroup类型再在需要的位置实例化covergroup cg_axi_lite_write (posedge clk); awaddr_cp : coverpoint awaddr[1:0]; awvalid_cp : coverpoint awvalid; awaddr_x_awvalid : cross awaddr_cp, awvalid_cp; endgroup cg_axi_lite_write cg_inst new();这里有个很重要的可选参数——采样事件。上面的写法用了(posedge clk)也就是每个时钟上升沿采样一次。但实际验证中你可能更希望在特定事件发生时采样比如读写事务完成时。那就可以把采样事件改成covergroup cg_axi_lite_write (event ev_sample); ... endgroup然后在你认为合适的时刻通过-ev_sample来触发采样。这种按事件采样的方式比单纯按时钟采样更精准能显著减少无效数据量我强烈建议你在实际项目里用起来。covergroup可以定义在module里、interface里也可以定义在class里。在class里用的最多尤其是在UVM环境中通常把covergroup定义在monitor或scoreboard的类中。但要注意一点如果你在class里定义了covergroup实例化时必须调用new()函数而且covergroup的采样对象必须是class里能访问到的信号或者是通过new函数的参数传进去的虚接口。这个细节新手经常栽跟头编译报错说找不到信号其实不是信号不存在而是covergroup的采样作用域没写对。2.2 仓bin的进阶写法自动分箱和自定义分箱coverpoint的取值域默认会被自动分成bin。比如一个4比特信号默认会分成16个bin每个bin对应一个值。这种自动分箱可以快速上手但真实场景中通常需要手动指定bin不然覆盖率报告会非常碎而且有些组合你觉得不重要也会被当成未覆盖项列出来。手动指定bin有两种常见写法。第一种是直接列出关心的值coverpoint cmd { bins cmd_read {READ}; bins cmd_write {WRITE}; bins cmd_idle {IDLE}; }第二种是用数组或范围来生成bincoverpoint addr { bins low {[0:15]}; bins mid {[16:31]}; bins high {[32:47]}; bins rest default; }这里我要多说一句default这个特殊的bin。它会捕获所有没有明确列出来的取值通常用来保证覆盖率统计的完备性。但同时default bin在报告里一般不计入“未覆盖”的统计因此能有效避免一些无关取值把覆盖率数字拉低。不过使用default也要心里有数——如果default占比特别高说明你的bin划分策略可能没覆盖到设计的主要工作模式需要回头审视一下验证计划。还有一种常见需求是忽略某些取值。比如一个信号只有复位后才会出现某些特殊值而你不关心复位阶段的状态那就可以用ignore_bins来过滤掉coverpoint mode { ignore_bins reset_mode {MODE_RESET}; }ignore_bins和default的区别在于ignore_bins是完全从覆盖率统计中排除这些取值连“未被覆盖”的状态都不算default则是不让它把覆盖率拉低。两者本质不同用的时候要注意区分场景。很多时候项目里为了拉高覆盖率数据好看滥用ignore_bins把关键场景都滤掉了——这其实是在自欺欺人验证的初衷是发现bug不是刷一个漂亮的百分比数字。2.3 交叉覆盖率发现组合爆炸里的隐藏盲区交叉覆盖率cross是用来统计多个覆盖点之间组合情况的工具。它解决的核心痛点是单个覆盖点各自都覆盖到了但它们的组合可能从来没发生过。继续用AXI的例子。假设你分别收集了AWLEN突发长度和AWSIZE传输大小的覆盖点单独看两个覆盖点都达到100%覆盖但AWLEN8且AWSIZE4即8拍传输且每拍4字节共32字节这个组合可能一次都没发生。如果不做交叉覆盖这个问题完全不会被发现而组合恰恰是很多功能bug的高发区。交叉覆盖的写法很简单cross awlen_cp, awsize_cp;但有个重要细节如果你不想统计所有组合而是只关心某些特定组合可以用binsof和intersect来过滤cross awlen_cp, awsize_cp { ignore_bins unexpected binsof(awlen_cp) !binsof(awsize_cp) intersect {1, 2, 4}; }这段代码的含义是当awlen_cp的任意取值与awsize_cp的取值1、2、4组合时都要排除掉。说白了你对某些组合不感兴趣那就让它们从统计里消失。这里必须提个醒交叉覆盖的数量是呈几何增长的。两个各有16个bin的覆盖点做cross会生成256个交叉bin。如果三个覆盖点各16个bin那就是4096个交叉bin。在设计覆盖率模型时无脑cross会让覆盖率报告膨胀到你根本不想看而且仿真性能也会受影响。我的建议是只对你真正关心的功能点做交叉覆盖。如果你自己都说不清楚这个交叉组合要验证什么行为那就先别写。2.4 覆盖率选项与收集流程从数据到决策的闭环除了基本的coverpoint和crossSystemVerilog覆盖率还有几个常用选项这些选项用好了能让覆盖率数据更符合你的验证目标。第一个是weight选项。每个coverpoint或cross都可以设置权重默认权重是1。如果你希望某个关键组合在总覆盖率中占比更高可以把权重调大。比如cp_high_priority : coverpoint sig_a { weight 3; } cp_low_priority : coverpoint sig_b { weight 1; }第二个是goal选项。默认覆盖率目标是100%但实际项目中有些点确实很难达到100%覆盖。你当然可以努力去补激励但有些是设计本身就不会出现的情况这时可以显式设置goal为90%或95%并配套ignore_bins做说明。不过这个操作要慎重默认不推荐乱改goal因为管理层看覆盖率数字时100%和90%的说服力完全不同。第三个是option.per_instance。当同一个covergroup被多个实例化时默认覆盖率是合并统计的。但你有时需要单独看某一个实例的覆盖情况比如有多个相同通道的FIFO你想确认是不是某个通道从来没被充分测试过。这时设置per_instance1即可covergroup cg_fifo (posedge clk); option.per_instance 1; ... endgroup覆盖率收集的工作流一般是定义covergroup并实例化 - 跑仿真 - 生成覆盖率数据库通常在仿真结束时通过$coverage_save或工具自动生成 - 用工具打开覆盖率报告 - 分析未覆盖项 - 补充或调整激励 - 重跑仿真。当你发现覆盖率数据涨不上去了先别急着加激励看看那些未覆盖bin是不是ignore_bins没设对或是验证环境里某些限制条件导致激励根本不可能产生这些值。找到根因调整起来就事半功倍。3. SVA断言从属性到验证3.1 断言的底层逻辑属性、序列、成功与失败SVA的基础概念其实不多但初次接触时容易绕晕。核心就三个序列sequence、属性property、断言assert。序列是最底层的时间行为描述。比如“信号a拉高后的下一个周期信号b会拉高”这个行为描述就叫序列sequence s_req_ack; (posedge clk) req ##1 ack; endsequence这里##1表示延迟一个时钟周期。req ##1 ack的意思就是当前周期req1下一个周期ack1。如果这个序列匹配成功那属性就对这个序列进行进一步判别。属性是比序列更高一层的概念它可以包含蕴涵操作符。最常见的是|-和|分别表示“如果前件成立则当前周期后件必须成立”和“如果前件成立则下一个周期后件必须成立”property p_req_ack; (posedge clk) req |- ##1 ack; endproperty assert property (p_req_ack);第三行就是断言本身。把属性和断言语句结合起来仿真器在每个时钟上升沿检查这个属性是否成立。如果前件req1但后件ack没有在下一周期拉高断言失败并报错。好多人刚开始写SVA时容易混淆sequence和property。我的理解方式是sequence管的是“信号之间如何随时间展开”property管的是“这个展开过程需要满足什么整体要求”。sequence可以嵌套在property里但property不能反过来嵌到sequence里至少在基本用法上是这样。等你会灵活使用sequence重命名、局部变量后对这两者的边界感会更深。3.2 时序控制与常用操作符从##1到$past覆盖最常见的协议场景SVA里的时间控制符是理解断言语义的重中之重。除了##1、##2这种固定延迟外还有一种延迟范围比如##[1:3]表示延迟1到3个周期之内后件成立即可property p_req_ack_range; (posedge clk) req |- ##[1:3] ack; endproperty##[1:3]在真实协议验证里非常常用。比如很多总线的应答信号协议规定必须在请求后2到4个周期内返回这种场景用固定延迟就没法写了只能用延迟范围。还有一个高频操作符是$past()。它可以取信号在前几个周期的值。比如你想验证“当ready拉高时data信号相比上一周期发生了变化”就可以写property p_data_change; (posedge clk) ready |- (data ! $past(data)); endproperty$past函数有几个可选参数最常用的是$past(signal, n)表示当前周期之前第n个周期的值n默认是1。还有一个需要注意的参数是clock gating但实际项目中我用得不多通常默认即可。另外一个比较常用的是throughout和within用来描述“某个条件在整个时间段内一直成立”。比如写使能拉高期间读使能必须一直保持低电平property p_no_read_during_write; (posedge clk) write_en throughout (write_valid ##1 write_valid); endproperty实际操作中我发现新人最容易踩坑的是时钟域的问题。SVA默认是单时钟域的如果你在时钟a的always块里采样了时钟b域的信号很容易出现竞争。正规做法是断言也按信号所属时钟域来写不要图省事。跨时钟域的断言不是不能用但有专门的CDC验证方法学那个是另一个大坑这里按下不表。3.3 断言的复用与层次化在interface里封装在模块里调用断言的复用性非常重要。一个项目里可能有好几个模块都有类似的协议要求比如所有生成write_valid的模块都要求write_valid不能和write_ready同时为高或者握手信号拉高后必须在一个窗口内完成。如果你在每个模块里各写一遍断言后期维护成本很高而且很容易出现同一协议在不同模块里写了不同版本的问题。推荐的做法是把断言封装在interface里。interface本来就是用来描述模块之间通信协议的把和协议相关的时序断言放在里面再自然不过。比如interface axi_lite_interface(input logic clk, input logic rst_n); logic [31:0] awaddr; logic awvalid; logic awready; // 协议断言awvalid与awready不能同时与复位冲突 property p_awvalid_no_assert_during_reset; (posedge clk) disable iff (!rst_n) not (awvalid awready); endproperty assert property (p_awvalid_no_assert_during_reset); endinterface在模块顶层例化这个interface后断言会自动随接口的例化而生效。这样做的好处是验证环境里用的接口信号驱动方式、DUT里实际的时序行为都被统一的断言约束住了。改协议时只改interface不用满工程找断言。另一个复用技巧是把断言封装成bind模块。当你不想修改被测模块的RTL代码时可以用bind语句把断言模块“绑”到目标模块内部。这在验证第三方IP时特别有用bind dut_module protocol_checker checker_inst( .clk(clk), .rst_n(rst_n), .req(req), .ack(ack) );bind语句就像是“外挂”了一组断言到设计模块上不会改动原RTL但仿真时这些断言对所有例化dut_module的实例都生效。第一次用bind的时候可能觉得有点“魔法”但它确实是SVA复用的一把利器。4. 实操一个总线协议检查的完整实例4.1 设计需求与验证目标纸上谈兵说了这么多我拿一个简化的SRAM接口协议来做完整演示。假设接口信号只有四个req请求信号高电平有效ack应答信号高电平有效wr读写选择1表示写、0表示读addr地址总线宽度8位data写数据总线宽度8位协议要求req拉高后ack必须在2到4个周期内拉高在req和ack同时为高的周期wr、addr、data必须保持稳定复位期间不允许出现req拉高一次事务完成后req1且ack1的下一拍req必须拉低至少一拍不允许连续发起事务现在的验证目标设计一个验证环境收集上述协议行为的覆盖率同时用SVA监控协议是否被遵守。4.2 覆盖率模型实现定义关键覆盖点和交叉覆盖针对上面的协议要求可以设计如下的覆盖率模型。我把covergroup定义在interface里方便直接采样接口信号interface sram_if(input logic clk, input logic rst_n); logic req; logic ack; logic wr; logic [7:0] addr; logic [7:0] data; covergroup cg_sram_protocol (posedge clk); option.per_instance 1; // 请求和应答的相位关系 cp_req_ack : coverpoint {req, ack} { bins idle {2b00}; bins pending {2b10}; bins completed {2b11}; bins illegal {2b01}; // 没有req就出现ack正常协议中不该出现 } // 读写类型 cp_wr : coverpoint wr; // 地址分区低地址、中地址、高地址、边界值 cp_addr : coverpoint addr { bins low {[0:63]}; bins mid {[64:191]}; bins high {[192:254]}; bins max {255}; } // 读写操作与地址分区交叉 cross_wr_addr : cross cp_wr, cp_addr; // 事务完成后的下一拍行为需要配合采样时刻 cp_req_ack_next : coverpoint {req, ack}; endgroup covergroup cg_sram_turnaround (posedge clk); // 采集事务结束后req拉低的情况 cp_turnaround : coverpoint req { bins low_after_done {0}; } endgroup cg_sram_protocol cg_protocol new(); cg_sram_turnaround cg_turnaround new(); // 用事件触发采样事务完成后的状态 event ev_transaction_done; covergroup cg_after_done (ev_transaction_done); cp_req_after : coverpoint req; cp_wr_after : coverpoint wr; endgroup cg_after_done cg_after new(); // 在事务完成时触发采样事件 always (posedge clk) begin if (req ack) -ev_transaction_done; end endinterface这段代码演示了几个关键点第一coverpoint的表达式可以是信号拼接{req, ack}这样能直接把组合状态当成一个覆盖点来统计。2b01被标记为illegal bin因为协议不允许在没有请求的情况下出现应答。这个bin如果在覆盖率报告里出现了计数那基本意味着设计有bug。第二用cross把读写选择和地址区间做了交叉覆盖。地址分四个区间读写分两种情况所以这个cross一共有8个bin。数量不大有意义适合演示。第三cg_after_done这个covergroup使用了自定义事件ev_transaction_done来触发采样。只有在req和ack同时为高的下一周期才会采样req和wr的状态用来检查“事务完成后req是否成功拉低、wr是否还保持原值”。这里有个仿真时序细节要强调在always块里用-ev_transaction_done触发事件这个事件的触发时刻是在当前time step的NBA阶段如果事件来自阻塞赋值还是可能提前不同仿真器行为会有微小差异。稳妥做法是如果需要采样“事务完成后的下一拍”你可以在事务完成事件触发的地方加一个#1step或使用clocking block的采样边沿。但那样写出来例子会太复杂这里只是展示思路实际项目中要根据仿真器行为确认采样点。4.3 断言检查实现把协议规则变成可执行的约束覆盖率负责统计“测到哪些场景”断言负责检查“这些场景有没有违反协议”。针对协议的四条要求我写四个断言// 断言1req拉高后ack必须在2到4个周期内拉高 property p_ack_within_2_to_4; (posedge clk) disable iff (rst_n 1b0) $rose(req) |- ##[1:3] ack; // 注意这里用了[1:3]配合下次采样相当于req拉高后的第2到第4个周期 endproperty assert property (p_ack_within_2_to_4) else $error(req raised but ack not asserted within 2-4 cycles); // 断言2req1且ack1时wr、addr、data必须保持稳定即下一拍与当前拍值相同 property p_stable_during_transfer; (posedge clk) disable iff (rst_n 1b0) (req ack) | ($stable(wr) $stable(addr) $stable(data)); endproperty assert property (p_stable_during_transfer) else $error(Control signals changed during transfer); // 断言3复位期间不允许req拉高 property p_no_req_during_reset; (posedge clk) disable iff (rst_n 1b1) not ($rose(req)); endproperty assert property (p_no_req_during_reset) else $error(req asserted during reset); // 断言4一次事务完成后req必须拉低至少一拍 // 检测req和ack同时为高的上升沿下一拍req必须为0 property p_req_low_after_done; (posedge clk) disable iff (rst_n 1b0) (req $rose(ack)) | !req; endproperty assert property (p_req_low_after_done) else $error(req did not deassert after transaction completion);逐个解释一下第一个断言的$rose(req)是检测req的上升沿也就是请求发出的时刻。|-后面的##[1:3] ack表示之后的1到3个周期内ack必须为高。为什么写[1:3]而不是[2:4]这里涉及时间原点的理解$rose(req)是在上升沿那一拍被检测到的这一拍属于周期0。##[1:3]表示的是“从下一拍开始算起的1到3拍内”。如果你的协议要求的是“req拉高的那一拍不算第2到第4拍要看到ack”那写法就是##[2:4] ack。这两种写法在周期计数上非常容易混淆我一开始也经常搞错建议写完之后在仿真波形里专门盯几个pass用例确认一下。第二个断言的|符号表示下一拍成立。$stable(signal)是SVA内置的系统函数当信号与上一个采样周期的值相同时返回真。这里用( req ack ) | $stable(...)检查的是在req和ack同时为高的这一拍之后的下一拍wr、addr、data的值不发生变化。为什么这么写因为我们通常关心的是“数据传输的那一拍各信号要保持稳定”而且要注意握手完成的那一拍信号值会被接收方采走下一拍即使变了也不影响本次传输。这个断言的语义是本轮传输完成后的下一拍这三个控制信号保持了原值。如果你希望检查的是“在reqack为高的那一拍”信号必须等于前一拍的值那应该写成|- $stable(...)配合$past。这两种需求经常被混在一起写之前务必想清楚你要验证的是“传输前保持”还是“传输后保持”。第三个断言的disable iff (rst_n 1b1) 和前面的思路相反表示当rst_n为高时整个断言被禁用。这其实是错误的写法注意看这个断言我要检查的是“复位期间不允许req拉高”因此必须在复位拉低即rst_n0时使能断言但disable iff应该是使能条件的反。在这个仿真实例里如果你写disable iff (rst_n 1b1)当rst_n为0时断言工作检查有没有$rose(req)。看起来似乎可行。但更标准、语义更清晰的写法是property p_no_req_during_reset; (posedge clk) if (!rst_n) not ($rose(req)); else $pass; endproperty或者更常见的写法是直接用disable iff把复位条件排除掉但注意排除的是“复位状态”不是“非复位状态”。比如你想在复位期间禁止断言很自然地写disable iff(rst_n)意思是复位时整个断言不使能。上面我写的disable iff (rst_n 1b1)就是这个意思。但要注意这和你预期的“复位期间检查”是冲突的——复位时断言都关了还怎么检查复位期间的行为所以如果协议明确要求复位期间req不能拉高你应该把断言写成不复位时检查肯定行为如req不能与ack同时拉高过久而不是在复位状态里加not。因为绝大多数SVA断言库的设计思路都是“功能阶段才检查时序”复位阶段直接禁用。你非要检查复位期间的行为可以用单独的always块配合if (!rst_n)来做不要硬塞进SVA断言里。这里我保留这个例子是为了提醒大家思考disable iff条件时一定要先想清楚“我要在哪个时间窗口内做检查”。第四个断言用来防止连续发起事务。协议要求事务完成后req必须拉低至少一拍。所以用( req $rose(ack) )作为前件检测ack上升沿且req为高这表示事务完成。紧接着的下一拍要求req为0。这样能保证两次事务之间至少隔一拍空档。4.4 仿真运行与结果分析如何用覆盖率报告反推测试缺口上面这些断言和covergroup写在一个interface里仿真时把它和DUT、testbench顶层连好。顶层验证环境的示意代码大致长这样module tb_top; logic clk; logic rst_n; initial begin clk 0; forever #5 clk ~clk; end // 复位序列 initial begin rst_n 0; #20; rst_n 1; end // 实例化interface sram_if u_sram_if( .clk(clk), .rst_n(rst_n) ); // 驱动激励用简单task发几个事务 initial begin wait(rst_n 1); // 第一个事务地址0x10写操作 drive_write(8h10, 8hAB); // 第二个事务地址0x99读操作 drive_read(8h99); // 第三个事务地址0xFF写操作 drive_write(8hFF, 8h12); // 完结 #100; $finish; end task drive_write(input [7:0] addr, input [7:0] data); (posedge clk); u_sram_if.req 1; u_sram_if.wr 1; u_sram_if.addr addr; u_sram_if.data data; do (posedge clk); while (!u_sram_if.ack); u_sram_if.req 0; endtask task drive_read(input [7:0] addr); (posedge clk); u_sram_if.req 1; u_sram_if.wr 0; u_sram_if.addr addr; do (posedge clk); while (!u_sram_if.ack); u_sram_if.req 0; endtask endmodule跑完之后我模拟一下覆盖率报告里可能出现的情况。假设只有上面三个简单事务那么cp_req_ack覆盖点idle和completed可能被覆盖到pending不一定。如果每个事务的ack都在req拉高后的第2拍出现那你的覆盖率只覆盖了“请求保持2拍得到应答”的场景没有覆盖“请求保持3拍”或“4拍才应答”的场景。这就是一个典型测试缺口。cp_addr覆盖点0x10落在low区间0x99落在mid区间0xFF落在max区间但mid区间虽然被0x99访问到了其他地址区间如high区间192到254没有事务访问过。所以cp_addr会有部分覆盖率缺口。cross_wr_addr覆盖点写操作只访问了low和max区间读操作只访问了mid区间。也就是说“写mid”“读low”“读high”“读max”这些组合都缺失。断言方面如果DUT的时序正确四条断言都应该被pass。但你可以故意在drive_read里把ack行为改乱比如在req拉高后第5拍才拉高ack断言1就会立刻报错。这就是SVA在仿真中的实时监控能力。分析法不是跑完就结束的。拿到这份覆盖率报告下一步应该做两件事一是增加激励让未覆盖的场景出现比如把地址改成0xC0、0x0F等二是在testbench里做一个随机延迟的ack生成器让ack在2到4拍之间随机返回从而把应答时序范围拉开。如果Ack时序是靠DUT内部状态机产生的那就要去检查状态机的设计看是不是存在某些状态无法进入的问题——这往往是RTL缺陷的先兆。5. 踩坑记录与排查技巧5.1 覆盖率一直是0%先别怀疑工具很多人第一次把covergroup写好、跑完仿真打开覆盖率窗口看到0%的时候第一反应是工具出问题了。以我的经验绝大多数情况下是代码写错了。最常见的原因是covergroup没有实例化。covergroup和class不同你没有定义变量并调用new()它不会自动创建。在module或interface里写covergroup定义但没有实例化仿真器不会报编译错误但覆盖率收集路径根本没有建立。解决办法就是在initial块或声明处显式new()。第二个常见原因是采样信号写错了作用域。在class里定义的covergroup如果采样信号是tb_top顶层信号你需要通过虚接口或构造函数传参进去如果你直接用全局信号名很容易产生编译问题或者采到的始终是x态。在UVM里我习惯在monitor里用analysis port把事务对象发给scoreboard然后在scoreboard里对事务字段做覆盖。这样既能采样到事务级数据又不需要关心时序采样点。第三个原因是采样事件没有触发。比如你把covergroup的采样事件绑定到了某个soft event但这个事件在仿真过程中从未被触发过那覆盖率自然一直是0%。你可以用$increment_coverage或仿真器的覆盖率窗口来查看哪些covergroup完全没有采样记录然后从这些covergroup入手排查。第四个不太显眼但很容易踩的坑在循环中实例化covergroup但没有为每个实例保存引用。比如你在for循环里连续new了10个covergroup但没有把每个实例保存在数组里前面的实例会被垃圾回收或覆盖导致你实际只收集到了最后一个实例的数据。这在分析per-instance覆盖率时尤其致命很多人只看总覆盖率没发现但看每个实例的覆盖率才发现一大片是零。5.2 断言误报的常见来源信号还没稳定就下结论断言写好后最头疼的问题之一就是误报。明明协议上设计是对的断言却报了error。根据我的经验误报大多出在以下几个场景第一复位释放后的头几个周期信号可能还没稳定。SVA断言通常在复位期间通过disable iff关闭但复位释放瞬间用$rose、$fell检测信号边缘时仿真器可能因为x态或初始值而产生误判。建议在断言里统一加上disable iff (rst_n 1b0)给信号留出确定的建立时间。第二采样时刻和赋值时序不匹配。如果你在时钟上升沿的阻塞赋值区阻塞赋值更新了信号而断言也在同一个上升沿采样那么断言看到的值可能是旧值也可能是新值取决于仿真器的调度顺序。为了避免这种不确定性推荐使用clocking block来采样或者直接在班子里用非阻塞赋值驱动信号。UVM里大家对非阻塞赋值都很熟但到了写断言时就容易忽略采样同步问题。第三时钟门控和异步复位嵌套带来的问题。如果你的设计里有门控时钟SVA的(posedge clk)是采样不到门控打开后的边沿的这时你需要用$clk_gate_check这类专门的时钟门控断言或把时钟信号改成门控后的有效时钟。异步复位吃掉请求信号的情况更复杂简单用disable iff处理复位会导致断言窗口被截断。这在异步设计中是个深坑只能说尽量在验证计划里提前定义好复位和断言的交互策略。5.3 性能优化覆盖率收集和断言监控的开销不能忽视覆盖率收集和断言监控都是有性能代价的尤其在跑回归仿真时。覆盖率收集的核心开销在cross。十个以上的覆盖点做全交叉很容易让仿真速度慢一倍以上。断言则更多体现在属性评估的复杂度上。如果断言里包含复杂的时间窗口比如##[1:100]仿真器在100个周期内都要跟踪这个属性实例开销会显著增大。常见的优化手段包括减少不必要的cross只交叉真正有关联的场景。将covergroup的采样频率降低。如果采样事件从每个时钟改成事务完成时才采一次覆盖率收集开销会大幅下降。用ifdef控制断言和覆盖率编译开关。比如ifdef ASSERT_ON ...endif在性能验证或功耗仿真时关掉。批量处理时可以用多个仿真批次分别收集不同覆盖率然后合并覆盖率数据库而不是一次仿真收集所有覆盖率。还有一点很实用如果你在跑超大规模SoC级别的验证覆盖率数据库文件动不动几个GB建议在covergroup里配置option.coverage_goal和option.weight减少不必要的bin。毕竟没人会认真看一个有十万个bin的覆盖率报告。5.4 多周期断言与性能仿真的“不兼容”问题这个话题在项目量产阶段尤其值得注意。多周期路径Multicycle Path在静态时序分析里经常出现性能仿真Power-Aware Simulation也可能让时钟、复位行为变得非常复杂。在这些场景下你精心调好的断言很可能因为时序变化而产生大量误报。我的建议是在做综合后仿真或低功耗验证时对时序类断言做一次专门的审查该关掉的关掉该加disable条件的加上。断言是验证工具不要让它们变成仿真回归里的“狼来了”噪音报错的断言如果没人第一时间处理后面大家就会忽略所有断言就起不到实时监控的作用了。覆盖率和断言这套东西刚上手时确实容易写成“为了覆盖率而覆盖率”“为了断言而断言”。我自己的体会是最好的切入点是从协议规范出发你拿到的接口协议文档里每一句话几乎都能翻译成一条断言或一个覆盖点。协议说“信号X必须保持稳定直到Y事件”那就是$stable的断言协议说“允许的X状态有A、B、C”那就是三个bin的覆盖点。把一个接口协议翻译成十几条断言和四五个covergroup这个过程的收获远比最后看到“覆盖率100%、断言全pass”的数字要大。到下一篇笔记我打算动笔搭建一个完整的UVM验证环境把这些断言和覆盖率全部嵌进去做成一个能直接用于项目的开源模板。