极客工场

Appearance

共 2,097 字预计阅读约 7 分钟

Vivado 偶发不确定失败：结果时好时坏速查 ​

更新时间：2026-10-25。FAQ 速查页，属于 FPGA 工具排错系列。Vivado 最让人心态崩的一类问题是「不确定」：同一套 RTL、同一套约束，昨天时序收敛今天 WNS 变负；仿真跑十次挂一次，挂的那次还没留波形。这类问题九成不是玄学，而是随机种子、竞争冒险、未初始化状态、多线程调度差异中的一条在起作用。跨工具同类问题可对照 Quartus 偶发不确定失败 与 nextpnr 偶发不确定失败，约束背景见 时序约束基础。

本文要回答的问题 ​

  • Vivado 哪些环节自带随机性，怎么把种子固定下来？
  • 仿真「十次挂一次」最常见的 RTL 根因是什么？
  • 实现结果每次不同，是工具 bug 还是设计问题，怎么判别？
  • 换台机器结果就变了，怎么对齐环境差异？

一、报错原文与现象 ​

偶发失败通常没有统一报错，而是这类「不稳定」的信号：

text
CRITICAL WARNING: [Timing 38-282] The design failed to meet the timing requirements.
WNS = -0.214 ns (run 3) ; WNS = 0.031 ns (run 4)   -- 同一网表两次实现结果不同
ERROR: [VRFC 10-2987] 'u_core' is not compiled in library 'xil_defaultlib'
# 仿真侧：assertion fired at 1,372,410 ns，但只在第 7 次回归时出现

核心特征一句话：输入不变、输出漂移。综合实现侧的漂移表现为时序余量在零附近来回翻；仿真侧的漂移表现为失败时间点随机、重跑即消失。先把这两类分开，后面的路完全不同。

二、可能原因总览 ​

报错/现象可能原因处置
两次实现时序结果不同布局布线初始种子不同固定 -directive，多轮 sweep 找稳定配方
多线程实现结果与单线程不同多线程调度引入的确定性差异排查期 set_param general.maxThreads 1
仿真十次挂一次零延时竞争（同一时刻多个块读写同一信号）时序逻辑统一非阻塞赋值，查组合环
上电后偶发功能错误寄存器未初始化/复位不全补齐复位或初始值，查 X 传播
换机器结果漂移工具版本补丁、器件 speed file 差异记录版本与器件库摘要，对齐环境
夜间回归才挂负载/温度导致时序临界路径翻转看失败是否集中在 WNS≈0 的临界设计
增量编译偶发不收敛增量参考检查点与新改动不兼容失败时回退全量编译对照

三、逐条排查展开 ​

把随机种子先固定，把「偶发」变「必现」。 排查一切不确定问题的第一步是消灭变量。Vivado 实现流程的随机性入口是布局布线的初始状态，同一网表换 -directive 或换运行次序，落点就会变。排查期用同一脚本、同一 directive 连跑三次：

tcl
place_design -directive Explore
route_design -directive Explore
# 或者干脆做一次种子扫描，看结果的散布面
foreach s {1 2 3 4 5} {
  opt_design; place_design -directive ExtraNetDelay_high
  phys_opt_design; route_design -directive AggressiveExplore
  report_timing_summary -file timing_seed_$s.rpt
}

如果五次 sweep 里四次收敛一次不收敛，且 WNS 都在 ±0.1ns 附近打转，说明设计本身就在时序悬崖边上——这是设计问题，不是工具问题，该做的是修路径（加流水、放松多周期约束），而不是继续掷骰子。

排查期把多线程降到 1，排除调度差异。 Vivado 默认最多用 8 线程，多线程下部分算法的中间顺序与单线程不完全一致，结果会有微小差别。为了确认你看到的现象不是线程数引起的：

tcl
set_param general.maxThreads 1

单线程下连续两次结果完全一致，再逐步加回线程确认差异来源。注意这只用于排查，生产回归不值得为这点确定性牺牲几倍的运行时间。

仿真偶发挂，先怀疑零延时竞争。 RTL 仿真里「十次挂一次」的最经典根因：两个 always 块在同一仿真时刻一个读、一个写同一信号，谁先执行取决于调度器，而调度顺序会被任何无关改动（加一行 display、换个编译顺序）扰动。自查三件套：时序逻辑一律用非阻塞赋值 <=；组合逻辑一律用阻塞赋值 =；绝不在两个过程块里驱动同一变量。testbench 侧时钟与激励的驱动错开沿口（比如在时钟下降沿驱动激励），能消掉一大类 DUT 与 TB 之间的竞争。仿真方法背景见 testbench 仿真入门。

未初始化状态是上电偶发失败的温床。 FPGA 配置完成后触发器有确定的初始值，但 Block RAM、移位寄存器、以及仿真里的 X 传播行为未必如你所想。现象是「冷启动偶发不对，复位一次就好」——这几乎就是复位覆盖不全的签名。把复位树查一遍：哪些寄存器没有被任何复位覆盖、异步复位是否做了同步释放。仿真里打开 X 传播检查，凡是 X 漏进控制逻辑的路径都要补。

换机器才出现的漂移，先对版本摘要对设计。 Vivado 同一版本不同补丁（2017.4 与 2017.4.1）的布局布线算法有细微差别，器件 speed file 也可能更新。出问题时先收集两份环境的「指纹」对照：

text
version                          # Tcl 里查工具版本
report_property [get_parts]      # 器件库信息

版本、补丁、器件型号、speed grade 四项有一项不同，结果漂移就不算异常。团队纪律：回归结果必须连同这四项指纹一起归档，否则「在我机器上是好的」永远扯不清。

四、排查流程图 ​

fpga/intermediate/ts-vivado-flaky-nondeterministic.md D2 示意图

读这张图抓住一个原则：偶发问题的所有出路都从「先固化」开始——种子、线程数、环境指纹全部固定后仍复现的，才是真问题；固定后不复现的，说明你一直在和一个随机数搏斗。红色是入口现象，蓝色是排查动作，绿色是固化成功的判定点，橙色是修复动作，紫色是收尾沉淀。

五、预防与纪律 ​

  • 回归记录四件套：工具版本、补丁号、器件 part、实现 directive，随每次结果一起归档。
  • 时序设计留余量：目标 WNS 不要贴着 0 走，留出 0.2ns 以上余量，临界设计必然偶发。
  • RTL 编码纪律：时序块只写非阻塞、组合块只写阻塞、一个信号只被一个块驱动，评审时逐条查。
  • 复位全覆盖：上电后所有控制状态机必须经过复位，仿真开 X 检查兜底。
  • 种子 sweep 常态化：关键设计每次大改动后跑一轮 5 种子扫描，看散布面而不是看单次结果。

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

本篇是 FPGA 排错速查簇中「不确定性与随机性」节点的 Vivado 页：与 Quartus 偶发不确定失败、nextpnr 偶发不确定失败 互为跨工具对照；偶发失败的常见下游表现是时序不收敛，约束侧背景见 时序约束基础 与 XDC 约束入门，系列总览见 FPGA 知识版图。

一句话总结 ​

Vivado 偶发不确定失败的第一原则是先把随机性全部钉死：固定实现 directive、排查期单线程、记录版本与器件指纹，让「时好时坏」变成「稳定复现」；仿真偶发挂优先查零延时竞争（时序非阻塞、组合阻塞、单一驱动源）与复位覆盖不全，实现结果漂移优先看设计是否压在时序悬崖上并做多种子 sweep 看散布面；最后把种子与环境指纹随回归结果归档，偶发问题才有被真正闭环的一天。