Vivado升级后，老工程时序崩
一个老工程，旧版Vivado里时序全绿，板子跑得稳稳当当。升级新版后一点Implementation——满屏红色，WNS直接掉到-0.5ns，TNS好几十个纳秒。
这问题比想象中普遍。AMD论坛里从2019.2升到2023.1的、从2024.2升到2025.1的都有人发帖，有人500多个端点全violating。
时序翻车的根本原因
代码没动，约束没动，但工具内部的算法换了。具体来说有三类变化最容易触发问题。
综合策略变了。新版引擎对逻辑映射和寄存器重定时（retiming）的处理不同。2023.1引入了no_retiming属性，老版本没有，同样的代码综合出来网表结构可能差很远。
布局算法变了。这是最常见的翻车点。新版place_design的timing-driven策略做出不同的布局决策，单元位置变了，走线延迟跟着变。有用户工程在综合阶段WNS还是正的，一到placement就掉成负值。
IP核时序模型变了。典型案例：2024.2升到2025.1，CPM模块PCIe路径出现510个端点违例——新版IP的XDC文件里多了一行set_case_analysis约束，老版本根本没有。
怎么解决
别直接暴力升级。不要用新版打开旧工程然后全量重跑。在新版里建空工程，手动导入源文件和约束，避免IP自动升级带来的隐患。
对比时序报告。升级前在老版本跑一次report_timing_summary保存下来，升级后再跑一次。两份报告一对比，哪些路径是新增违例一目了然。
IP升级要谨慎。Block Design里IP提示upgrade时别急着全升，先查Release Notes看时序相关改动，升级后检查约束文件有没有新增或变更。
换Implementation Strategy。Performance_Explore、Performance_BRAM、AreaOptimized都试试。有时候换个策略，布局器走完全不同的优化路径，时序直接过了。AMD官方回复这类问题，第一反应也是建议切换strategy。
高扇出信号要关注。全局复位、使能这类高扇出信号在新版中可能触发不同的优化行为。用(* MAX_FANOUT = 50 *)属性引导工具复制寄存器，或者用BUFG驱动，减少单点负载过大的时序风险。
⚠ 时序违例不代表设计有问题，很可能是工具行为变化的"假翻车"。先确认违例路径是否真的有功能影响，再决定修代码还是调约束。板上跑着没问题的逻辑和工具报的违例，要分开看。
升级前检查清单
老版本备份时序报告（WNS、TNS、违例路径列表）
新版新建空工程，手动导入源文件和约束
IP逐个升级，每个都查Release Notes
综合后对比WNS，placement后再对比一次
切换2-3种Implementation Strategy试跑
检查XDC文件有无新增约束或冲突
升级是好事，但"升了就完事"的心态要不得。花半小时做对比验证，比花三天排查时序违例划算得多。
参考来源：
· AMD Adaptive Support: Vivado 2025.1 Versal Prime PCIe Timing Issue
· AMD Adaptive Support: Moving Project to Vivado 2023.1 Timing Failed
· CSDN: Vivado综合实现报错全攻略（2026-07-03）
· 21ic电子网: Vivado时序约束实战（2026-06-21）