如果你在跑仿真的时候看到Warning-[INFL_DELTA] Too many events zero delay loop，大概率第一反应是懵的：仿真好像卡死了，log 停在那里一动不动，CPU 却疯狂转圈。别慌，这不是你的 DUT 挂了，而是仿真器发现了一个“时间不走路”的循环。理解这个 warning，你就能顺着线索把卡死的 testbench 或 RTL 逻辑揪出来。
这个 warning 在 Verilog/SystemVerilog 仿真里并不罕见，尤其常见于刚入门写 testbench、或者组合逻辑反馈环没处理好的场景。它背后的核心概念是 delta cycle（增量时间片），搞懂它，你就知道为什么always #0 clk = ~clk;这种写法能瞬间把仿真器逼疯，也知道组合逻辑环路为什么会在 0 时刻无限打转。这篇文章不讲空理论，直接从我实际踩坑的经验出发，把出现的现场、背后的调度机制、典型代码案例和排查修复手段都说清楚。无论是数字前端设计、验证工程师，还是刚开始学仿真的学生，都值得花几分钟看完。
1. 仿真卡死现场：这个Warning到底在抱怨什么
1.1 在真实项目里，这个警告通常长这样
我用过好几家主流仿真器，Cadence 的 Xcelium/Incisive 会明确打出INFL_DELTA这个标识，有些工具则显示成别的文本，但关键词基本就是Too many events和zero delay loop。第一次遇到时，我盯着终端看了半天，仿真进程的 CPU 占用率飙到 100%，但时间戳永远停在0ns或者某个固定的时间点，没有任何前进的迹象。强行 Ctrl+C 中断后，堆栈经常会指向一个看似无辜的always块或者initial块。
印象最深的一次，是我在验证一个 DMA 模块的带宽监控逻辑时，testbench 里用了一行非常随意的写法：
always #0 clk = ~clk;当时只想快速生成一个时钟用于打点，觉得#0无所谓。结果一跑仿真，整个环境就像被按了暂停键，log 最后一行就是Warning-[INFL_DELTA] Too many events zero delay loop。后来检查才发现，#0的延迟并没能让仿真时间前进，时钟在同一个时刻被无限次取反，仿真器被迫在同一时间片里处理无穷无尽的事件，最后只能靠触发这个 warning 来提醒你：代码里存在零延迟死循环。
这个 warning 的作用其实是保护机制。仿真器会设定一个事件数量的阈值，一旦在同一个 delta 周期检测到过多事件被触发，就判断你已经陷入了死循环，于是弹出警告。如果阈值设置合理，工具还会在警告后强制终止该循环或者直接提示你检查代码，防止仿真机被拖到天荒地老。
1.2 不是所有重复事件都是坏事：理解INFL_DELTA的用途
有朋友会问，RTL 仿真中很多信号不就是在反复跳变吗？为什么偏偏这个会被判定为异常。关键在于“零延迟”。正常的时序逻辑和 testbench 激励，一般会带#5、#10这样的延迟，或者等待某个时钟边沿/事件，仿真器每处理完一批事件后，时间都会往前走一点。而零延迟循环的可怕之处在于，它永远停留在一个时间点内反复触发新事件，仿真器根本找不到理由推进时间。
INFL_DELTA中的 DELTA 指的就是 delta cycle。在事件驱动仿真中，同一个仿真时间点内还需要区分多个“增量时间片”，用来处理组合逻辑的级联传播。一个信号发生变化，会触发新一轮的 always/assign 求值，这些求值结果可能又触发另外的信号变化，直到整个组合逻辑稳定下来，仿真器才会推动时间到下一个时间戳。如果这些求值永远无法结束，delta cycle 就会无限增加。仿真器认为这种情况已经超出了合理范围，于是甩出这个 warning。
所以这个 warning 本质上是一道“防火墙”，它替你挡住了一批会让仿真永远跑不完的低级错误。见过它在综合后仿真里折腾你，也见过它在 testbench 里无征兆出现，但只要你理解了零延迟循环的形成机制，排查起来其实非常快。
2. 理解零延迟循环：仿真时间、delta cycle和事件调度
2.1 仿真时间不是“连续河流”，而是一帧帧的画面
很多人初学 Verilog 时，会把#10当成“等待 10 个时间单位”，好像仿真器有一个时钟在背景里滴答走一样。实际上，事件驱动仿真器的工作方式更像电影放映：它并不关心时间本身，只关心每一帧画面里的信号状态。仿真器维护一个事件队列，队列里的事件都带有一个时间戳。每次从队列里取出当前最早的事件进行处理，处理完这个时间点的所有事件后，再跳到下一个时间点。每个“时间点”内部还可以细分为多个 delta cycle，用来保证组合逻辑的传播顺序。
用生活中的类比来解释：你把一叠便利贴按时间顺序贴在墙上，每张便利贴上写着一个待办事项。仿真器的工作就是不断从墙上撕下最早的那张，执行完，再看有没有新便利贴产生。如果执行某个便利贴时，你又立刻写了一张时间戳完全相同的新便利贴，那么仿真器会继续处理它，而这个过程中墙上那个“第 1 分钟”的标签始终没有变。
正常仿真中，这种同时间戳事件是有限的：比如一个组合逻辑 A 变化，触发 B 变化，B 再触发 C，几个 delta 之后稳定，时间就可以往前走了。可如果组合逻辑形成了环路，A 触发 B，B 又触发 A，这种连锁反应就不会停止。于是每个仿真时间点内部的事件数量变成无穷大，INFL_DELTA就来了。
2.2 为什么“#0”会产生无穷事件
先看一段几乎所有 Verilog 学习者都写过或见过的代码：
initial begin clk = 0; forever #0 clk = ~clk; end这段代码的本意可能是“生成一个无延迟时钟”，但仿真器实际执行起来是这样的：
- 时刻 0，
clk被赋值为 0。 - 进入
forever循环，执行#0。 #0表示等待 0 个时间单位，所以仍然停留在当前时间点。clk被取反变成 1。- 因为
clk发生了变化，如果有always @(clk)或@(posedge clk)的语句块，它们也会在同一时刻被触发。 - 执行完这些触发块后，循环又回到
#0，再次取反clk，产生新事件。
时间始终没有前进，但事件数量却不停累加。仿真器只能一遍遍处理这些事件，直到触发INFL_DELTA的保护阈值。你可能会想，既然#0这么坑，为什么仿真器不直接禁止？因为它也有正当用途，比如某些抽象的功能模型需要在同一个时间片内通过 delta 顺序完成建模，所以工具选择用 warning 而不是 error 来提示。
2.3 组合逻辑环路也是“零延迟循环”的常见来源
很多同学误以为只有#0才会导致零延迟循环，其实组合逻辑反馈环同样是最经典的诱因。看下面这段：
wire a, b; assign a = ~b; assign b = ~a;当 a 变成 0，b 就会被赋值为 1；b 变成 1，又会让 a 变成 0；a 变成 0，又会让 b 变成 1……理论上这个过程会在一个无穷小的 delta 周期里无限翻转，仿真时间一步都没动。更隐蔽的情况是 RTL 代码里不小心写出了组合环路，比如：
assign c = en ? ~c : din;当en=1时，输出c的反相信号又被反馈到c的驱动端，同样会在仿真中形成震荡。这类问题在综合时往往会被工具识别为组合环路，但在功能仿真阶段可能先以INFL_DELTA的形式暴露出来。
3. 高频触发场景与真实案例拆解
3.1 时钟生成错误：always #0的典型反例
Testbench 里写时钟生成器，最忌讳的就是把延迟写成 0。很多从 C 语言思维转过来的朋友会认为“越快越好”，于是写出下面的代码：
initial begin clk = 1'b0; forever #0 clk = ~clk; end表面看，这只是让时钟以最快速度翻转，但仿真器会彻底卡死。正确写法很简单，延迟至少给一个正数：
initial begin clk = 1'b0; forever #5 clk = ~clk; end或者用always块：
initial clk = 1'b0; always #5 clk = ~clk;这里的#5不代表“综合成电路后频率是 100MHz”，而是告诉仿真器每隔 5 个时间单位翻转一次时钟。不同 testbench 可以根据 timescale 调整这个数值，比如timescale 1ns/1ps下#5就是 5ns，对应 100MHz 时钟周期。
3.2 少写一个assign驱动方向，导致组合反馈环
之前我帮同事排查过一个很有意思的问题，他写了个简单的握手信号生成器，结果一仿真就报INFL_DELTA。代码逻辑并不复杂：
wire req, ack; assign req = en; assign ack = req & valid; assign ready = ack & en;表面看，req由en驱动，ack由req & valid驱动，ready由ack & en驱动，不存在环路。但问题出在他后来为了调试，临时加了一句：
assign en = ready;这一下，en -> req -> ack -> ready -> en形成了完整的组合环路。仿真时间被卡死在 0ns，所有信号在高阻和不定态之间反复横跳。排查时把最后这行注释掉，仿真立刻正常。这类“调试遗留”问题在实际项目中特别常见，尤其是多个模块信号互相连接的时候，一不小心就会在单向上误加一个反向驱动。
3.3 可综合设计里意外引入的组合环路
如果说 testbench 中零延迟循环是“自己坑自己”，那 RTL 设计里的组合环路就是“坑到整个项目”。比如下面这种带反馈的组合逻辑：
always @(*) begin if (rst) q = 0; else q = en ? ~q : q; end当rst=0且en=1时，q的变化会触发always @(*)重新求值，而q又变成了新的~q，于是再次触发，形成零延迟震荡。这种代码综合时即使能出网表，也会产生组合环路，带来时序收敛困难、毛刺、功耗异常等一系列问题。功能仿真阶段能提前看到INFL_DELTA是好事，说明你在 chip 流片前发现了致命隐患。
需要说明的是，组合环路和时序逻辑中的反馈是两回事。时序逻辑的反馈经过寄存器，有明确的时钟边沿分隔，不会在同一个 delta 内无限循环。组合逻辑的反馈则没有任何“闸门”，信号变化会立刻在组合网络中传播，仿真器只能在事件调度层面判断你是不是死循环了。
3.4 其他容易踩坑的写法：fork/join并行块与零延迟循环的组合
有些人习惯用fork...join写并行激励，比如：
initial begin fork forever #0 data = ~data; #10 $finish; join_none end这段代码本意可能是让data快速翻转，同时用#10限制仿真结束时间。然而，#0翻转会在当前时间点无限产生事件，#10的进程根本没有机会被调度到，因为仿真器永远在处理data翻转产生的事件。即使你写了$finish，也未必能执行到，这取决于仿真器对无限循环与正常事件的调度策略。更稳妥的做法是给翻转加上真实延迟，或者用always #5。
3.5 当仿真器在某个时间点“死机”，不一定是0时刻
虽然大多数零延迟循环发生在 0 时刻，但如果你在仿真中途某个时间点把某个信号拉高，恰好触发了组合环路，也可能在非零时间点卡住。比如在跑复位释放后的初始化配置时，一个用于模式选择的寄存器被写入特定值，开启了某个旁路逻辑，这旁路逻辑内部恰好有组合环路。此时 log 里的INFL_DELTA警告后面会跟着行号和模块名，时间戳停在配置写入后的那个时刻，不会继续前进。
遇到这种情况，不要只盯着 0 时刻排查。先看 warning 出现前最后一次有效操作是什么，再反推哪些信号被更新了，往往能在五分钟内定位到问题。
4. 定位与修复的完整实操指南
4.1 第一步：顺着仿真器给出的行号和模块名查
大多数主流仿真器在报INFL_DELTA时，会附带触发事件所在的文件和行号。你第一件要做的事情，不是去重新审阅全篇代码，而是打开 log，找到Warning-[INFL_DELTA]紧跟着的 source info。比如：
Warning-[INFL_DELTA] Too many events in zero delay loop. File: tb_dma.sv, line = 45那么基本可以确定第 45 行附近存在零延迟触发源。如果工具只给了模块名，也可以直接搜索该模块内所有always、initial、assign语句，重点关注没有延迟控制的反馈路径。
有些时候，warning 指向的位置并不是真正的问题源头。比如它可能会指向一个被反复触发的always @(clk)块，但真正制造循环的是always #0 clk = ~clk;。这时你就要学会“顺藤摸瓜”，不仅看行号，还要看这个位置的信号由谁驱动，驱动这个信号的信号又由谁驱动，直到找到那个不断制造新事件的根因。
4.2 第二步：快速二分定位法
如果 warning 没有提供有效行号，或者指向的语句太多，我有两个常用的定位技巧：
第一个是“注释排除法”。把代码中疑似有问题的零延迟块先注释掉，再跑仿真。如果INFL_DELTA消失，就说明问题出在这段代码。如果仿真卡死依旧，继续二分排除。这个方法虽然笨，但非常高效，尤其是在 testbench 代码量不大的时候。
第二个是“事件计数器法”。在你怀疑会导致循环的always块里加一个计数器，每执行一次就加 1，并打印出来：
integer loop_cnt = 0; always @(*) begin loop_cnt = loop_cnt + 1; if (loop_cnt > 1000) begin $display("ERROR: combinational loop detected at %m, time=%0t", $time); $fatal; end // 原来的逻辑 end这样一旦发生死循环，计数器会迅速超过阈值，并通过$fatal终止仿真，同时打印出具体位置。要注意，loop_cnt如果声明成普通integer，在组合循环里本身也会变成事件传播的一部分，不过用于定位已经足够。你也可以用static变量或者外部全局计数器，避免干扰原逻辑。
4.3 第三步：区分是 testbench 问题还是设计问题
定位到具体代码后，需要判断它属于 testbench 的激励生成问题，还是 RTL 设计里的真实逻辑缺陷。判断标准很简单：如果问题代码只在仿真环境里存在，不参与最终综合，那就是 testbench 问题；如果它能综合成电路，并且信号通路中存在反馈，那就是设计问题。
testbench 问题相对好解决，把零延迟改成有延迟，或者用时钟沿/事件触发替代#0即可。设计问题则需要更谨慎，你需要检查组合逻辑真值表，看看是不是分支条件漏掉了某个状态，导致输出反馈到输入。常见修复手段包括：
- 补全
case的默认分支，避免生成不期望的锁存器。 - 在组合
always块中，把所有输出在所有分支下都显式赋值。 - 禁止在组合逻辑块内读取自身驱动的信号，如果必须反馈，请插入寄存器打一拍。
- 使用 lint 工具做 CDC/组合环路检查，从源头拦截。
4.4 第四步：调整仿真器行为，临时绕过并确认根因
有些时候，你只是需要快速确认“是不是这段代码导致了循环”，不一定要立刻改完重启长回归。这时候可以尝试用仿真器的命令行选项临时控制这个 warning 的严重程度。
各主流仿真器都提供了类似的 severity 控制机制，例如把INFL_DELTA从 warning 提升为 error，或者限制零延迟事件的最大迭代次数。具体选项名因工具而异，建议查看你所用仿真器的 warning 手册。临时绕过的意义在于：你可以让仿真在触发到阈值后立刻停下，而不是一只无响应。这样即使你没有找到根因，至少能拿到一份完整的 wave dump，帮助后续分析。
但请注意，这仅仅是权宜之计。绝对不能靠提高阈值让仿真继续跑下去，因为即使跑下去，仿真时间也不会真正前进，结果没有任何参考意义。我见过有人把迭代上限调大十倍，然后去吃午饭，回来发现仿真还在满负荷运行，纯粹是浪费资源。
4.5 第五步：修复后回归验证
修复完代码，不要只看 warning 消失就认为万事大吉。你需要确认仿真时间能够正常推进到目标结束点，并且关键波形符合预期。尤其是设计问题修复后，最好跑一下相关的定向用例和随机用例，确认没有引入功能回归。
如果是在 testbench 里的时钟生成处踩坑，修复后可以用$time打印几个时间点，确认时钟周期和占空比符合预期。如果是在 RTL 组合逻辑里修环路，建议用门级仿真或者形式验证工具再跑一遍，确保综合以后不会有同样的反馈路径残留。
5. 常见问题与个人经验速查表
5.1 遇到这个warning，但又想先跑通仿真，有哪些应急手段
说句实话，INFL_DELTA并不是一个“警告一下就完事”的问题，它往往意味着仿真已经完全卡死。真想快速绕过，首选是找到触发位置并注释掉可疑逻辑，让仿真先跑一个正常时间；其次才是考虑仿真器选项。一个比较实用的应急方法是，在 testbench 顶层加一个 watchdog 进程：
initial begin #1000; if ($time < 1000) begin $display("ERROR: Time seems stuck at %0t, abort.", $time); $fatal; end end这个进程会在 1000 个时间单位后检查仿真时间是否真的走到了 1000。如果因为零延迟循环卡死在 0 时刻，理论上#1000这行也无法被调度，因为事件队列被无限 delta 事件塞满。但在某些仿真器中，$fatal所在的 initial 块可能会被优先处理，因此可以作为一道保险。不过说实话，最稳妥的手段还是在仿真器层面对事件数量设上限，这比在代码里加 watchdog 更直接。
5.2 组合逻辑环路与“零延迟循环”有什么区别
很多人会把这两个概念混为一谈。严格来说，零延迟循环强调的是“事件在同一个仿真时间点无限迭代”，组合逻辑环路是导致这种情况的常见原因之一，但不是唯一原因。always #0这种写法也算零延迟循环，但它并不存在组合逻辑环路，只是纯粹的激励写法不当。
组合逻辑环路除了能引发INFL_DELTA之外，还可能在门级仿真中表现为 X 态传播。比如两个反相器首尾相接，在没有延迟模型时会出现信号在 0/1 之间无限震荡；加入延迟模型后，可能变成真实的振荡器，导致仿真时间大幅度跳变，但数值结果却毫无意义。因此，如果你同时看到了不定态 X 在波形里闪烁，优先考虑组合环路，而不是#0写法。
5.3 为什么仿真器不直接报error，而是给warning
这其实反映了 EDA 工具的“宁可放过，不可错杀”哲学。在极限编程和抽象建模领域，确实存在一些合法场景需要在零延迟下执行有限次迭代。比如某些纯函数模型用always @(*)做组合化简，虽然理论上可能有中间态的多次跳变，但最终能在有限 delta 内稳定。仿真器无法提前判断一段代码是“有意为之”还是“无意写错”，于是只能设定一个阈值：超过阈值就提示，但允许用户决定是终止还是继续。
理解这一点后，你就知道不要把INFL_DELTA当成一个普通 warning 忽略。它在大多数情况下是硬错误，意味着你的仿真已经在空转。把它提升为 error 是完全没有问题的操作，这能倒逼自己在早期发现零延迟循环，而不是等到跑大规模回归时才发现某个用例卡了一整晚。
5.4 我在实际项目中总结出的三条预防经验
第一条：testbench 里统一封装时钟生成函数，禁止随时随地手写always #0。就算要用变量控制时钟频率，也只在封装好的 task/function 里通过#(half_period)实现，不要在业务代码里直接出现零延迟。
第二条：每次跑回归前，用 lint 工具做一次“组合环路检查”。绝大多数商业 lint 工具都支持查找组合反馈回路，能在仿真前就把问题暴露出来。即使你没有 lint 工具，也可以写一个简单的脚本来扫描always @(*)块和assign语句中的赋值目标/源信号是否有重叠，虽然不如工具精准，但至少能过滤掉低级失误。
第三条：听到“仿真卡死”时，先看 warning 再动手。很多工程师一遇到卡死就直接杀掉进程重启，重启几次后才发现是代码问题。其实仿真器已经明确告诉你INFL_DELTA，顺着这个关键词去查，远比无头苍蝇式重跑高效得多。尤其是大型 SoC 验证环境，一次全量编译可能就要半小时，学会从 warning/error 里提取关键信息，能帮你省下大量时间。
5.5 如果 warning 怎么都消不掉，还可以试试这些方向
有一种比较隐蔽的情况：多个generate块或宏定义展开后，才在某一配置下形成组合环路。你在顶层看到的代码明明很干净，但宏展开之后，某些条件编译的assign组合在一起形成了反馈。这时建议用仿真器的“展开后查看”功能，或者直接在编译选项里加宏定义打印，把预处理后的代码看一遍。还有一种是跨模块信号绑定，比如 interface 内部的modport方向和实际连接不匹配，导致信号被重复驱动，也能引发类似的现象。
如果你已经排查了所有可能的地方，依然复现INFL_DELTA，可以把范围缩小到最小复现用例：剥离无关模块，只保留时钟生成和可疑逻辑，逐步往外扩展。这个方法看起来笨，但我靠它解决了好几个隐藏很深的环路问题。最小复现用例不仅能帮你定位，还可以作为 bug report 附带给仿真器厂商，如果你的工具真的有调度 bug，他们会更愿意处理。
我在实际使用中还有一个体会：不要迷信“只有零延迟代码才会触发这个 warning”。某些 timestamp 极小但非零的延迟，比如#0.001，在超大时间尺度下可能导致仿真器在同一个时间步内处理海量事件，同样会触发类似保护。写 testbench 时尽量用规范的整数延迟，配合合理的timescale，能减少很多莫名其妙的仿真问题。
这个内容后续还可以这样扩展：如果你正在做门级仿真或者 SDF 反标后的仿真，遇到INFL_DELTA时，可以结合时序报告反查是否有组合环穿过标准单元库。对于验证平台开发来说，在搭建早期建立一套统一的时钟/复位生成规范，并且把INFL_DELTA提升为 error，能让你少熬很多夜。希望这篇经验能帮你在下次遇到“仿真卡死”时，更快找到问题，而不是干瞪眼。
