如果你正在啃 System Verilog看到第9篇这个序号应该能猜到我这份笔记是按自己排的顺序在更新的。之前几篇把数据类型、流程控制、面向对象、随机化、约束、线程和邮箱这些基础都过了一遍这一篇我想专门聊聊整个验证环境里最容易被单独学、却很少被串起来用的三个语法点interface、clocking block 和 SVA 断言。为什么把这仨放在一起因为在实际搭 testbench 的时候它们根本不是三件事而是一件事的三面。interface 负责提供一个固定的信号集合和方向协议clocking 负责让 driver/monitor 对这个信号集合的采样和驱动在时间上确定下来SVA 则直接在信号集合上写时序检查。很多同学分别看语法都能看懂一进真实环境就傻眼问题基本都出在不知道这三者怎么配合。这篇笔记不是照着手册念而是把我在写 APB 验证片段时遇到的一个完整套路拆开讲适合刚把 SystemVerilog 基础过完、准备自己搭一个模块级验证环境的人。1. 为什么要把 interface、clocking 和 SVA 放在一起学1.1 三个语法点各自解决什么问题很多人学 SystemVerilog 的时候会下意识地把语法点当成零散的“知识点”去背interface 记成“一种新的连接方式”clocking 记成“一个同步信号的容器”SVA 记成“一种用来写断言的语言”。这么记不能说错但会漏掉它们之间真正的协作关系。我习惯用一句话概括interface 解决的是信号怎么组织、方向怎么约束的问题。clocking 解决的是信号在哪个时刻被采样、在哪个时刻被驱动的问题。SVA 解决的是信号之间的关系是否满足协议时序的问题。在一个完整的验证环境里一个总线接口信号会同时被三种角色使用DUT 把它当真实的输入输出端口driver 要按协议驱动它monitor 要按协议观察它。如果不做任何约束同一个信号会被多个地方乱写方向全靠自觉采样时刻全靠(posedge clk)硬等最后的仿真结果经常差一拍、抢一拍出问题根本说不清楚是谁的锅。interface、clocking、SVA 这三者组合起来相当于把“信号长什么样”“谁在什么时候碰它”“碰得对不对”三件事一次定死。1.2 分开学为什么容易“会语法不会用”我见过不少同学单问 interface 怎么写、clocking 的#1step是什么、$rose和$fell怎么用都能答出来。但一让他从零搭一个小模块的验证环境就开始卡壳interface 里的信号要不要都列出来modport 是不是必须的driver 里到底该写(posedge clk)还是(vif.drv_cb)SVA 应该放在 testbench 里还是 interface 里这些问题单独看语法书没有一本会给你完整答案因为它们是“语法点的组合用法”。比如 SVA 如果写在 module 外部你得把一堆信号作为端口传进来写起来很啰嗦但如果把它写在 interface 里信号天然就在作用域内断言可以直接引用还方便复用。这种“位置选择”是工程经验不是语法书会告诉你的。1.3 本篇笔记的路线所以我决定第9篇这么安排先用最简单的语言把 interface、clocking、SVA 分别讲透然后用一个 APB 总线的小验证片段把它们串成一个能跑起来的完整例子。最后把我自己踩过的坑列一遍这些都是你大概率也会遇到的。2. interface 不只是“连线”它是验证环境里的契约层2.1 最小接口与为什么要用接口接口最简单的理解就是一堆信号的集合。比如我们定义一个 APB 接口interface apb_if #( parameter ADDR_WIDTH 32, parameter DATA_WIDTH 32 ) (input logic pclk); logic psel; logic penable; logic pwrite; logic [ADDR_WIDTH-1:0] paddr; logic [DATA_WIDTH-1:0] pwdata; logic [DATA_WIDTH-1:0] prdata; logic pready; logic pslverr; endinterface这里我把pclk作为接口的输入端口剩下的信号都在接口内部声明。这样做的第一个好处是DUT 和 testbench 都不需要各自声明一堆端口只要在模块端口里写一个apb_if.TB bus或者apb_if.DUT bus就能拿到全部信号。第二个好处是当总线信号需要新增时比如某个项目里 APB 多了一个pprot信号你只需要在 interface 里加一行所有使用这个接口的模块、类、断言都能立刻看到不需要去翻 DUT 和 TB 的端口列表。2.2 modport方向不只是装饰信号集合有了但“方向”这个问题还悬着。APB 总线上DUT 是 slave它接收 psel、penable、paddr、pwdata输出 prdata、pready而 driver 正好相反。如果方向不固定代码里很容易出现一个模块误驱动了本不该它驱动的信号。modport 就是干这个的modport DUT ( input psel, penable, pwrite, paddr, pwdata, output prdata, pready, pslverr ); modport TB ( output psel, penable, pwrite, paddr, pwdata, input prdata, pready, pslverr );看到这里你应该明白modport 不只是在文档层面表示方向它会在编译层面限制访问。如果一个模块端口声明为apb_if.DUT bus那么它在内部就只能驱动 output 列出的信号而不能驱动 input 信号。这种限制在大型项目里非常值钱因为它把“人别犯错”变成了“编译器不让犯错”。2.3 参数化接口与接口里的子程序接口也支持参数这在实际项目中非常常用。比如地址宽度和数据宽度的参数会贯穿整个验证环境接口先定义好DUT、driver、monitor 全部都从同一个参数源取值避免各处32h写死。接口里还能定义任务和函数。如果你有很多重复的时序操作可以直接写在接口里作为公共方法。不过我个人建议像 driver 这种比较大的任务还是放在 class 里接口里的任务适合放一些“协议层面的短操作”比如一次单拍握手或者一个简单的等待条件。2.4 virtual interface让类访问接口面向对象是 SystemVerilog 验证环境的骨架但 class 本身不能像模块那样例化一个接口实例。它只能通过virtual interface拿到接口的句柄然后访问里面的信号。这个过程有点像你拿着一个遥控器去操作远处的电视机类并不拥有信号但可以通过遥控器去控制。class apb_driver; virtual apb_if vif; function new(virtual apif vif); this.vif vif; endfunction endclass这里有个细节我用的virtual apb_if没有指定 modport。这样写最灵活class 里想访问哪个信号都行。如果某天你想约束 driver 只能用 TB 方向的接口可以把声明改成virtual apb_if.TB vif。虽然实际中不少团队为了省事不写这层约束但我还是建议写上它的价值和我前面讲 modport 一样就是让方向问题在编译期暴露而不是等仿真跑飞了再去查。2.5 用接口时常见的“方向失守”场景我见过一个最容易出问题的场景一个接口信号让两个 driver 同时驱动。SystemVerilog 对多个连续赋值 wire 类型有解析规则但对 logic 类型如果多个进程同时驱动仿真器会警告甚至直接 X 态。接口不会阻止这种错误它只提供一个地方统一声明信号真正的保护来自 modport 和你的编码规范。所以我的建议是接口里能写 modport 就写能带参数就带把接口当成一个真正的“协议契约”来管理而不是当成一个快速连线工具。3. clocking block 的 skew 语义决定了你的 TB 稳不稳3.1 clocking block 长什么样很多新手第一次看到 clocking block 会有一种“这不是多此一举吗”的感觉。直接(posedge clk)不也能同步吗为什么要包一层时钟块我先给你看一个典型写法default clocking drv_cb (posedge pclk); default input #1step output #2; output psel, penable, pwrite, paddr, pwdata; input prdata, pready, pslverr; endclocking default clocking mon_cb (posedge pclk); default input #1step output #2; input psel, penable, pwrite, paddr, pwdata, prdata, pready, pslverr; endclockingdrv_cb是给 driver 用的时钟块output 表示这个时钟块的使用者负责驱动这些信号input 表示使用者采样这些信号。mon_cb是给 monitor 用的所有信号都只采样不驱动。3.2 input #1step 和 output #2 到底是什么意思这是 clocking block 最核心、也最不好理解的部分。我直接用时间轴解释。当你在时钟块里声明default input #1step时意思是所有 input 信号在对应的时钟沿到来之前一个时间步采样。这个“一个时间步”发生在仿真调度器的 NBA 区之前保证你采样到的值是“时钟沿前一刻的值”而不是时钟沿后某个进程刚刚更新的值。#2则相反它表示 output 信号要在时钟沿之后 2 个时间单位才被驱动。这相当于模拟了实际的时钟到输出延迟避免你的 TB 信号和 DUT 内部信号在同一时刻被求值从而产生竞争。所以 clocking block 做的事情本质上是把“什么时候采样、什么时候驱动”这两个时间决策固化下来。你不必在每个 driver 里写#1step或者#1这种人为延时所有使用者共用同一套时序规则。3.3 没有 clocking 时的竞争有多难受没有 clocking block 的时候典型的采样代码长这样(posedge clk); data vif.pready;问题是这个(posedge clk)之后的 data 读取到底读到的是时钟沿之前的值还是 DUT 刚更新的值这在不同的仿真器、不同的编译顺序下结果可能不一样。因为时钟沿触发的事件不止一个而你的 TB 进程和 DUT 进程的执行顺序没有强制约束。clocking block 把采样点固定到#1step之后所有使用这个时钟块的进程对同一信号的采样结果就是一致的不会再出现“谁先跑谁后跑”的玄学问题。3.4 一个接口里的多个时钟块怎么分配上面我写了两个时钟块这在实际项目中很常见。driver 需要输出控制信号、采样状态信号所以它有独立的 drv_cbmonitor 需要观察所有信号所以它有独立的 mon_cb。两者互不干扰各自固化了各自的采样和驱动时刻。如果 driver 和 monitor 公用同一个时钟块也不是不行但方向声明会非常别扭driver 视角的 output 符号在 monitor 视角就变成了输入反过来也成立。与其在一堆input和output里绕来绕去不如一开始就按角色拆成多个时钟块代码读起来也清晰得多。3.5 访问时钟块的几个易错点时钟块里的 output 信号只能用非阻塞赋值驱动。时钟块里的 input 信号只能被采样不能赋值。直接访问vif.psel和访问vif.drv_cb.psel不是一回事前者是墙上的电线后者是“在时钟沿前后某个确定时刻去读/写电线”的操作。(vif.drv_cb)等价于等待这个时钟块对应的时钟事件但它和(posedge vif.pclk)在严格调度语义下是有细微差别的后者更底层。经验不够丰富时优先用(vif.drv_cb)它能保证你的采样点在时钟块定义的采样窗口内。4. 在 interface 里写 SVA把协议检查内嵌到信号源头4.1 立即断言和并发断言先分清时机SystemVerilog 的断言分两大类立即断言和并发断言。立即断言写法是assert (expr) else ...;它在过程块里执行到那一行时立即求值不会跨越时钟也不创建线程。它更适合做“当前状态对不对”的检查比如某个事件发生后立刻确认标志位被置位。并发断言是assert property (property_expr);它从仿真开始就一直存在或者从使能时刻开始在指定的采样时刻评估整个时序表达式。它是 SVA 的灵魂也是我们做协议检查主要用的东西。两者的时机差异非常关键立即断言在过程代码的“现在”时刻检查并发断言在“每一个相关时钟沿”检查。你把并发断言当成立即断言用或者反过来都会得到一堆莫名其妙的误报。4.2 我最常用的系统函数和 sequence 写法SVA 里有一组内建函数是写断言时的高频工具我每天都会用到$rose(sig)信号在采样沿变为 1$fell(sig)信号在采样沿变为 0$stable(sig)信号保持原值$past(sig, n)取 n 拍之前的值$onehot(sig)只有一位为 1$onehot0(sig)只有一位为 1 或全 0$isunknown(sig)存在 X/Z 态sequence 是描述信号序列的最小单元sequence s_penable_rise; $rose(penable); endsequence sequence s_access_phase; psel penable; endsequencesequence 里可以用##1、##2表示间隔周期用[*1:$]表示重复一到任意次数用and、or、within、throughout组合更复杂的时序关系。4.3 property 和蕴含的思考方式property 是断言的更外层容器它把 sequence 组合成完整的前因后果。最常用的是蕴含操作符|-和|。a |- b当 a 成立时在同一个采样沿检查 b。a | b当 a 成立时在下一个采样沿检查 b。我把蕴含理解成逻辑里的“如果……就必须……”。写断言的时候先问自己三个问题触发条件是什么也就是“如果”的部分。要检查的后续是什么也就是“就必须”的部分。这两者发生在同一拍还是下一拍这决定用|-还是|。想清楚这三点大部分 APB 级协议断言都能写出来。4.4 将 APB 协议规则写成断言回到 APB 协议本身。一个最简单的写传输大概长这样IDLE 状态下 psel 拉高下一拍 penable 拉高进入 ACCESS 阶段等待 pready 为高之后传输完成然后 psel、penable 拉低。这个协议可以拆成两条核心断言property p_penable_after_psel; (posedge pclk) $rose(psel) | $rose(penable); endproperty ap_penable_after_psel: assert property(p_penable_after_psel); property p_penable_requires_psel; (posedge pclk) penable |- psel; endproperty ap_penable_requires_psel: assert property(p_penable_requires_psel);第一条的含义是一旦 psel 从 0 变 1下一拍 penable 必须从 0 变 1这对应 SETUP 阶段必须进入 ACCESS 阶段。第二条的含义是penable 为高的任何时刻psel 必须为高防止出现没有选中设备就使能传输的非法状态。如果你还想检查 ACCESS 阶段地址和写数据不能乱变可以这样写property p_addr_stable_during_access; (posedge pclk) (psel penable !pready) | ($stable(paddr) $stable(pwrite)); endproperty ap_addr_stable_during_access: assert property(p_addr_stable_during_access);这条断言的逻辑是当前处于 ACCESS 阶段且 pready 还没拉高下一拍 paddr 和 pwrite 必须保持不变。这个行为正好对应 APB 规范里“控制信号在传输完成前必须保持稳定”的要求。4.5 断言的开关、打印和调试断言写多了以后你会发现有时候跑大规模回归一堆断言同时开着出错的第一个信号很难定位。所以我养成了一个习惯在验证顶层提供开关按模块或按接口控制断言。$assertoff(level, scope)关闭某个范围的断言$asserton(level, scope)重新打开$assertkill(level, scope)终止当前未完成的断言尝试这些控制语句可以放在 initial 块里按 test 的需求动态调整。比如某些掉电用例里时钟会停有些断言会误报那就在这种 test 里关掉对应的能力断言。调试断言失败时我最常用的手法是先看失败发生的时间点再用-assert debug或等价选项打开断言调试窗口查看这条断言的“成功/失败”路径最后对照波形确认是 RTL bug 还是断言本身写错了。断言写错的比例不低所以不要一上来就怀疑 DUT。5. 一个 APB 小验证片段三者协同的完整代码走读前面的部分全是铺垫这一章我直接给一个能编译、能运行的最小验证片段。它包含一个接口、一个最简单的 RTL DUT、一个 driver 类、一个 monitor 类以及把它们拼起来的 testbench。5.1 apb_if信号、clocking、modport、断言集中定义我把之前的内容整合到一个接口文件里interface apb_if #( parameter ADDR_WIDTH 32, parameter DATA_WIDTH 32 ) (input logic pclk); logic psel; logic penable; logic pwrite; logic [ADDR_WIDTH-1:0] paddr; logic [DATA_WIDTH-1:0] pwdata; logic [DATA_WIDTH-1:0] prdata; logic pready; logic pslverr; clocking drv_cb (posedge pclk); default input #1step output #2; output psel, penable, pwrite, paddr, pwdata; input prdata, pready, pslverr; endclocking clocking mon_cb (posedge pclk); default input #1step output #2; input psel, penable, pwrite, paddr, pwdata, prdata, pready, pslverr; endclocking modport DUT ( input psel, penable, pwrite, paddr, pwdata, output prdata, pready, pslverr ); modport TB ( output psel, penable, pwrite, paddr, pwdata, input prdata, pready, pslverr ); property p_penable_after_psel; (posedge pclk) $rose(psel) | $rose(penable); endproperty ap_penable_after_psel: assert property(p_penable_after_psel); property p_penable_requires_psel; (posedge pclk) penable |- psel; endproperty ap_penable_requires_psel: assert property(p_penable_requires_psel); endinterface注意这里我把断言直接写在 interface 内部。这样做的最大好处是无论哪个模块、哪个类使用这个接口断言都在你不需要在 testbench 里额外例化一个“断言模块”。断言和协议放在同一个文件里维护起来非常顺手。5.2 apb_slave用 modport 做端口的 DUT 实现我写一个最简单的 APB slave只有一个寄存器支持写和读module apb_slave #( parameter ADDR_WIDTH 32, parameter DATA_WIDTH 32 ) ( input logic pclk, input logic presetn, apb_if.DUT bus ); assign bus.pready 1b1; assign bus.pslverr 1b0; logic [DATA_WIDTH-1:0] regfile [1]; always_ff (posedge pclk or negedge presetn) begin if (!presetn) begin regfile[0] 0; end else if (bus.psel bus.penable bus.pwrite) begin regfile[0] bus.pwdata; end end always_comb begin bus.prdata 0; if (bus.paddr 1) bus.prdata regfile[0]; end endmodule这里最直观地体现了 modport 的作用apb_if.DUT bus让这个模块只能驱动 prdata、pready、pslverr只能采样 psel、penable 等。如果我不小心在 DUT 内部写了bus.paddr 0;编译器会直接报错这就能在早期拦截一堆笔误。5.3 apb_driver用时钟块驱动driver 类负责发起读写传输。我在类里通过 virtual interface 访问接口的 drv_cbclass apb_driver; virtual apb_if.TB vif; function new(virtual apb_if.TB vif); this.vif vif; endfunction task init(); vif.drv_cb.psel 0; vif.drv_cb.penable 0; vif.drv_cb.pwrite 0; vif.drv_cb.paddr 0; vif.drv_cb.pwdata 0; endtask task write(logic [31:0] addr, logic [31:0] data); (vif.drv_cb); vif.drv_cb.psel 1; vif.drv_cb.penable 0; vif.drv_cb.pwrite 1; vif.drv_cb.paddr addr; vif.drv_cb.pwdata data; (vif.drv_cb); vif.drv_cb.penable 1; do begin (vif.drv_cb); end while (!vif.drv_cb.pready); vif.drv_cb.psel 0; vif.drv_cb.penable 0; endtask task read(logic [31:0] addr, output logic [31:0] data); (vif.drv_cb); vif.drv_cb.psel 1; vif.drv_cb.penable 0; vif.drv_cb.pwrite 0; vif.drv_cb.paddr addr; (vif.drv_cb); vif.drv_cb.penable 1; do begin (vif.drv_cb); end while (!vif.drv_cb.pready); data vif.drv_cb.prdata; vif.drv_cb.psel 0; vif.drv_cb.penable 0; endtask endclass这里的(vif.drv_cb)是等待 drv_cb 对应的时钟事件。因为 drv_cb 的采样点被定义在#1step驱动点被定义在#2所以进入下一轮等待时上一轮设置的值已经在时钟沿后稳定地送到了 DUT 端口上。写 task 里循环等待pready的那几行我在实际项目中经常看到有人直接写while (!vif.pready) (posedge pclk);。这种写法在简单仿真里可能能跑但一旦环境复杂、有多个进程同时操作这个接口就容易被其他进程的信号更新顺序干扰。用时钟块采样每次读到的 pready 都是固定采样窗口的版本判断结果稳定很多。5.4 apb_monitor用时钟块采样monitor 类负责观察总线打印每一次传输class apb_monitor; virtual apb_if.TB vif; function new(virtual apb_if.TB vif); this.vif vif; endfunction task run(); forever begin (posedge vif.pclk); if (vif.mon_cb.psel vif.mon_cb.penable) begin if (vif.mon_cb.pwrite) $display([MON] write addr%0h data%0h, vif.mon_cb.paddr, vif.mon_cb.pwdata); else $display([MON] read addr%0h data%0h, vif.mon_cb.paddr, vif.mon_cb.prdata); end end endtask endclassmonitor 不需要驱动信号所以它只用 mon_cb 的 input 方向。这里我额外用了(posedge vif.pclk)来等待时钟再用vif.mon_cb.xxx去采样。这种组合在实际工程里也很常见等待时钟是自己控制节奏采样值则由时钟块保证确定性。5.5 顶层连接和运行结果最后把它们连到顶层module tb_top; logic pclk 0; logic presetn 0; always #5 pclk ~pclk; apb_if #(.ADDR_WIDTH(32), .DATA_WIDTH(32)) u_if (.pclk(pclk)); apb_slave #(.ADDR_WIDTH(32), .DATA_WIDTH(32)) u_dut ( .pclk(pclk), .presetn(presetn), .bus(u_if.DUT) ); apb_driver drv; apb_monitor mon; initial begin drv new(u_if.TB); mon new(u_if.TB); drv.init(); mon.run(); #20; presetn 1; #10; drv.write(32h0, 32hDEADBEEF); $display([TB] after write reg0 %h, u_dut.regfile[0]); begin logic [31:0] rdata; drv.read(32h0, rdata); $display([TB] read reg0 %h, rdata); end #50; $finish; end endmodule跑完这个仿真你会看到 monitor 打印写和读的传输信息DUT 寄存器值也验证正确。与此同时接口里的两个断言会一直监控时序如果有人把 driver 改成 penable 提前拉高仿真器会直接提示断言失败这就是它们在场上的价值。这个例子的重点不在功能而在于interface 统一了信号集合clocking 统一了采样驱动时刻断言在源头做协议守卫。三者配合你写出来的 testbench 结构非常干净换一个新的 DUT 也只是改接口连接和断言规则driver/monitor 的框架可以直接复用。6. 学习过程中踩过的坑和排查经验6.1 最离谱的一次默认 skew 设反整排信号晚半拍有次我给一个新的 AXI 接口搭环境为了赶进度直接抄了一份 clocking block把default input #1step output #2写成了default input #2 output #1step然后所有读操作的数据都晚了半拍。这种问题最坑的地方在于波形看起来“没有错”只是任何一处都在预期之后一拍。排查方法其实很简单在 monitor 里打印采样到的信号然后和 DUT 里真实信号做一次对拍。如果发现 monitor 看到的信号总是比 DUT 端口晚一拍先别怀疑逻辑检查 clocking 的 skew。skew 设反不像语法错误会编译报错它只会在行为上悄悄影响你。6.2 在时钟块里读到的永远是“旧值”这是新手最容易懵的地方。clocking block 的 input 采样发生在#1step所以你在时钟沿之后立刻读vif.drv_cb.pready读到的还是刚才时钟沿之前的值而不是 DUT 在这个时钟沿更新后的最新值。这不是 bug是特性。它保证了同一时刻的采样结果对所有观察者一致。如果你确实想拿“当前时钟沿更新后的值”就需要再等一个时钟周期或者用$past去处理跨拍关系。理解这一点之后很多“为什么数据慢了一拍”的问题就都明白了。6.3 断言里写阻塞赋值导致编译事故有次我在 property 里想临时检查一个内部计数器的值手一滑写了个过程块里的立即断言又在里面用了阻塞赋值结果仿真器一串编译错误。后来我把代码改成并发断言把要检查的表达式作为序列的一部分问题才解决。这个坑带给我的教训是写 SVA 时先默认用并发断言。并发断言的表达模型是“周期的序列”不是“过程代码里的当前值”。一旦你在断言里写出了always、if、赋值这类过程语句大概率是思路已经跑偏了需要停下来优化写法。6.4 忘绑 virtual interface 的 null 崩溃class 里声明了virtual apb_if vif;但 new 的时候忘了传接口句柄或者传了 null调用vif.drv_cb.psel 1;时仿真器直接报空指针。这种错误本身不难找但如果你在多个构造函数的串联调用里漏了一层报错信息可能不在真正出事的地方。我的建议是在 driver 的new函数里对vif null做一次显式检查不合法就直接$fatal退出。这种防御式编码在环境复杂后能帮你省大量 debug 时间。6.5 回归性能下降的排查SVA 不是免费的。如果你在整个验证环境里堆了几千条并发断言每次事件调度都要评估大回归的仿真时间会明显上升。这时候不能盲目删断言而是要做区分协议关键断言必须常开。调试用临时断言跑完就删或者用$assertoff默认关掉。覆盖率相关断言可以单独控制只在覆盖率收集的 test 中打开。我在一个项目里把临时断言用ifdef包起来在回归编译时直接不生成仿真时间能差出 15% 到 20%。对于动辄跑几天的回归来说这个优化很可观。6.6 给后来者的路径建议如果你刚学完基础语法想练这一篇的内容我建议的路径是先照着第 5 章的 APB 例子手敲一遍确认能跑通然后自己给 interface 加两个断言并故意制造一个违例看看报错信息长什么样接着去改写 driver试试不用 clocking block 直接用(posedge clk)驱动对比一下两种写法的差异。这个练习做完你对 interface、clocking、SVA 的认知就不再是零散的语法点了而是“一个能协同工作的系统”。这也是我写这一篇笔记最想让你拿到的东西。最后再分享一个小技巧如果你的仿真器支持开启动态断言调试选项把断言失败时的波形自动保存下来能省很多来回定位的时间。我后来搭环境的第一件事就是把断言和波形绑定打开遇到问题直接看失败附近的波形比在终端里翻 log 高效多了。