搞FPGA的兄弟，应该都见过这种场面：综合或实现跑得好好的，突然弹出一条 Timing Loop 的 Critical Warning，尤其是 Vivado 或者 Quartus 里那种带着combinational loop、combinational loop关键词的报告，心里立马“咯噔”一下。更麻烦的是，这类警告不像普通时序违例那样一眼能看懂，而是经常躲在成千上万行综合日志里，不仔细找根本不知道源头在哪。而且 Timing Loop 跟时序违例有本质区别：时序违例顶多是“跑不快”，Timing Loop 是“根本不知道它会在哪个时刻翻车”。一旦设计中真的存在组合环路，轻则 RTL 仿真和实现后仿真结果对不上，重则上板后功能时好时坏，严重的时候甚至会让 FPGA 内部局部形成震荡，功耗和发热直接拉满。
新手听到“死循环”这个词往往会很懵：我写的是硬件语言，项目里也没用while，哪来的循环？其实这个“死循环”不是软件概念，而是数字电路里一条没有任何寄存器打断的组合逻辑反馈路径——信号从某个组合逻辑的输出绕了一圈，又回到了自己的输入。就像一群人围成一圈互相递话，第一个人说完，话传一圈又传回自己耳朵里，没人喊停就永远干转。工具在设计网络里发现这种“话传一圈”的路径，就会报 Timing Loop。
这篇文章我按实战经验把 Timing Loop 的成因、报错特征、定位流程和拆解修复完整讲一遍。不管你是用 Xilinx/AMD 的 Vivado，还是用 Intel/Altera 的 Quartus，排查思路基本相通，只是工具入口和关键词略有差别。文章末尾还会放几个实际踩过的坑和排查习惯，希望能帮你少走一段弯路。
1. 先拆明白：Timing Loop 到底是怎么形成的
1.1 从触发器到“组合环路”的本质区别
先补一个基础认知。FPGA 里的时序逻辑核心是触发器（Flip-Flop，FF），触发器在时钟沿到来时把输入端 D 上的值采样到输出端 Q，之后保持不变，直到下一个时钟沿到来。因为触发器本身有采样-保持的特性，信号每经过一级触发器，就被“锁”住一次，不会在同一个时钟周期里无限穿越。这也是为什么常见的数据通路“组合逻辑 + 寄存器 + 组合逻辑 + 寄存器”能稳定工作：组合逻辑算出结果，寄存器在下一个时钟沿把它抓住，再往后送。
Timing Loop 完全不同。它在组合逻辑网络里形成了一条不经过任何寄存器的反馈路径，典型结构是：一个assign或者组合always块计算出a，然后a又直接或间接参与计算自身。看一个最直白的例子：
assign a = b & (~a);这里的a既是输出，又出现在右侧表达式里。工具一综合就会发现：a的取值取决于“现在的a”，中间没有任何时序单元。如果 b 为 1，这个表达式在理想情况下会变成a = ~a，也就是每个时刻都想翻一次；放到真实晶体管电路里，这就是典型的振荡结构。这类一眼就能看穿的代码，工程里基本不会有人写，真正危险的是“看着没问题、实际绕了一圈”的复杂组合逻辑。
还有一种常见场景是模块互相例化形成“环”。比如模块 A 的输出连到模块 B 的输入，模块 B 的输出又连回模块 A 的输入，中间不存在任何寄存器，这也是一种组合环路。模块越多、信号名越长，这种环就越隐蔽。很多工程师看到报告里一串不认识的内部信号名，直接脸色发白，其实完全没有必要。
1.2 Vivado 和 Quartus 的报错风格与关键词
不同工具对 Timing Loop 的检测阶段和提示方式不一样。Vivado 在综合阶段如果发现组合环路，通常会在综合日志里打出类似：
WARNING: [Synth 8-295] Found a combinatorial loop: '/top/u_alu/inter_result' -> '/top/u_alu/data_out' -> '/top/u_alu/inter_result'部分版本还会出现[Synth 8-6014]这类带 WARNING 级别的提示，并且综合后的时序报告或利用率报告里也会留痕迹。关键问题在于：很多场景下 Vivado 并不会把它升级成 Error，只是给一个 Warning。如果不够仔细，很容易直接忽略，结果跑到实现阶段才发现时序一团乱麻，甚至布局布线失败。
Quartus 的风格更直接，一般在对工程执行 Analysis & Synthesis 之后，会在编译日志或报告窗口打印：
Warning (10036): Combinational loop in design at ... Warning (10038): Combinational loop due to ... Critical Warning: Found combinational loop ...比较稳定的特征是警告编号10036一带。想快速定位，只需要打开 Compilation Report，在“Analysis & Synthesis”下面的 Warninngs 页面里搜索loop或10036就能把相关消息捞出来。另外，Tcl Console 里也会同步输出，直接滚动窗口复制关键词搜索也可以。
关于关键词搜索，我多啰嗦一句：不要只搜大而泛的Warning，那会面对一片汪洋。在 Vivado 日志里搜combinatorial loop，在 Quartus 日志里搜Combinational loop或10036，效率会高很多。真到了图形化界面里，还可以过滤警告类型，把组合环路单独列出来看。
2. 最容易养成 Timing Loop 的几种 Verilog 写法
2.1 敏感列表不全，把“组合逻辑”写出了“迷宫”
绝大多数 Timing Loop 其实不是设计者诚心想做反馈，而是敏感列表写漏了。看这个非常典型的例子：
always @(a or b) begin c = a & b; d = c | din; end这里d的计算依赖c，c依赖a和b，但敏感列表里只写了a和b，把din漏了。仿真时如果din变化，这个 always 块不会重新执行，d也就不更新，仿真波形会出现一段“跟预期不一致的延时”。综合器可不管仿真语义，它会把代码推断成d = (a & b) | din这样的组合网络，这个网络本身没有环路。
但有些情况敏感列表缺失就会演变成环路。看这个变形：
always @(a or b) begin if (sel) y = a; else y = ~y; end输出y出现在赋值号右侧，敏感列表里又没有y。综合器忠于代码语义，会把y = ~y推断成一条从y输出反馈回y输入的组合路径，形成典型 Timing Loop。真实项目里不会有人写这么直白，但等价结构很常见。比如一个读控制逻辑里，读使能由读状态决定，读状态又受到“数据有效”信号的影响，而“数据有效”又来自读状态，几个 always 块一交叉，环就出来了。
我的建议非常直接：新代码一律使用always @(*)，或者直接用 SystemVerilog 的always_comb，让工具自动推导敏感列表，别手写always @(a or b or c)。这个习惯能减少一大半环路诱因。
2.2 组合 always 块里的“隐式保持”
另一种高频踩坑写法是想用组合逻辑保持状态。比如：
reg flag; always @(*) begin if (start) flag = 1'b1; else if (done) flag = 1'b0; end设计者可能想表达：start 时拉高，done 时拉低，其它时候保持原值。问题是，这段代码里flag没有写进敏感列表，也没有“默认赋值”。对于分支不完备的组合 always 块，综合器会生成一个锁存器（latch）来“记住”当前值。一旦生成 latch，flag当前值就会反馈到输入侧，形成latch + 反馈路径的组合，工具自然要报 Timing Loop。
这类问题最迷惑人的地方在于：仿真时功能是对的，因为仿真器会在 latch 的语义下自动保持值；但综合实现后，工具报出来的环路路径往往让你一脸懵。更隐蔽的是，不同仿真器对 latch 的处理会有细微差别，导致 RTL 仿真结果和实际硬件差异很大。
正确的“保持”姿势，是把状态变量写进时钟驱动的时序块：
always @(posedge clk or negedge rst_n) begin if (!rst_n) flag <= 1'b0; else if (start) flag <= 1'b1; else if (done) flag <= 1'b0; end这段代码现在就是一个标准的 D 触发器，flag 的值在每个时钟沿被更新，不存在任何组合反馈路径。修完之后，Timing Loop 自然消失。
2.3 latch 与组合环路：一对难兄难弟
这里把 latch 单独拎出来讲，是因为它和 Timing Loop 经常同时出现，而且产生原理非常相似。latch 的本质是在电平有效时透明、电平无效时保持，保持状态必然需要一条反馈路径。所以只要综合器推断出 latch，工具“发现组合环路”的概率就会明显上升。
比如下面这段代码：
always @(*) begin if (en) q = d; end这个写法就是一个很典型的 latch：当en=1时，q=d；当en=0时，q 保持。工具推断出来的结构里，反馈信号会让综合器在检查环路时给出警告。有些工程师觉得“小 latch 没什么大不了”，但在高速设计中，latch 的时序分析模型比 D 触发器复杂，而且容易成为 hold time 问题的高发区。最稳妥的做法是：设计组合逻辑时保证所有分支都有赋值，或者所有中间变量在 always 块开头先赋默认值：
always @(*) begin q = 1'b0; // 默认赋值，避免隐式 latch if (en) q = d; end这样写，综合器就会把 q 处理成一个带使能的组合选择器，而不是 latch。类似的逻辑也可以用来预防那类由“分支不完备 + 输出反馈”共同导致的 Timing Loop。记住一个原则：工具只是忠实地表达你代码里隐含的电路结构，你给的语义含糊，它就报环路；你把语义写清楚，环路自然消失。
3. 定位 Timing Loop 的实操流程
3.1 第一步：从综合日志里找出嫌疑节点
不管用哪个工具，定位 Timing Loop 的第一步永远是从综合日志里找到“嫌疑节点”，也就是报告里列出的那些信号名。工具报环路时一般都会给出一条路径，比如：
WARNING: [Synth 8-295] Found a combinatorial loop: 'data_out' -> 'mux_sel' -> 'mux_out' -> 'data_out'这条路径里的每个信号都是排查突破口。我实操时通常先把这些信号名全部复制出来，然后回到 RTL 代码里全局搜索。如果能搜到，就顺藤摸瓜找到对应的 always 块或 assign 语句；如果搜不到，大概率是经过综合优化后重命名过的内部网络，这时候就要上图形界面。
这里有一个关键经验：千万别只盯着最后一个信号。路径是环形的，任何一个节点都能作为起点往后追。报告里的顺序只是工具内部遍历的顺序，不代表“源头”在第一个信号。真正要问自己的问题是：这条组合路径里的每个节点，到底是由哪些模块、哪些 always 块产生的？
3.2 第二步：Vivado 里用 Schematic 和 Netlist 交叉定位
Vivado 打开综合后的设计，在左侧 Flow Navigator 点Open Synthesized Design，再选Schematic。这时候可以用工具栏里的Search功能，输入报告的信号名，比如data_out。图形窗口会高亮对应的 LUT、MUX 或引脚。顺着连线看，如果发现某个节点同时接到目标单元的输出和输入端口，那基本就能锁定环路了。
如果 Schematic 里的连线太多，看不过来，可以直接用Netlist视图，按层次结构展开，找到报告里的顶层子模块，再一级一级往里点。我习惯用“报告信号名 + 模块层次”双管齐下：在 Tcl Console 里用get_nets <信号名>或get_pins <信号名>获取精确的对象路径，然后用select_objects选中，再回到 Schematic 里高亮。
一个小技巧：在 Vivado 里对疑似环路的网络执行report_timing -loop，如果工具确认真的存在环路，它会输出这个 loop 的完整路径和涉及的单元数量；如果环路已被综合时的 loop-breaking 措施打断，也能在输出里看到相关提示。这比单纯看 Warning 更直接。
3.3 第三步：Quartus 里用 RTL Viewer 和 Netlist Viewer 定位
Quartus 的定位路径和 Vivado 大同小异。综合通过之后，打开Tools -> Netlist Viewers -> RTL Viewer，可以在图形里看到综合出的 RTL 结构。使用菜单里的查找功能，输入信号名，系统会跳到对应节点。如果 RTL Viewer 里结构太复杂，再换Technology Map Viewer或用Netlist Viewer查看映射后的 LUT 与寄存器结构。
Quartus 图形界面上，组合反馈路径通常表现为一条从某个逻辑单元输出转个弯又回到自身或相邻组合节点输入的网络。由于 Quartus 的绘图方向比较“有曲线感”，第一次看会觉得很晕，建议把无关的层次节点先折叠起来，只保留报告里涉及的模块。
还有一个非常实用的功能：在 Quartus 的编译报告里，点开Analysis & Synthesis -> Warnings，找到对应的10036警告，有些版本会提供“Locations”列，直接列出相关引脚或内部节点名的集合，配合Node Finder使用，能很快定位到具体网络。
3.4 第四步：画出数据流，判断是真环还是误报
拿到信号名和图形路径后，不要急着改代码，先在纸上或者思维里过一遍数据流：这个信号从谁产生，中间经过哪些组合逻辑，最终又影响了谁。画完你会发现很多“环路”其实是设计者有意为之的反馈。数字电路里不是所有反馈都是坏事，比如数字锁相环里的环路滤波器、delta-sigma 调制器里的反馈，甚至状态机的次态逻辑，本质上都含反馈。区别在于：有寄存器打断的反馈是设计意图，没有寄存器打断的纯组合反馈才是问题。
判断方法很简单：沿路径走一遍，看有没有遇到触发器。只要路径里出现任意一个FDRE、FDCE之类的时序单元，这个环就不是 Timing Loop，而是正常的时序反馈。如果整条路径都是 LUT、MUX、或门电路，没有任何时序单元，那工具报的 Timing Loop 就是真问题。
这一步尤其重要，因为综合器的误报和特殊优化也会出现。比如某些工具会把复位网络里的缓冲器结构错误归类为环路，或者把三态缓冲组成的双向路径识别为组合环，这时候不用慌，结合代码逻辑人工判断即可。
4. 拆解与修复：从代码层面打破环路
4.1 直接修法：用寄存器和使能信号打断反馈
确认是真环之后，修复思路就一句话：在反馈路径上插入寄存器，或者用使能信号切断反馈的生效条件。先看一个项目里常见的“产生式环”：
wire flag_vld; wire flag_stall; assign flag_vld = data_rdy & (~flag_stall); assign flag_stall = ~flag_vld & fifo_full; end这两个 assign 构成了环路：flag_vld决定flag_stall，flag_stall又决定flag_vld。如果fifo_full处于某个状态，这条组合路径就会形成一个没有寄存器的循环。仿真可能还能跑，工程上这类代码一上综合就会触发 Timing Loop 警告。
最简单的改法是引入一个寄存器作为“仲裁点”：
reg flag_vld_reg; always @(posedge clk or negedge rst_n) begin if (!rst_n) flag_vld_reg <= 1'b0; else flag_vld_reg <= data_rdy & (~flag_stall); end assign flag_stall = (~flag_vld_reg) & fifo_full;这样flag_stall依赖的已经从flag_vld变成flag_vld_reg，而flag_vld_reg是上一拍的寄存器值，环路被寄存器硬生生打断，Timing Loop 自然消失。代价是逻辑反应慢了一拍，如果系统对响应速度有严格要求，需要跟总体时序一起评估。
4.2 更稳的做法：组合逻辑改时序逻辑
直接插寄存器算是最快的修复方式，但有些场景插一拍会破坏性能或功能时序。更普遍的做法是把原本写在组合 always 块里的反馈逻辑，整体搬进时钟驱动代码块里，用状态机思路重构。
举个例子。假设你原来写了一个调整优先级仲裁器的组合逻辑，某路请求反压之后会立即改变仲裁结果，导致组合逻辑互相牵制。改成时序逻辑后，仲裁结果在时钟边沿更新，反馈路径就变成“寄存器输出 -> 组合逻辑 -> 寄存器输入”，每一拍都重新计算一次，环路解除，电路行为也变得更可控。
从时序收敛角度看，组合反馈最大的问题是“组合路径长度不确定”，工具无法预估它最终会形成多长的逻辑链。把它们变成寄存器间的组合路径后，时序分析器就能算出具体的 setup/hold 约束，后续约束和收敛才有意义。所以遇到 Timing Loop，不要只想着“把警告消掉”，要问一句：这段反馈是不是本来就应该做成时序逻辑？大多数情况下答案是肯定的。
4.3 架构层面的预防：状态机与异步信号的正确使用
修好一个环不难，难的是在后续项目里不再造出新的环。我总结几个架构层面的预防思路，都是血泪教训换来的：
第一，状态机的次态逻辑里不要出现“用输出影响输入”的组合形态。状态寄存器本身的反馈属于正常时序反馈，但次态组合逻辑里，如果某个输出信号在计算过程中又被用于判断当前状态，就很容易形成组合反馈。写作时尽量把“现态”和“次态”分离：现态来自寄存器输出，次态由一个纯组合块计算，输出逻辑只读现态。
第二，异步信号进入 FPGA 后一定要先打两拍同步，不要在组合逻辑里直接用异步信号作为环路判断条件。异步信号经常会出现毛刺，如果又参与反馈逻辑，就会成为“环路上的振荡源”，综合器分析和实现都会变得很不稳定。
第三，默认赋值要养成习惯。写过组合 always 块之后，检查一遍所有分支是否覆盖完整。见到一段分支不完整的组合逻辑，第一反应就要问：工具会不会在这里生成 latch？这个 latch 会不会形成反馈？如果会，尽早改造，别等问题堆积到综合阶段再排查。
第四，认真对待工具里“loop breaking” 相关选项。Vivado 综合时默认会尝试打断环路，Quartus 的优化设置里也有类似机制，但这是“后补手段”，能救急不治本。一旦这些优化介入，某些 RTL 语义可能被改变，导致仿真与实现不一致。更稳的还是让 RTL 本身就不含组合环。
5. 常见问题与排查技巧实录
5.1 那些容易被误判为 Timing Loop 的情况
实际项目里我遇到过好几次“工具报了 Timing Loop，但代码看着完全没问题”的情况。检查之后发现，一半是真有隐蔽环路，一半是下面这些特殊情况：
第一种是仿真模型的内部行为。有些 IP 核或仿真模型里故意包含模拟反馈结构，用于建模模拟行为，比如 PLL 的锁定模型、ADC 的采样仿真模型。这些模型在综合时可能被直接透传，工具基于网表分析时会误认为存在组合环。遇到这种情况，先看报告路径是否指向 IP 核内部，再决定是否需要用综合属性去豁免。
第二种是总线中常见的 mux 回环。代码层面是两个多路选择器互相选，比如：
assign out_a = sel ? in_a : out_b; assign out_b = sel ? out_a : in_b;数据流上确实形成了交叉选择路径，但只要 sel 的取值在时序上受控，实际电路里不会无限振荡。不过综合器不关心“受控不变”，它只要看到结构上的反馈就报环路。这种场景建议直接按真环处理，把交叉 mux 改成寄存器版本或优先级明确的 if-else，免得后期实现炸雷。
第三种是 VHDL/Verilog 混合工程中的类型转换桥接。两种语言之间通过端口连接时，综合工具偶尔会把转换逻辑包装成一个额外的组合层，如果两个模块之间也有反馈，报告路径上会出现一堆bas、to_unsigned之类的自动生成网络名，看着吓人，本质还是同一个反馈环。
5.2 一次真实的 Timing Loop 排查实战
之前排查过一个带外同步采样功能的数据采集模块。现象是 Vivado 综合只给 Warning，但实现阶段时序报告差得离谱，关键路径上的组合延迟达到几十纳秒，怎么约束都收不拢。我打开综合日志，发现一条比较长的组合环路报告，涉及信号sample_en、fifo_wr、fifo_full、overflow_flag，中间穿过大概五六个模块。
按照第三节的流程，我先在 RTL 里搜索这几个信号。sample_en在顶层被拉到采集模块，fifo_wr由采样状态机产生，fifo_full是 FIFO IP 的输出。从 RTL 上看，每个模块单独看都是正常的。但把它们连起来：采样状态机里的写使能fifo_wr同时又是 FIFO 的写请求；当 FIFO 满了，fifo_full会反馈到状态机，让状态机暂停；暂停逻辑里又包含对fifo_wr的组合判断。结果就是fifo_wr通过状态机组合逻辑又影响到了fifo_full的判定，形成一条跨模块的大型组合环。
我最后做的修复是：在 FIFO 写使能和状态机之间插入一拍 FIFO 写有效寄存器，同时把 FIFO 满判断放在寄存器输出之后，彻底切断从fifo_wr到fifo_full再到fifo_wr的组合回环。改动前后功能仿真波形完全一致，但实现时序从最初的无法收敛变成全路径几步，问题直接解决。
这件事给我最大的启发是：Timing Loop 跨模块时最隐蔽，因为每个模块单独看都干干净净。排查时一定要把报告里的路径信号串联起来，看它们之间的全局关系，而不是困在单个模块的局部逻辑里。
5.3 几个我踩过坑后总结的排查习惯
最后分享几个固定动作，每次遇到 Timing Loop 我基本都会照做。
习惯一：把综合日志里的Warning (10036)或[Synth 8-295]当成一等公民处理。我现在的习惯是，只要综合报告里出现组合环路警告，不彻底解决不进入下一步。以前的惨痛教训是：带着这个 Warning 往下走，实现阶段的时序问题越发越乱，最后回头发现根源就是这个环。
习惯二：保留一个只含最小复现工程的“隔离环境”。如果环路出现在一个大工程中，不要在主工程里反复试错，把涉及环路的模块单独抽出来，做一个几行代码的顶层包起来，专门在这个小工程里反复综合、修改。小工程综合速度快，日志也干净，定位效率提高不只一点。
习惯三：版本管理代码时，把日志和报告一起提交。Timing Loop 的警告在不同版本工具里可能不出现、可能换个说法。我实际遇到过同一个代码在 Quartus 18.1 报10036，在 Quartus 20.1 却不报，但实现后行为异常。所以每次编译后的日志、报告都留档，方便后面追溯“这个警告到底是什么时候冒出来的”。
习惯四：遇到不确定的环路，先用report_timing -loop（Vivado）或 Quartus 里的时序报告验一遍。工具说“有环”不等于代码一定写错了，但工具说“没环”也不能保证实现一定稳。用报告结合 RTL Review，比单凭肉眼检查代码靠谱得多。
习惯五：改完代码后不要只跑综合，一定要跑一遍完整仿真，重点是验证功能时序跟修改前是否一致。插寄存器或改时序逻辑虽然解决了环路，但也有可能改变原本的时序响应。只有仿真和实现结果都对得上，这次修复才算真正完成。
搞了这么多年 FPGA，我最大的体会是：Timing Loop 并不可怕，可怕的是对它放任不管。它不像语法错误那样会当场阻止编译，而是像一颗埋在系统里的“定时炸弹”，可能是上板后的某个随机功能失效，也可能是你以为功能正常但时序收敛不了。只要按照“先搜日志、再导图形、画数据流、拆反馈路径”的流程走一遍，绝大多数组合环路都能在一个下午内定位清楚并修复干净。以后再遇到Timing Loop这几个字，就别慌了，稳住，按流程来就行。
