极客工场

Appearance

共 3,712 字预计阅读约 12 分钟

CRITICAL WARNING: [Synth 8-3352] multi-driven net 排查：Vivado 多驱动告警速查 ​

更新时间：2026-10-26。本篇属于 FPGA 入门排错线，讲 Vivado 综合阶段最常见也最容易被忽略的一类 CRITICAL WARNING。同一问题在开源 lint 工具侧的表现见 %Warning-MULTIDRIVEN 排查，两边可以对照着读。

首屏答案：[Synth 8-3352] multi-driven net 的意思是同一根网络（net）被两个以上驱动源同时驱动——最典型的是两个 always 块写同一根 reg。仿真器对这种情况往往一声不吭（后写的覆盖先写的），但综合到真实电路时一根物理导线只能有一个驱动者，Vivado 会在 IO 插入之后、网表检查阶段连发两条 CRITICAL WARNING 指认两个 driver pin。修法永远是合并到单一驱动源：把多个写分支收进同一个 always 块里用 if/else 或多路选择器表达。注意一个版本差异：网上大量旧帖把多驱动告警写成 [Synth 8-3331]，而 Vivado 2017.4 的真实报错码是 8-3352，搜资料时两个码都要试。

本文要回答的问题 ​

  • [Synth 8-3352] 告警里 1st driver pin / 2nd driver pin 两行分别指什么？
  • 为什么仿真（behavioral simulation）对这种写法完全不报，综合才炸？
  • 8-3352 和旧帖里的 8-3331 是什么关系？
  • 多驱动有哪几种典型写法，按什么顺序排查收敛最快？
  • 合并 always 块之后，怎么验证网表真的干净了？

一、报错原文与现象 ​

最小复现是一个教科书式的错误：同一根输出 y 被两个不同时钟沿的 always 块各自驱动。

verilog
module md_bad(input wire clk_a, input wire clk_b, input wire a, input wire b, output reg y);
  always @(posedge clk_a) y <= a;
  always @(posedge clk_b) y <= b;   // 同一根 reg，两个 always 块驱动
endmodule

用 Tcl 脚本在批处理模式下跑综合：read_verilog md_bad.v 之后 synth_design -top md_bad -part xc7a35tcpg236-1。综合过程本身一路绿灯——RTL 解析、优化、技术映射全部通过，直到 IO 插入完成后的网表检查（Check Netlist）阶段，两条 CRITICAL WARNING 才冒出来：

Vivado 2017.4 综合实测：reg y 被两个 always 块驱动，网表检查报 8-3352

读这段输出抓三个要点。第一，告警成对出现：1st driver pin 'y_reg__0/Q' 钉在源文件第 2 行，2nd driver pin 'y_reg/Q' 钉在第 3 行——两个驱动源的位置都给了，不用自己满工程搜。这里的 y_reg/Q 是综合后触发器实例的输出引脚，Q 即触发器的数据输出端。第二，告警对象是 y_OBUF 而不是 y 本身：经过 IO 插入后，y 这根内部网络在输出缓冲器（OBUF）一侧汇成了 y_OBUF，两个触发器的输出同时短接到了它上面。第三，紧随其后 Check Netlist 报告里 multi_driven_nets 一项 Status 是 Failed——这才是 Vivado 对多驱动的正式判定，CRITICAL WARNING 只是它的对外通报。

值得留意的是：这次综合最终以 exit=0 收场，Synthesis finished with 0 errors, 2 critical warnings。也就是说 Vivado 不会因为 8-3352 中止流程，它会带着这个结构性错误继续往下走，产出一个两个触发器输出被硬连在一起的网表。这正是它危险的地方——不盯告警窗口的人根本意识不到设计已经坏了。

二、分析与设计：为什么仿真不报，综合才报 ​

很多初学者见到 8-3352 的第一反应是「可我的仿真跑得好好的」。这不矛盾，是两级工具对同一段代码的语义解释不同，把推演过程拆开看：

仿真器是事件驱动的软件模型。两个 always 块就是两个并发进程，clk_a 沿来了进程一给 y 赋 a，clk_b 沿来了进程二给 y 赋 b，后发生的事件覆盖先写的结果，变量 y 在任意时刻只有一个值——仿真世界里「一根信号两个写者」完全合法，只是值取决于调度顺序。

综合器面对的是物理电路。y 是一根真实的导线，always @(posedge clk_a) y <= a 综合出一个 D 触发器，always @(posedge clk_b) y <= b 又综合出另一个 D 触发器，两个触发器的 Q 输出被连到同一根导线上。CMOS 电路里两个输出级对推：一个想输出高电平、一个想输出低电平时，导线上的电平由两边的驱动强度决定，轻则逻辑值错误，重则大电流烧片子。不存在「被两个时钟沿轮流写」的触发器这种器件。

