iverilog force/release 行为：reg 与 wire 释放后的区别
更新时间：2026-10-31。本文是开源 EDA 排错系列的 FAQ 速查页，总入口见 开源 EDA 报错排错中心。测试台常用
force把内部信号钉在指定值，再用release结束强制；真正容易看错的是释放之后：变量和线网并不走同一套恢复规则。
本文要回答的问题
force覆盖的是对象的当前值，还是它原来的赋值来源？- 为什么同一个
release后，reg仍是强制值，wire却立即跟随驱动？ - 为什么说
release不是撤销语句，也不会自动恢复强制前的旧值？ - 怎样安排一个最小实验，把释放语义与后续驱动变化分开观察？
一、先记住：force 是持续覆盖，release 只是结束覆盖
iverilog force/release 行为可以分成三个阶段理解。强制期间，普通过程赋值或连续驱动仍然存在，但目标对象对外呈现 force 指定的值；执行 release 后，这个覆盖被移除；接下来读到的值，则由对象是变量还是线网决定。
这张图的关键不是“释放后回到哪里”，而是“释放时谁有权决定当前值”。reg 是变量，释放后没有连续驱动可以接管；wire 是线网，连续赋值一直存在，所以覆盖一撤掉就重新由驱动求值。
最小实验只用一个测试台：r 是 reg，w 是 wire，assign w = driver 给线网提供持续驱动。两者同时被强制为 1，期间把 driver 从 0 改成 1、再改回 0，最后同时释放。
输出中的 step=forced_driver_0 很重要：此时 driver=0，但 wire=1，说明连续赋值的结果仍被强制覆盖。下一行执行释放后，reg=1 wire=0 driver=0，两个对象的差异在同一个仿真时刻直接出现。
二、最小复现：不要在强制期间给 reg 安排新赋值
为了让对照只聚焦释放规则，强制期间只改变 driver，不给 r 写新值。核心代码如下，完整测试台还包含每一步的显示语句。
module tb;
reg r;
reg driver;
wire w;
assign w = driver;
initial begin
r = 1'b0;
driver = 1'b0;
force r = 1'b1;
force w = 1'b1;
#1 driver = 1'b1;
#1 driver = 1'b0;
release r;
release w;
#1 driver = 1'b1;
#1 r = 1'b0;
#1 $finish;
end
endmodule这里的 driver 本身也是 reg，但它没有被强制，所以两次过程赋值都正常生效。w 在强制期间不随它变化，释放后才重新体现当前驱动。r 则一直保留 1，直到最后一条 r = 1'b0。
| 观察阶段 | driver | reg r | wire w | 这一步说明什么 |
|---|---|---|---|---|
| 初始 | 0 | 0 | 0 | 两侧都有确定的普通值 |
| 强制后 | 0 | 1 | 1 | 强制值覆盖两种对象 |
| 强制中改驱动 | 0 | 1 | 1 | 上游变了，被强制线网仍不变 |
| 释放后 | 0 | 1 | 0 | 变量保持，线网恢复驱动 |
| 驱动再置 1 | 1 | 1 | 1 | 已释放线网重新跟随驱动 |
| reg 再赋值 | 1 | 0 | 1 | 下一过程赋值改写变量 |
读表时把“释放后”和“驱动再置 1”分开，才能避免把线网恢复驱动误看成延迟生效。它不是在等待下一个时钟沿，而是在释放后立即回到连续赋值所决定的值。
三、release 后分流：变量保持，线网重算
下面的语义图把同一条释放语句分成两支。蓝色表示释放与类型判断，橙色表示变量侧后续赋值，绿色表示线网恢复并跟随驱动；两条分支都不包含“读取强制前快照”的动作。
这也解释了为什么只看 wire 容易得出“release 会恢复原值”的错觉。本例强制前 w=0，释放后也恰好是 0，但决定这个结果的是当时的 driver=0，不是工具保存了强制前的线网快照。若释放前让 driver=1，释放后的 w 就会是 1。
四、原始输出：release 不是 undo
以下摘录保留同一次运行的仿真输出。step=released 中的 reg=1 直接推翻了“释放会撤销 force”的理解：强制前 r 明明是 0，释放后却没有回到 0。
$ iverilog -g2012 -s tb -o simv tb.v && vvp simv
step=initial reg=0 wire=0 driver=0
step=forced reg=1 wire=1 driver=0
step=forced_driver_1 reg=1 wire=1 driver=1
step=forced_driver_0 reg=1 wire=1 driver=0
step=released reg=1 wire=0 driver=0
step=driver_1 reg=1 wire=1 driver=1
step=reg_reassigned reg=0 wire=1 driver=1
tb.v:35: $finish called at 7000 (1ps)step=driver_1 还补上了另一项证据：r 没有被释放语句隐式改写，仍为 1，而 w 已恢复普通线网行为，随驱动变成 1。到 step=reg_reassigned，新的过程赋值才把 r 改为 0。
| 常见说法 | 是否正确 | 准确表述 |
|---|---|---|
| release 会恢复强制前的值 | 否 | 它只移除强制覆盖，不执行历史值回滚 |
| reg 释放后立刻变 x | 否 | 本例保持强制值，等待后续过程赋值 |
| wire 释放后保持强制值 | 否 | 连续驱动重新决定线网值 |
| release 后必须等时钟沿 | 否 | 本例没有时钟，释放后的差异已直接出现 |
五、在测试台里使用时还要守住三个边界
force/release 适合故障注入、临时替代激励和观察下游响应，不应被当成可综合的硬件赋值写法。它描述的是仿真器对对象的覆盖控制，综合电路里没有与之等价的“撤销覆盖”结构。
调试层次信号时，还要确认强制的是哪个实例路径，并为每一次强制安排明确的释放点。漏掉 release 会让后续测试继续在被覆盖的对象上运行，看起来像 DUT 不响应激励。若多个测试共用同一层次对象，用例结束时应检查是否还有未解除的强制。
本文刻意不在强制期间给 r 安排过程赋值，以免把“强制期间的赋值如何处理”混进释放对照。实际测试台若需要这种写法，应另加针对该场景的用例，不要直接套用本例的时间线。
六、观察结果不一致时，先排除采样和对象路径问题
如果另一份测试台没有复现同样的释放结果，先核对打印时刻。release、连续赋值更新和显示语句可能落在相邻的仿真活动中；在语句后立即读取，与等待一个小的仿真延迟再读取，观察到的事件顺序可能不同。本文每个阶段都保留 #1，目的是让本阶段更新完成后再打印，不是要求释放必须等待 1 ns。
还要核对 force 的目标路径。层次化写法强制的是指定实例中的对象，不会因为其他实例有同名信号就一起生效。释放也应指向同一个对象；只释放测试台顶层的局部变量，不会解除对 DUT 内部信号的强制。
| 异常现象 | 优先核对 | 判别方法 |
|---|---|---|
| wire 释放后看似没变 | 当前驱动是否恰好等于强制值 | 释放前后各改变一次驱动 |
| reg 释放后不是预期旧值 | 是否把 release 当成回滚 | 对照强制前、强制值和释放值 |
| 打印结果像慢一步 | 显示语句与赋值是否同一时刻 | 分阶段延迟采样并标注步骤 |
| 改了一个实例却影响判断 | 强制与释放路径是否一致 | 打印完整层次路径并逐实例检查 |
回归测试不要只检查释放后一行。至少固定四个断言：强制时值被覆盖；强制中改变上游不会改动被强制线网；释放后 reg 保持而 wire 恢复；后续 reg 过程赋值与 wire 驱动变化分别正常生效。这样即使将来调整测试步骤，也不会把“当前值碰巧相同”误判为语义通过。
最后区分仿真时间和真实硬件行为。本文全部步骤在 7 ns 内完成，只是为了把事件分开显示；纳秒数值本身不是 force/release 的延迟参数。把测试台改成 10 ns 或 100 ns 的间隔，释放后的变量与线网分支仍相同。
代码获取
本文测试台与运行脚本已同步公开仓：https://github.com/derekzhuo/geek-doc.cn/tree/main/experiments/ts-iverilog-force-release-behavior。克隆后进入该目录执行 bash run.sh，即可复现 reg 与 wire 在强制、释放及后续赋值阶段的完整对照。
实验环境
- 机器/系统：Mac / macOS（Darwin 25.5.0，x86_64）
- 工具版本：Icarus Verilog version 13.0 (stable) (v13_0)
- 日期：2026-10-31
- 完整命令：
iverilog -g2012 -s tb -o simv tb.v && vvp simv
这一篇在知识体系里的位置
本篇属于开源 EDA 排错簇的“仿真赋值语义”节点，重点解释 iverilog force/release 行为，而不是某个编译错误。声明或驱动对象混淆时，可对照 iverilog implicit wire definition 排错；需要回顾编译与运行链路，可看 iverilog 第一个仿真实录。
总结
iverilog force/release 行为的核心是“覆盖结束后由谁接管”：reg 释放后保持强制值，直到下一次过程赋值；wire 释放后恢复当前连续驱动，并继续随驱动变化。release 不是撤销语法，不会统一恢复强制前的旧值。实测中释放后的 reg=1 wire=0 driver=0，以及随后 reg 再赋值为 0 的两行结果，把这条区别完整固定下来。