Vivado 报告三阶段检查：方法论 DRC 全解

周五, 28 八月 2026 - 09:24

文章来源：FPGA入门到精通

report_methodology 是 Vivado 里专门检查设计是否符合 UltraFast 设计方法学的 DRC 体系，按设计阶段分为 RTL lint 检查、综合后网表/约束检查、实现后时序检查三档，检查集随阶段自动切换。

它与 report_drc、check_timing 是三个不同维度的闸门：DRC 查「设计对不对」，Methodology 查「方法对不对」，check_timing 查「约束全不全」。

工程模式下实现阶段默认自动运行，所有 Critical Warning 与大部分 Warning 必须解决，否则直接威胁 QoR、时序分析准确性乃至上板硬件稳定性。

report_methodology 是什么?

report_methodology 检查的是「你按 UltraFast 方法学设计了吗」：约束写没写对、RAMB/DSP 流水线加没加、时钟拓扑合不合规、有没有误用异步例外。

这些问题仿真实测不出来，综合也不报错，但会在上板后以偶发故障的形式爆出来。

三命令的分工：

什么时候该想起它，判断很朴素：仿真过了上板崩、QoR 上不去、时序报告越看越不对，先跑一份 methodology 报告，问题往往就列在表里。

有个原因值得说透：仿真验证的是功能正确性，约束问题在仿真里根本不体现。

仿真模型不检查约束，未约束的时钟、缺失的跨域例外、误用的异步例外，仿真照样跑得欢，要等实现后 report_timing_summary 才暴露，那时候定位成本已经翻了几倍。

methodology 报告的价值就是在综合后这个节点，把这类问题提前拦下来。

三阶段检查体系：同一命令，不同检查集

同一个 report_methodology 命令，在不同设计阶段给出不同结论：

检查集随阶段自动切换，AMD 建议每个设计阶段都运行，并在进入下一阶段前把 Critical Warning 与 Warning 解决掉。

工程模式（Project Mode）下，工具默认在 opt_design 或 route_design 期间自动运行 Report Methodology，不用手动触发；

非工程模式（Non-Project）要自己把命令写进 Tcl 流水线。

怎么跑：Tcl 命令与 IDE

Tcl 命令方式（需先打开设计）：

open_checkpoint synth_1/synth.dcp report_methodology -name methodology_1 -file methodology.txt 预期：methodology.txt 生成，按规则族分组列出违例，每条带编号、位置与严重等级（Critical Warning / Warning）。

IDE 方式：Reports > Report Methodology（Project Mode 下也可走 Flow Navigator 的 Implementation 流程）。

运行时机，四个节点必须重跑：

●首次综合完成时

●添加重大模块后

●发生重大约束变更后

●时钟电路（clocking）变更后

常见规则族速查：SYNTH / TIMING / CLKC / PDRC

两个容易误读的点。

一是 SYNTH-6/11/12/13（RAMB/DSP 可选流水线）在相关原语输入/输出路径 setup slack 满足阈值（UG835：-slack_lesser_than 默认 2 ns）时不报告，

性能余量足够时工具自动放过，不用处理。

二是 TIMING 族的 CDC 相关检查（同步时钟间误用异步例外、时钟组缺失），正是 W35 CDC 主题周说的那类约束隐患，methodology 报告是抓它们的工具。

TIMING 族的检查粒度很细，举例：bus skew 无效（多位总线跨时钟域没有正确约束）、OSERDESE3 跨 SLR skew、GT 最小脉宽这类约束正确性问题，都在 TIMING 族覆盖范围。

这类问题在仿真里全是「看起来正常」，却是上板偶发故障的高发区。

违例处理与豁免（waiver）

●AMD 官方 IP 的违例已预先评估核查，报告里直接列出，不用自己排查

●某条违例确实不影响设计，必须明确理解违例含义与影响后才能忽略

●可安全忽略的违例走 waiver 机制豁免，详见 UG906 Design Analysis and Closure Techniques

红线一句话：Critical Warning 必须清零，Warning 大部分需处理，才能保证 QoR 良好、时序分析准确、硬件稳定。

实战：综合后四步检查清单

UG949 第 5 章 Design Implementation 给了综合后四步，直接落地成命令流。

第一步，检查和清理 DRC（默认规则 + 方法论 + 时序三份报告）：

report_drc -name drc_1 -file drc.txt report_methodology -name methodology_1 -file methodology.txt report_timing_summary -name timing_1 -file timing_summary.txt 预期：三份报告都生成。

尽早发现并纠正违规，避免进入实现后爆雷。

第二步，检查综合日志的 Critical Warning：

set_param messaging.defaultLimit 1000 预期：超过 100 次重复的消息只写前 100 条，调大 messaging.defaultLimit 能看全。

确认所有 Critical Warning / Warning 与设计预期一致，重点清理 Critical Warnings。

第三步，检查时序约束：无脏约束，排查「约束未被加载或应用」的 Critical Warning 与 Warning。

第四步，满足综合后时序：

report_timing_summary -max_paths 100 -file synth_timing.txt

预期：综合后 WNS 为负，说明后续实现大概率难收敛，需要回到 RTL 或约束改进，不要带着负 slack 往下推。

排错三例：报告跑出来为空，先确认设计阶段对了（elaborated 阶段跑不出实现后检查）；

工程模式下自动运行的方法论结果，去 Reports 窗口的 Methodology 标签页看，找不到就 open 对应 run 后手动重跑；

Critical Warning 反复出现，先看是不是 waiver 没生效或约束根本没加载，用 check_timing 查约束覆盖。