所以根因判断可以浓缩成一句话：仿真允许变量多写者，电路不允许导线多驱动者。Vivado 在 RTL 解析阶段并不拦（语法上两个 always 各自合法），一直走到网表成型、做连接性检查时才确认「这根 net 真的有两个 driver pin」，这就是 8-3352 出现在日志很靠后位置的原因。顺带一提，双时钟驱动同一寄存器还叠加时钟域交叉（CDC）隐患——数据在两个时钟域之间无同步直穿，即使驱动问题修了，时钟归并问题也要单独审视。

两级工具对同一段代码的态度差异，整理成一张对照表方便速查：

维度行为级仿真（如 XSim）Vivado 综合
两个 always 写同一 reg合法，后发生的事件覆盖先写的值综合出两个触发器，输出短接到同一根导线
检查结果不报警，波形看似正常Check Netlist 判 Failed，报 [Synth 8-3352]
出问题的时机永远不（语义上就允许）IO 插入之后、网表检查阶段
流程是否中止正常跑完不中止，exit=0 照样产生坏网表
正确的预防位置不可依赖，仿真通过不代表结构合法综合告警必看，CRITICAL WARNING 入 CI

这张表里最反直觉的是最后一行：很多人习惯把「仿真过了」当成设计就绪的通行证，但仿真器对结构合法性几乎不背书，它只验证你写下的行为在多写者语义下跑出什么值。结构合法性的守门员是综合与 lint 工具，这也是为什么专业流程里 lint（如 Verilator -Wall）和综合告警 review 是不可省略的两道闸。

三、版本差异：8-3352 与 8-3331 ​

搜这个报错时会踩到一个坑：大量旧帖、论坛回答写的是 [Synth 8-3331] 或更老的编号，按精确串 8-3352 去搜反而结果稀少。这是 Vivado 各版本告警编号漂移造成的——Xilinx 在不同年份的版本里调整过 Synth 8-xxxx 系列的编号分配，同一「multi-driven net」问题在新旧版本里挂的码不同。本文所有证据都来自 Vivado 2017.4 实跑，该版本的真实报错码确定为 [Synth 8-3352]。

实际排查时的建议：先按你日志里的精确码搜；搜不到就退而用告警正文关键词 multi-driven net 加 Vivado 搜，编号差异不影响根因与修法——无论挂哪个码，它指的都是同一件结构性错误，修复路径完全一致。

另外注意告警级别本身：8-3352 是 CRITICAL WARNING 而不是 ERROR，Vivado 的告警分级里它低于直接中止流程的错误，但高于普通 WARNING。这个分级的含义是「工具能继续走，但走下去的产物你大概率不能要」。工程实践里应把 CRITICAL WARNING 视同 ERROR 处理——计数为零才允许进入实现（implementation）阶段，否则后面布局布线跑出来的时序、功耗分析全都是建立在坏结构上的空转。

四、多驱动的典型形态与排查流程 ​

8-3352 不是单一错误模式。把「一个网络多个驱动者」按写法归类，三种形态一张卡看全：

multi-driven net 三场景：都是一根信号多个驱动源

读这张卡按「驱动语句出现在哪一层」归位：多 always 是时序逻辑撞车，多 assign 是组合逻辑撞车，第三种形态提醒你先建立正确的预期——不要拿仿真通过当设计无误的证据。三个场景共享同一条根因判断：这根信号的值应该由谁说了算？答案只能有一个。

拿到 8-3352 之后的标准收敛路径如下图，颜色按角色区分：红是告警入口与命中的根因，蓝是排查动作，橙是修复动作，绿是闭环复验，紫是防复发沉淀。

fpga/beginner/ts-vivado-synth-8-3352-multiple-driver.md D2 示意图

读这张图抓住一个分岔：告警本身已经把两处驱动位置都钉出来了，排查量不在「找」，而在「判」——判断两处驱动是一处笔误（改名改漏、复制粘贴残留），还是两处都想往这根信号里写值。前者删改多余那处即可；后者说明设计意图是「条件写入」，那就必须把条件显式写进同一个驱动块。不存在「保留两个驱动块还能修」的路径，也没有「把 CRITICAL WARNING 降级消音」这种正经修法。

五、修复与验证 ​

本例属于「两处都想要」分支：y 要能在两个来源之间选择。正确写法是引入选择信号，把两个写分支收进单一时钟、单一 always 块：

verilog
module md_fixed(input wire clk, input wire sel, input wire a, input wire b, output reg y);
  always @(posedge clk) y <= sel ? a : b;   // 单一时钟域、单一驱动源
endmodule

对修复后的文件跑同一条综合流程，关键证据有三处，全部来自同一份输出：

修复后复验：Check Netlist 通过，资源报告里只剩 1 个触发器 + 1 个 LUT3

