做芯片验证的几乎没有谁没在仿真里写过force和release。但你要是在项目组里随便拦下一个写UVM sequence的工程师问他force执行之后信号到底怎么恢复、为什么有时候release完值没变、变量和wire的释放行为有什么不同十个里面至少有八个会愣一下。这个现象我见过太多次了包括我自己刚入行的头两年对force的理解也基本停留在“写一句话把信号按住”至于它背后的事件调度机制、对net和variable的分叉行为、和UVM层次路径的配合全是模糊的。这个系列文章就是想把芯片验证中force和release这件事彻底讲透。从标准语义到仿真器的实际行为从最基础的层次引用到工程上怎么用uvm_hdl_force封装、怎么和sequence配合再到release的顺序陷阱、多层force叠加时的恢复规则、覆盖率被污染这些坑全部摊开来说。适合正在写UVM验证环境的人适合刚接手门级仿真、开始对内部信号做定向注入的人也适合那些已经被“force了没反应”“release了值不对”折磨过的人看。1. force和release先搞清楚它到底是个什么机制1.1 一个最容易被高估的验证“开关”很多人把force理解成一个简单的“置数开关”force一下设为某个值release一下恢复原状。这个理解方向没错但太粗糙了。在SystemVerilog里force是一条过程赋值语句它可以在initial、always、task这些过程块里使用。它的核心作用是用一个强制值去覆盖目标信号当前的驱动值而且这个覆盖是“越权”的普通的过程赋值、连续赋值、门级输出在它面前全部让路。release则是撤销这次强制让信号重新回到正常驱动的轨道上。这里有一个天然的疑点既然是覆盖那释放之后到底恢复成什么很多人的第一反应是“恢复成force之前的值”。这句话对但只说对了一半。另一半取决于两个因素第一个是目标信号是net类型还是variable类型第二个是变量在force之前有没有被过程赋值“托管”。这两个因素组合起来会产生完全不同的释放结果。我后面会用一整节专门讲这个分叉行为这里先记住一个结论force不是简单的“按一下、松一下”它本质上是在信号驱动链上叠加了一个更高优先级的驱动源。1.2 底层原理为什么force能压过普通驱动要理解force为什么能“压过”其他驱动得从仿真器的时间调度机制说起。SystemVerilog的事件调度把仿真时间划分成多个region同一个time step里信号赋值不是同时生效的而是按照Active、Inactive、NBA、Observed等顺序依次处理。普通的过程阻塞赋值发生在Active区域非阻塞赋值的更新发生在NBA区域连续赋值则每次输入变化都重新求值。force的优先级体现在它绕过了这个正常的驱动求值链。仿真器内部对被force的信号打了一个特殊标记只要这个标记存在信号的实际值就由force决定而不是由RTL里那些assign语句或者驱动器决定。换句话说force操作直接在信号的值存储层面上了“锁”这不是在驱动逻辑里增加一个竞争对手而是直接把裁判叫停了。这也是为什么用force去模拟真实硬件的某些状态注入特别合适因为它真的可以做到“不讲道理”。DUT内部某根线被某个逻辑块死锁成0你用force把它变成1RTL那套逻辑完全没有办法反抗。同样的效果如果用普通驱动去做你得先找到那个逻辑块改约束、改激励、甚至要绕过整条驱动链成本完全不同。不过强制的代价也很现实它脱离了RTL的正常行为轨迹。如果一个信号本来会随输入变化而变化你把它force住那内部所有依赖它的逻辑都会看到你给的值但它自己对外的正常响应逻辑已经失效了。所以force从来不是正常的“激励手段”它更像一把手术刀用来做定点切开和病灶模拟。2. 明确了原理再决定什么场景该用2.1 这种场景就该用异常注入与硬件行为模拟force在芯片验证里最常见的应用场景我归纳下来基本是四类。第一类是异常注入。比如要验证中断处理逻辑在极端情况下的行为可以把DUT内部某条中断线force成常高或者常低观察处理器核的响应。再比如做安全机制验证时把某个关键寄存器的存储节点force翻转模拟单粒子翻转或者硬件错误改写然后检查错误检测逻辑能不能抓到这个异常。第二类是硬件行为模拟。典型的例子是JTAG的IDCODE寄存器。芯片的IDCODE本来是由硬件连线决定的仿真环境里你没法修改综合后的网表但验证不同的软件版本时又需要让IDCODE返回不同的值。这时候直接把IDCODE的输出force成目标值比去改RTL再重编仿真环境快得多。类似的还有OTP熔丝值、芯片版本号、die温度传感器的模拟输出都可以用force来做。第三类是绕过漫长的初始化过程。有些DUT里的子模块上电后需要等几万个周期才能完成校准比如PLL锁定、片内LDO启动。验证某个完全无关的功能点时每次都要等这几万个周期纯粹是浪费时间。把代表“校准完成”的内部状态信号直接force成有效值可以瞬间跳过初始化阶段让验证聚焦到真正要测的功能上。第四类是配合负向测试。比如你想验证总线在“从设备一直不回应”的情况下主设备能不能超时退出与其去构造一个复杂的从设备模型不如直接把dut内部的ready信号force成0逼出超时路径。这种思路在协议验证里特别常用。2.2 这种场景千万别用千万别拿force去“修”bugforce最大的诱惑是当DUT里出现一个bug时有人会忍不住想“诶我把这个信号force一下先让仿真跑过去”。这是绝对的禁区。验证工程师的职责是暴露问题而不是掩盖问题。你用force把一个错误信号强行掰成正确值回归测试的结果看起来漂亮了但RTL的bug还躺在那里流片后一样会在真实场景下爆发。而且这种“修bug”式的force往往不带日志、不带注释、没有CR记录几周之后连你自己都忘了这个force的存在。等后端的人跑网表仿真发现某个信号值对不上查下来才发现是验证环境里留了一个神秘的force语句那时候再排查定位的成本非常高。另外还有两类信号我要特别提醒时钟和复位。对时钟信号做force在功能仿真阶段偶尔有人用比如强制某个时钟关闭来模拟门控行为。但一旦被force的时钟出了问题整个DUT的时间基准全部错乱仿真器行为不可预期。复位信号同理如果你在复位释放之后又force成无效电平DUT内部的异步复位逻辑会在一瞬间集体动作产生一堆真实的、但和测试意图毫无关系的X态传播。我曾经见过一个例子工程师为了“稳定”某个信号把复位force成1结果整个回归测试的失败日志全是X态白白排查了两天。原则很简单能用正常激励构造的场景先用正常激励正常激励代价太高才考虑force而force永远只用于模拟外部无法直接控制的内部状态或者制造真实硬件中可能出现的异常条件永远不能用来让已有bug“消失”。2.3 和assign、deposit的区别别混着用在实操中很多工程师会把force和assign混为一谈这会导致一些非常隐蔽的错误。assign是连续赋值它有自己的驱动源信号的值由右侧表达式持续决定。如果你在testbench里写assign对DUT内部信号直接赋值这等于给信号又加了一个驱动源仿真器会报多驱动警告甚至直接产生X态。force则简洁地覆盖了原有驱动不带多驱动问题。另一个容易混淆的是工具里的deposit操作比如Verilog工具命令或UVM里的uvm_hdl_deposit。deposit更像是“临时改一行代码的值”它改变信号的当前值但不建立持续的强制关系而force是一种持续的压制被force的信号在release之前无论RTL内部怎么驱动它都无效。为了更直观地理解我把几个常用手段的区别列成一个表手段是否有持续压制力是否会产生多驱动释放方式典型用途force有直到release不会值的优先级覆盖release语句模拟内部状态锁定、异常注入assign有持续驱动会多驱动冲突风险用另一个assign或null值撤销一般不用于DUT内部信号deposit无只改当前值不会无需释放等待下次正常赋值寄存器后门设置、临时改值普通驱动器BFM无走正常驱动链无无正常激励生成我在项目里的习惯是凡是涉及DUT内部逻辑、需要模拟异常状态的地方优先force凡是寄存器配置类需求优先走uvm_reg后门或者depositassign几乎不用在DUT内部信号上避免给自己挖多驱动的坑。3. 工程级实操从最简单的force到UVM环境的完整用法3.1 基础写法与路径别栽在层次路径上最基本的force写法非常简单直接给出完整层次路径加一个值就行initial begin force tb_top.dut_u.reg_file.mem[3] 32hdead_beef; // 仿真时间推进 #100ns; release tb_top.dut_u.reg_file.mem[3]; end但这里有几个细节新手非常容易踩。第一个细节是层次路径必须以仿真器实际展开后的顶层为起点。比如你所在testbench的顶层模块名是tb_top但UVM环境里你用的是不同的句柄名字你不能写uvm_test_top.dut_u.xxx因为uvm_test_top结构上并不在DUT的硬件层次路径里。正确做法是找到testbench顶层模块实例名从它往下写。拿不准的话第一件事是在仿真波形窗口里把DUT实例的路径展开看一遍照抄。第二个细节是force语句的层次路径必须是静态的。你不能把路径放在一个task的字符串参数里动态拼出来再传给force语句去执行。SV语言层面的force不支持这种用法。这意味着如果你希望像写脚本一样“传一个路径进去把这个信号force住”你就不能依赖裸的force语句而必须用VPI/UVM提供的方法用字符串路径来操作也就是后面要说的uvm_hdl_force系列函数。第三个细节是不同仿真器对大小写和通配符的处理不完全一致。层次路径里的模块实例名、信号名默认区分大小写路径写错一个字母编译器不一定报错运行时force静默失败的可能性也有。我强烈建议在写force之前先调用路径检查函数确保路径真的存在。3.2 变量与netforce之后release的两种结局这是整个force/release话题里最容易被忽略、也最容易导致误判的知识点。对net类型的信号wire、tri这类执行force语义很直接force期间net的值由force决定release之后net恢复为正常驱动源的值。这个“正常驱动源”可以是连续赋值、门输出或者三态驱动总之是网表/代码里本来就有的那个驱动链。所以对于netrelease的恢复行为基本符合直觉。对variable类型logic、reg这类变量执行force行为就不一样了。按照SystemVerilog标准语义release一个被force的变量时这个变量恢复为在force之前最后一次过程赋值驱动的值如果force之前没有任何过程赋值在驱动它那release之后它就一直保持被force期间的值。这句话翻译成大白话一个有always块或initial块不断赋值的变量release后会回到那个逻辑块最近一次赋的值一个只被声明、没有过程赋值在驱动的变量release之后仍保持你force进去的值。我举个例子logic [7:0] var_a; logic [7:0] var_b; initial begin var_a 8h01; // 这是一个过程赋值var_a被“托管”了 force var_a 8hff; // force期间var_a 8hff #10ns; release var_a; // var_a回到8h01因为上一个过程赋值是它 force var_b 8hff; // force之前var_b从未被过程赋值驱动 #10ns; release var_b; // var_b保持8hff没有旧值可恢复 end这个差异直接影响验证策略。如果你要force一个寄存器变量而它本来就有RTL的always块在赋值release之后就会瞬间回到RTL的驱动值这可能是一个你根本不想要的值。反过来如果force一个悬空变量release之后它不会自己变回去你的“临时注入”变成了“永久注入”后面对这个信号的断言全部受影响。所以每次写force之前先问自己一句我force的到底是net还是variable它有没有被持续赋值想清楚这个release的预期就基本不会错。3.3 与UVM结合uvm_hdl_force、包裹宏与sequence在真实的UVM验证环境里直接用裸的force语句有局限性。主要问题就是前面说的路径动态化。工程上更常见的做法是借助UVM自带的HDL接口这些接口底层走的是仿真器的PLI/VPI能力可以通过字符串路径来操作。UVM里最常用的三个函数是uvm_hdl_check_path(string path) // 检查路径是否存在 uvm_hdl_force(string path, value) // 对路径执行force uvm_hdl_release(string path) // 对路径执行release用法很直接if (!uvm_hdl_check_path(tb_top.dut_u.ctrl_busy)) begin uvm_fatal(FORCE, path not found) end uvm_hdl_force(tb_top.dut_u.ctrl_busy, 1b1); // ... 一段时间后 uvm_hdl_release(tb_top.dut_u.ctrl_busy);用这套接口还有一个好处就是可以封装。我在实际项目里会做两个公用宏保证所有用到force的地方都走同一套检查和报错机制。define FORCE_SIG(path, val) \ begin \ if (!uvm_hdl_check_path(path)) \ uvm_fatal(get_type_name(), $sformatf(FORCE path not found: %s, path)) \ if (!uvm_hdl_force(path, val)) \ uvm_error(get_type_name(), $sformatf(FORCE failed: %s, path)) \ end define RELEASE_SIG(path) \ begin \ if (!uvm_hdl_release(path)) \ uvm_error(get_type_name(), $sformatf(RELEASE failed: %s, path)) \ end有了这套封装在sequence里force信号就变得很干净class idle_force_seq extends uvm_sequence #(uvm_sequence_item); task body(); string path tb_top.dut_u.bus_u.rst_tree.hold_ready; FORCE_SIG(path, 1b0) repeat (20) (posedge vif.clk); RELEASE_SIG(path) // 恢复后再采样确认 (posedge vif.clk); if (vif.ready ! 1b1) uvm_error(get_type_name(), release failed to restore ready) endtask endclass不过要提醒一点把层次路径硬编码在sequence里可维护性并不好。更工程化的做法是把这些需要force的路径集中定义在一个package或者宏文件里至少做到“所有路径不散落在业务代码中”。更进一步可以用一个专门的“force agent”来管理这些注入行为记录哪些信号正在被force、被谁force、force了多久这样后端做形式化验证或者门级仿真时看到这些注释和记录才能快速理解设计意图。4. 时序细节与release的讲究4.1 force生效瞬间的竞争与毛刺force虽然能压住信号但它生效的那一刻仍然要面对事件调度的现实。如果你在一个时钟的上升沿同时执行force而同一时刻DUT的采样逻辑也在采样那么被force的信号到底是新值还是旧值完全取决于仿真器当前处理到哪个region、force的更新是不是已经落到了值存储上。更实际的问题是毛刺和X态传播。想象一个场景某个内部握手信号ready本来被一个timing逻辑驱动为高你在某个异步时刻force它变成低接着在接下来一个时钟边沿又release。release的瞬间如果RTL的旧驱动值恰好也在一个微妙的状态就可能产生半个周期的毛刺。这个毛刺在波形上可能只有一两个仿真步长但足够让后级的组合逻辑产生一次错误翻转。我的习惯是force和release都对齐时钟沿并且尽量选择被测信号本身不参与采样的时刻。比如下面的写法// 等时钟低电平阶段执行force避开上升沿采样窗口 (negedge clk); force dut_u.handshake.ready 1b0; repeat (3) (posedge clk); (negedge clk); release dut_u.handshake.ready;这里选negedge执行force和release是因为大多数DUT的采样逻辑集中在posedge低电平阶段做强制注入被下一个posedge采到的概率更高也更容易保证“第一个被采到的值就是force后的值”。还有一个细节如果force和release在同一个仿真时间点紧挨着执行中间没有延迟那么很多仿真器的行为是不确定的。有的工具会把两次操作合并表现为这个信号从来没变过有的则会先更新一次再更新一次导致采样线能抓到一阵毛刺。所以至少用#0或者一个明确的时钟沿隔开给仿真器一个确定的事件顺序。4.2 多层force叠加时的释放规则这个知识点属于那种“不说不知道一说吓一跳”的坑。SV标准允许同一个信号被连续多次force每次新的force都会覆盖前一个force的效果但所有force都会保留在信号上直到对应层次被释放。当你release其中一层force时信号恢复到的不是原始驱动值而是前一层force的值。举个例子initial begin force dut_u.sample_reg 8h11; // 第一层force #10ns; force dut_u.sample_reg 8h22; // 第二层force #10ns; release dut_u.sample_reg; // 释放第二层 // 此刻sample_reg是8h11不是RTL原始值 #10ns; release dut_u.sample_reg; // 释放第一层 // 此刻才真正回到RTL驱动的值 end这个行为模拟听起来很简单但实际遇到时非常迷惑。很多工程师在调试中写了两次force然后只release一次发现信号“没有恢复原状”第一反应是release写错了其实是因为还有一层force在上面压着。正因为如此我在项目里会强制规定一个信号在同一个测试用例里只能被一个地方force使用前先检查这个信号是否已经在“force管理表”里挂了名字。如果确实需要多次叠加那每次release后都打印当前信号的实际值确认恢复到了哪一层。绝不靠眼睛猜。4.3 release之后的恢复验证工程上我还有一个强制习惯凡是在某个环境里动过forcerelease之后不要马上进入后续流程先加一个采样检查确认信号真的回到了预期值。release dut_u.clk_gen.lock; (posedge clk); if (dut_u.clk_gen.lock ! expected_value) uvm_error(get_type_name(), $sformatf( after release, lock %b, expected %b, dut_u.clk_gen.lock, expected_value));这个检查通常会救你一命。因为release的恢复行为受到net/variable语义、驱动链状态、多层force残留等多重因素影响靠波形观察总是滞后可能等到后面断言失败的时候你已经忘了前面哪个force还在影响当前信号。主动检查会在release后的第一个采样点就暴露问题把定位成本降到最低。5. 常见问题与现场排查实录5.1 问题速查表把我在项目中见过的、身边同事踩过的force/release相关坑整理成一个表方便你直接对照排查。现象可能的根因排查方向force之后信号值没变路径写错实际force到了不存在的信号用uvm_hdl_check_path验证路径看仿真器logrelease之后信号没有恢复force的目标是variable且没有过程赋值在托管检查变量是否有持续赋值必要时手动赋期望值release之后恢复成了另一个force值同一信号被多层force叠加检查所有force点逐一releaseforce期间出现X态信号本身是tri类型且存在多驱动器检查net的驱动链看看是否三态冲突force了寄存器软件读回却是旧值force作用在存储节点寄存器cell内部没有真正改变确认验证意图若想模拟固件配置优先后门写寄存器时钟被force后整个仿真行为错乱时钟信号被强制为常值时间基准破坏立刻停止该用例不要试图继续调试高层环境里force不到底层信号路径没有以testbench顶层为起点用波形窗口复制硬件路径而不是自己手写用task的参数动态写force报错裸force路径必须是静态的改用uvm_hdl_force字符串接口这个表我建议可以贴在自己工位旁边。尤其是第一行和第三行我在不同项目里至少各见过十次——很多人从头到尾没想过路径会静默失败也没想过多层force会“卡住”恢复值。5.2 三个典型案例复盘第一个案例force了变量release后不恢复导致回归失败。当时同事在验证一个低功耗状态机想把某个状态标志位force成0模拟低功耗唤醒时不满足条件的情况。他写的是force到RTL内部的一个logic变量release后还专门在状态机里等了几个周期。结果状态机一直卡在唤醒路径不退出整个用例超时。问题就出在release语义上。那个logic变量在RTL里虽然由一个always块赋值但那个always块的使能条件在force期间恰好被打断所以变量在force之前根本“没有过程赋值在驱动”。release后变量保持force期间的值0状态机自然永远等不到标志位恢复。解决方式也不是换成net而是明确在release后用testbench主动把一个期望值写进去或者用deposit方式代替。第二个案例release半层force信号值“恢复”到上一层而不是原始值。这个案例是在做寄存器异常注入的时候出现的。验证同学想先模拟寄存器被硬件错误改写再模拟软件写回。他先force寄存器为脏值跑一段之后又force了一个新值进去最后release一次就认为恢复原状。结果软件回读时发现寄存器值还是脏值不是复位初始值怎么查都查不到原因。最终还是我帮忙在release前后打印信号值发现第一次force的值还挂在上面才算找到这个多层force陷阱。第三个案例是路径没有以testbench顶层为起点。另一位同事在UVM的scoreboard里直接写force路径用的是自己定义的interface实例名而那个interface实例名和DUT硬件层次里的名字并不对应。仿真器没有报任何编译错误只是在运行时这句话等于什么都没有做。最坑的是那个用例依赖这个force来制造异常条件却一直复现不出来浪费了整整一天。后来加上uvm_hdl_check_path之后第一跑就报了“path not found”。这三个案例的共性是force从来不报错它只会安静地生效或者安静地失效。所以检查路径、检查恢复值、检查force层数这些动作必须变成肌肉记忆而不是指望仿真器帮你发现。6. 最后聊几句实在话我把这一系列关于force和release的经验写完最后想说的其实是一句有点反直觉的话force这个能力越强大就越要克制使用。从技术上说它确实能模拟异常注入、能绕过初始化、能“不讲道理”地控制内部状态这些能力在芯片验证中不可替代。但每次写下一个force之前我都建议你多问自己三个问题这条路劲是不是我确认过的这个信号的force和release语义我是不是真清楚除了force有没有更贴近真实硬件行为的方式我在实际项目里吃过太多亏也见过太多人把force当作“万能胶”。真正专业的验证工程师对待force的态度应该是敬畏多于依赖。它是一把手术刀不是一把锤子。把它用在它该用的地方同时留下清楚的注释、严格的路径检查、规范的release管理这样它的价值才能被完全发挥出来而不是变成回归测试里那些最神秘的失败源。希望这个系列的梳理能让你下次面对force时心里多一分底气少一分试探。