第一，Check Netlist 报告里 multi_driven_nets 的 Status 从 Failed 变为 Passed，多驱动判定正式清零；第二，Cell Usage 里触发器（FDRE）从坏版本的 2 个降为 1 个，多出来的选择逻辑综合成一个 LUT3——这正是三输入多路选择器 sel ? a : b 该有的样子，修复前后资源数字本身就是结构变化的证据；第三，结尾 Synthesis finished with 0 errors, 0 critical warnings and 0 warnings，综合干净通过。

还要提醒一句：不要用任何「把告警降级」的手段代替修复。Vivado 允许通过约束或 Tcl 命令调整特定告警的级别，把 CRITICAL WARNING 压成普通 WARNING 甚至静音，但多驱动的物理问题并不会因此消失——两个触发器输出仍然短接在同一根导线上，上板后表现为输出电平异常、功耗偏高，排查起来比一条日志告警贵得多。

合并时顺带做两个审视。一是时钟归并：原写法的 clk_a、clk_b 若本就是同一时钟，合并后只剩一个 clk，CDC 隐患一并消除；若确实是两个时钟，那要改的不只是驱动块，而是整个跨时钟域方案（同步器或握手）。二是语义核对：确认合并后的 if/else 或三元表达式忠实表达了原来的设计意图——「哪个条件说了算」必须有明确答案，不能只是把两段代码机械拼进一个块里。

六、预防清单 ​

  • 一根信号一处驱动：任何 reg/wire 全工程只在一个 always 或一条 assign 里出现左值，写代码时随手自查。
  • 复制粘贴后全文搜信号名：改时钟、改条件前先改信号名再粘，避免两块逻辑撞同一根线。
  • 仿真通过不等于结构合法：仿真对多写者沉默，把综合告警（尤其 CRITICAL WARNING）当作必看项，不要只看 exit code——8-3352 场景下综合照样 exit=0。
  • 跨工具交叉验证： Vivado 之前的快速预检可以用 Verilator 的 -Wall，同一问题在开源 lint 侧的报法见 %Warning-MULTIDRIVEN 排查，两边告警对照着看定位更快。
  • 告警入 CI：把「综合日志出现 CRITICAL WARNING 即判失败」写进构建脚本，让多驱动在提交阶段就被拦下。

落地 CI 那条给一个可直接照抄的做法：综合完成后对日志跑 grep -c "CRITICAL WARNING" vivado.log，非零即让构建脚本以非零码退出。这个检查成本极低，却能把包括 8-3352 在内的整类「流程没炸但结构已坏」的问题挡在提交线外——比依赖人盯告警窗口可靠得多。同理，团队规范里值得加一条：评审 Verilog 改动时，对 diff 里新增 always 块的左值信号做一次全工程搜索，确认它没有在别处被驱动。

实验环境 ​

  • 机器/系统：Windows（64 位）
  • 工具版本：Vivado v2017.4（SW Build 2086221），器件 xc7a35tcpg236-1（WebPACK 免费范围）
  • 日期：2026-10-26
  • 完整命令：vivado -mode batch -source v1_err.tcl（报错复现，Tcl 内容为 read_verilog md_bad.v + synth_design -top md_bad -part xc7a35tcpg236-1）；vivado -mode batch -source v1_fix.tcl（修复后复验，含 report_utilization）

代码获取：完整复现工程（坏/好两版 RTL、两份 Tcl 脚本）在公开仓 https://github.com/derekzhuo/geek-doc.cn/tree/main/experiments/vivado-multi-driver，装好 Vivado 2017.4（或任意 7 系列支持的版本）后按 README 跑 vivado -mode batch -source 两条命令即可复现。

这一篇在知识体系里的位置 ​

本篇是 FPGA 入门排错线中 Vivado 综合告警簇的一员，讲「一根信号多个驱动源」在 Vivado 综合视角下的表现与修法。同一问题在开源 lint 工具侧的视角见 %Warning-MULTIDRIVEN 排查；always 块写法的基础规则（含一块一信号的初衷）见 always 块写法与常见场景；综合推断出意外锁存器这一类相邻坑见 Verilog 锁存器陷阱。

一句话总结 ​

CRITICAL WARNING: [Synth 8-3352] multi-driven net 就是同一根网络被两个以上驱动源驱动，Vivado 2017.4 会把两个 driver pin 的源文件行号都钉给你（旧帖里的 8-3331 是同一问题的旧编号）；仿真不报是因为仿真允许变量多写者、电路不允许导线多驱动者；修法永远是合并到单一驱动源——条件写入收进同一个 always 用 if/else 表达，双时钟驱动还要顺带消除 CDC 隐患；复验的硬标准是 Check Netlist 里 multi_driven_nets 转 Passed、CRITICAL WARNING 清零，而不是只看综合 exit=0。