前言很多 FPGA 新人在 Vivado 里第一次看到timing failed第一反应是代码是不是写错了为什么综合、实现都跑完了最后还说 failedWNS、TNS、slack 这些数字到底要看哪一个这篇文章不讲虚的只讲新人真正需要看懂的东西。本文主要解决 4 个问题timing failed 到底是什么意思slack 是什么WNS、TNS、WHS、THS 分别怎么看看到 timing failed 以后应该按什么顺序排查文章适合 FPGA 应届生、研二研三学生、入行 1 年以内的新人工程师阅读。1. timing failed 不是语法错误而是时序不满足Vivado 里常见的几个阶段是RTL 编写 ↓ Synthesis 综合 ↓ Implementation 实现 ├─ opt_design ├─ place_design ├─ phys_opt_design └─ route_design ↓ Generate Bitstream语法错误一般在综合前后就会暴露。而timing failed通常发生在实现之后意思不是“Verilog 语法错了”而是按照你设置的时钟频率和约束条件Vivado 认为某些信号路径来不及稳定或者稳定得太早不能可靠工作。简单说功能仿真通过 ≠ 上板一定稳定 综合通过 ≠ 时序一定满足 bitstream 能生成 ≠ 设计一定可靠FPGA 不是只看逻辑对不对还要看信号能不能在规定时间内到达。2. 先记住一句话slack 是“余量”看时序报告最核心的词就是slack。可以先把 slack 理解成slack 时序余量如果 slack 是正数说明还有余量。如果 slack 是 0说明刚好卡边。如果 slack 是负数说明已经违反时序。例如slack 0.350 ns表示这条路径还有 0.350 ns 的余量。slack -0.120 ns表示这条路径慢了 0.120 ns或者说少了 0.120 ns 的时间。对于新人来说先记住这个判断slack 0时序通过 slack 0时序失败3. setup slack数据来得太晚会失败FPGA 里最常见的是寄存器到寄存器的路径寄存器 A --- 组合逻辑 --- 寄存器 B寄存器 A 在一个时钟边沿把数据打出去。数据经过组合逻辑和布线最后到达寄存器 B。寄存器 B 要在下一个有效时钟边沿采样这个数据。问题是数据必须在寄存器 B 采样之前提前稳定好。这就是 setup 要求。如果数据来得太晚寄存器 B 采样时数据还没稳定就会 setup violation。setup 分析可以简单理解成setup slack 要求到达时间 - 实际到达时间举个例子要求数据最晚 10.000 ns 到 实际数据 9.300 ns 到 slack 10.000 - 9.300 0.700 ns这条路径通过还有 0.700 ns 余量。再看一个失败的例子要求数据最晚 10.000 ns 到 实际数据 10.250 ns 到 slack 10.000 - 10.250 -0.250 ns这条路径失败慢了 0.250 ns。所以 setup 失败本质上通常是数据路径太慢 组合逻辑太长 布线延迟太大 时钟频率太高4. hold slack数据变得太早也会失败很多新人只关心 setup不关心 hold。这是不对的。setup 是怕数据来得太晚。hold 是怕数据变得太早。寄存器 B 在某个时钟边沿采样数据后数据不能立刻变化必须继续稳定一小段时间。这就是 hold 要求。hold 分析可以简单理解成hold slack 实际到达时间 - 要求保持时间如果 hold slack 是负数说明数据变化太早破坏了寄存器的保持时间。setup 和 hold 的区别可以这样记setup怕数据来晚 hold 怕数据变早在工程里setup 失败通常需要你改 RTL、加流水、优化结构。hold 失败很多时候由工具在布局布线阶段自动修但如果最终还有 hold violation就要认真检查约束、跨时钟路径、IO 约束和不合理的时钟关系。5. WNS 是什么WNS 全称是Worst Negative Slack直白翻译最差的一条负 slack也可以理解成Vivado 在所有 setup/recovery 相关路径里找到最差的那条路径它的 slack 就是 WNS。例如 timing summary 里看到WNS -0.238 ns意思是最差的 setup 路径差了 0.238 ns如果看到WNS 0.120 ns意思是最差的 setup 路径也还有 0.120 ns 余量注意一点WNS 只代表最差那条路径不代表所有路径的情况。所以 WNS 很重要但不能只看 WNS。6. TNS 是什么TNS 全称是Total Negative Slack直白理解总的负 slack更工程化一点说TNS 反映的是 setup 违例的整体严重程度。举例WNS -0.500 ns TNS -0.500 ns Failing Endpoints 1这通常说明只有一个 endpoint 失败而且最差就是这一个。再看另一个例子WNS -0.050 ns TNS -20.000 ns Failing Endpoints 800这时候虽然 WNS 只差 0.050 ns看起来不大但失败的 endpoint 很多整体问题很严重。所以看 setup timing 不能只看 WNS也要看 TNS 和 failing endpoints。可以这样判断WNS 很负最差路径很严重 TNS 很负失败路径很多整体收敛差 Failing Endpoints 多影响范围大7. WHS 和 THS 是什么WNS、TNS 主要看 setup/recovery。hold 相关要看WHSWorst Hold Slack THSTotal Hold Slack可以类比理解WNS最差 setup slack TNS总 setup 负 slack WHS最差 hold slack THS总 hold 负 slack如果看到WHS -0.080 ns THS -1.200 ns说明存在 hold violation。hold violation 不要随便在 RTL 里加 LUT、加反相器、加一堆无意义逻辑去“凑延迟”。这种写法很危险换个器件、换个版本、换次布局布线就可能失效。更合理的做法是先检查约束是否正确 再检查是否有错误的跨时钟路径 再看是否有不合理的 generated clock / false path / multicycle path 最后再结合实现结果分析8. Vivado timing summary 应该怎么看很多新人打开 timing summary一堆表格不知道从哪里看。建议按这个顺序1. 先看 Check Timing 2. 再看 Design Timing Summary 3. 再看 Intra-Clock Paths 4. 再看 Inter-Clock Paths 5. 最后点进具体 timing path9. 第一步先看 Check Timing在看 WNS/TNS 之前建议先看Check Timing。原因很简单如果约束本身不完整WNS/TNS 的参考价值就会下降。Check Timing 里常见问题包括no_clock unconstrained endpoint missing generated clock input/output delay 缺失 clock relationship 不清楚尤其是no_clock和unconstrained endpoint新人一定要重视。如果某些路径没有被时钟约束覆盖Vivado 可能根本没有正确分析这些路径。这时候你看到的 timing pass 可能是假象。也就是说timing met 但存在大量 unconstrained path不代表设计真的安全。工程里要先保证该约束的时钟都约束了 该约束的 IO delay 都约束了 该声明的异步路径正确声明了 不该 false path 的路径不要乱 false path10. 第二步看 Design Timing SummaryDesign Timing Summary 通常会有类似信息WNS(ns) TNS(ns) Failing Endpoints -0.238 -12.560 143 WHS(ns) THS(ns) Failing Endpoints 0.045 0.000 0这段信息可以这样读WNS -0.238说明 setup 最差路径差 0.238 ns。TNS -12.560说明 setup 失败不是一个孤立点整体累计负 slack 比较多。Failing Endpoints 143说明有 143 个 endpoint 存在 setup 违例。WHS 0.045说明 hold 最差路径还有 0.045 ns 余量。THS 0.000说明没有 hold 负 slack。这时候结论就是setup failed hold passed接下来应该优先分析 setup 路径。11. 第三步看 Intra-Clock 和 Inter-ClockVivado 的 timing summary 通常会把路径分成Intra-Clock Paths同一个时钟域内的路径 Inter-Clock Paths不同时钟之间的路径11.1 Intra-Clock 失败如果是 Intra-Clock 路径失败常见原因是组合逻辑太深 一个周期内做的事情太多 模块层级之间没有打拍 大 fanout 信号拖慢 DSP/BRAM 使用方式不合理 布线太远解决方向通常是加流水线 拆组合逻辑 减少一个周期内的计算量 关键控制信号打一拍 降低 fanout 让 DSP/BRAM 输出寄存 必要时做 floorplan11.2 Inter-Clock 失败如果是 Inter-Clock 路径失败要更小心。先问一个问题这两个时钟到底是不是同步关系如果两个时钟同源、频率有明确关系可能应该正常做时序分析。如果两个时钟异步就不能直接当普通同步路径处理。异步跨时钟需要 CDC 设计例如单 bit 控制信号两级同步器 多 bit 数据异步 FIFO 握手信号req/ack 结构 脉冲信号脉冲同步或 toggle 同步同时还要配合正确的 timing exception。但是不要看到跨时钟失败就直接写set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]这很危险。set_false_path的意思不是“帮我修好跨时钟”而是“这条路径不需要做常规时序分析”。如果你的 CDC 结构本身是错的false path 只会把问题藏起来。12. 第四步点进具体 timing path只看 WNS/TNS 不够真正定位问题要点进最差路径。一条 timing path 里重点看这些字段Startpoint Endpoint Path Group Path Type Requirement Data Path Delay Logic Levels Clock Path Skew Clock Uncertainty Slack下面逐个解释。13. Startpoint 和 EndpointStartpoint 是数据从哪里出发。Endpoint 是数据到哪里被采样。常见形式Startpoint: u_a/reg_data_reg[3]/C Endpoint : u_b/reg_sum_reg[3]/D这说明数据从u_a里的某个寄存器出来最后到u_b里的某个寄存器 D 端。新人排查时先根据 startpoint 和 endpoint 找到对应 RTL。你要搞清楚这条路径属于哪个模块 这条路径完成什么功能 这条路径是不是必须一个周期完成 中间有没有很长的组合逻辑14. Requirement 是什么Requirement 可以理解成这条路径被要求在多长时间内完成如果是 100 MHz 时钟周期是 10 ns。同一个时钟域内普通寄存器到寄存器路径的 setup requirement 通常接近一个时钟周期。但实际报告里不会简单等于 10 ns因为还要考虑时钟偏斜 时钟不确定性 时钟树延迟 setup time multicycle path max delay 约束如果你看到 requirement 非常小比如Requirement 0.200 ns就要警惕。这可能不是 RTL 逻辑真的那么差而是时钟关系或约束有问题。常见原因两个时钟关系定义不合理 generated clock 没写对 跨时钟路径没有正确处理 multicycle path 写错 时钟频率或相位约束不符合实际15. Data Path Delay 是什么Data Path Delay 是数据路径本身的延迟。它通常包括寄存器 clock-to-Q 延迟 组合逻辑延迟 net 布线延迟如果 Data Path Delay 很大一般要继续看Logic Delay 大还是 Route Delay 大15.1 Logic Delay 大说明组合逻辑复杂。常见情况一拍里做了太多 if/else 一拍里做了大位宽加法、比较、乘法 case 逻辑很深 优先级判断太长 没有合理使用 DSP BRAM 输出没有寄存优化方向加流水线 拆分组合逻辑 减少优先级链 把复杂运算分多拍 使用 DSP/BRAM 内部寄存器15.2 Route Delay 大说明布线延迟大。常见情况模块距离太远 fanout 太大 控制信号驱动太多地方 资源利用率太高 跨 SLR 或跨很远区域 布局拥塞优化方向降低 fanout 复制寄存器 减少全局大范围控制信号 使用 phys_opt_design 必要时做 floorplan 优化模块层次和数据流方向注意先改结构再考虑 floorplan。新人不要一上来就手动摆布局。16. Logic Levels 是什么Logic Levels 表示这条路径经过了多少级逻辑。如果 Logic Levels 很高通常说明组合逻辑太深。比如Logic Levels: 12这对高频设计来说就比较危险。新人可以先粗略理解逻辑级数越多setup 越难过。常见优化方法还是加寄存器 拆组合逻辑 把一拍完成的事拆成多拍17. Clock Skew 和 Clock Uncertainty 不要乱忽略timing path 里还会出现 clock skew、clock uncertainty。新人不需要一开始就深挖每个细节但要知道Vivado 的 slack 不是只看数据路径。它还会考虑时钟路径延迟 时钟抖动 相位误差 用户设置的不确定性 时钟树差异所以有时候你觉得数据路径延迟 9.8 ns 时钟周期 10 ns 应该刚好能过但 Vivado 可能仍然报失败。原因就是实际可用时间不是简单的 10 ns18. timing failed 后正确排查顺序建议新人按这个流程排查第一步确认约束完整 第二步确认失败类型是 setup 还是 hold 第三步确认失败路径是同时钟还是跨时钟 第四步查看最差 path 的 startpoint/endpoint 第五步判断是 logic delay 大还是 route delay 大 第六步根据原因修改 RTL 或约束 第七步重新综合实现看 WNS/TNS 是否改善不要一看到 failed 就乱改。更不要直接降低时钟频率然后假装问题解决。降低频率当然可能让 setup 变好但它没有回答这个问题这条路径为什么这么慢工程里要知道原因。19. 常见场景 1WNS 很负TNS 不大例子WNS -2.100 ns TNS -2.300 ns Failing Endpoints 2这种情况说明失败路径不多但最差路径很严重。排查重点找到最差 path 看 startpoint/endpoint 看是否某个模块里有超长组合逻辑 看是否某个约束写错导致 requirement 异常如果是一条真实的数据计算路径通常需要改 RTL比如加流水线。20. 常见场景 2WNS 不大TNS 很大例子WNS -0.080 ns TNS -35.000 ns Failing Endpoints 1200这种情况说明单条路径差得不多但失败范围很大。常见原因设计整体频率压得太紧 某个高 fanout 控制信号影响很多 endpoint 布局布线拥塞 某个模块整体没有做好流水处理方法先看失败路径是否集中在某个 clock domain 再看是否集中在某个模块 再看是否有大 fanout 信号 最后考虑整体架构是否需要加 pipeline21. 常见场景 3setup 过了hold failed例子WNS 0.120 ns TNS 0.000 ns WHS -0.030 ns THS -0.500 ns这说明 setup 没问题但 hold 有问题。新人容易犯的错误是在 RTL 里手动加几级 LUT 延迟不建议这样做。正确排查方向检查时钟约束是否正确 检查 generated clock 是否正确 检查跨时钟路径是否误分析 检查 IO delay 是否合理 检查是否有错误的 min delay / false path / multicycle path如果约束没有问题再看实现阶段是否可以通过工具优化解决。22. 常见场景 4有 unconstrained paths如果 timing summary 里有 unconstrained paths要优先处理。因为这代表有些路径没有被正确时序分析。常见原因没有 create_clock generated clock 缺失 输入输出端口没有 set_input_delay / set_output_delay 异步路径没有合理声明 IP 相关约束没有加入工程这类问题比 WNS 小负数更值得重视。因为 WNS 至少说明 Vivado 在分析它。unconstrained path 可能是 Vivado 根本没有按你的真实工作条件分析。23. 常用 Tcl 命令下面这些命令建议新人熟悉。23.1 查看 timing summaryreport_timing_summary更完整一点report_timing_summary -delay_type min_max -report_unconstrained23.2 只看 setupreport_timing_summary -setup23.3 只看 holdreport_timing_summary -hold23.4 查看最差路径report_timing -max_paths 10 -nworst 123.5 检查约束问题check_timing23.6 查看时钟report_clocks23.7 查看时钟交互report_clock_interaction23.8 查看 CDCreport_cdc24. 新人最容易犯的几个错误错误 1只看 WNS不看 TNSWNS 只代表最差路径。TNS 和 failing endpoints 才能反映失败范围。错误 2看到 timing failed 就降频降频可能能过但不一定是工程上的正确解决方式。你至少要知道是哪条路径慢为什么慢。错误 3跨时钟路径一律 set_false_path这是非常危险的。false path 不是 CDC 设计。CDC 要靠同步器、异步 FIFO、握手协议等结构解决。错误 4有 unconstrained path 还说 timing clean不完整约束下的 timing pass 没有太大意义。约束不完整报告就不可信。错误 5hold failed 就在 RTL 里凑延迟不要随便用 LUT、反相器、无意义逻辑去凑 hold 延迟。这种写法不稳定也不利于维护。25. 一个简单的阅读模板以后看到 timing failed可以照这个模板看1. Check Timing 有没有 no_clock / unconstrained path 2. Design Timing Summary 里是 setup failed 还是 hold failed 3. WNS/WHS 最差是多少 4. TNS/THS 总量大不大 5. Failing Endpoints 有多少 6. 失败集中在哪个 clock domain 7. 是 Intra-Clock 还是 Inter-Clock 8. 最差路径的 startpoint 和 endpoint 是什么 9. Data Path Delay 里 logic delay 大还是 route delay 大 10. RTL、约束、CDC、布局布线哪个最可能是根因这个顺序比盯着一个 WNS 数字更有用。26. 总结Vivado timing failed 不可怕。可怕的是不知道怎么看报告然后乱改。新人先记住这几个结论slack 是时序余量 slack 为正表示通过 slack 为负表示失败 WNS 看最差 setup 路径 TNS 看 setup 失败总量 WHS 看最差 hold 路径 THS 看 hold 失败总量 setup failed 通常是数据路径太慢 hold failed 通常是数据变化太早或约束/时钟关系需要检查 看 timing report 之前先看 Check Timing 有 unconstrained path 时不要轻易说 timing clean真正做工程时时序收敛不是简单地“让 WNS 变正”。更重要的是约束完整 时钟关系清楚 CDC 结构正确 关键路径能解释 RTL 结构能优化 最终 post-route timing clean能做到这些才算真正开始入门 FPGA 时序分析。 Vivado timing failed 怎么看：WNS、TNS、slack 到底是什么意思
前言很多 FPGA 新人在 Vivado 里第一次看到timing failed第一反应是代码是不是写错了为什么综合、实现都跑完了最后还说 failedWNS、TNS、slack 这些数字到底要看哪一个这篇文章不讲虚的只讲新人真正需要看懂的东西。本文主要解决 4 个问题timing failed 到底是什么意思slack 是什么WNS、TNS、WHS、THS 分别怎么看看到 timing failed 以后应该按什么顺序排查文章适合 FPGA 应届生、研二研三学生、入行 1 年以内的新人工程师阅读。1. timing failed 不是语法错误而是时序不满足Vivado 里常见的几个阶段是RTL 编写 ↓ Synthesis 综合 ↓ Implementation 实现 ├─ opt_design ├─ place_design ├─ phys_opt_design └─ route_design ↓ Generate Bitstream语法错误一般在综合前后就会暴露。而timing failed通常发生在实现之后意思不是“Verilog 语法错了”而是按照你设置的时钟频率和约束条件Vivado 认为某些信号路径来不及稳定或者稳定得太早不能可靠工作。简单说功能仿真通过 ≠ 上板一定稳定 综合通过 ≠ 时序一定满足 bitstream 能生成 ≠ 设计一定可靠FPGA 不是只看逻辑对不对还要看信号能不能在规定时间内到达。2. 先记住一句话slack 是“余量”看时序报告最核心的词就是slack。可以先把 slack 理解成slack 时序余量如果 slack 是正数说明还有余量。如果 slack 是 0说明刚好卡边。如果 slack 是负数说明已经违反时序。例如slack 0.350 ns表示这条路径还有 0.350 ns 的余量。slack -0.120 ns表示这条路径慢了 0.120 ns或者说少了 0.120 ns 的时间。对于新人来说先记住这个判断slack 0时序通过 slack 0时序失败3. setup slack数据来得太晚会失败FPGA 里最常见的是寄存器到寄存器的路径寄存器 A --- 组合逻辑 --- 寄存器 B寄存器 A 在一个时钟边沿把数据打出去。数据经过组合逻辑和布线最后到达寄存器 B。寄存器 B 要在下一个有效时钟边沿采样这个数据。问题是数据必须在寄存器 B 采样之前提前稳定好。这就是 setup 要求。如果数据来得太晚寄存器 B 采样时数据还没稳定就会 setup violation。setup 分析可以简单理解成setup slack 要求到达时间 - 实际到达时间举个例子要求数据最晚 10.000 ns 到 实际数据 9.300 ns 到 slack 10.000 - 9.300 0.700 ns这条路径通过还有 0.700 ns 余量。再看一个失败的例子要求数据最晚 10.000 ns 到 实际数据 10.250 ns 到 slack 10.000 - 10.250 -0.250 ns这条路径失败慢了 0.250 ns。所以 setup 失败本质上通常是数据路径太慢 组合逻辑太长 布线延迟太大 时钟频率太高4. hold slack数据变得太早也会失败很多新人只关心 setup不关心 hold。这是不对的。setup 是怕数据来得太晚。hold 是怕数据变得太早。寄存器 B 在某个时钟边沿采样数据后数据不能立刻变化必须继续稳定一小段时间。这就是 hold 要求。hold 分析可以简单理解成hold slack 实际到达时间 - 要求保持时间如果 hold slack 是负数说明数据变化太早破坏了寄存器的保持时间。setup 和 hold 的区别可以这样记setup怕数据来晚 hold 怕数据变早在工程里setup 失败通常需要你改 RTL、加流水、优化结构。hold 失败很多时候由工具在布局布线阶段自动修但如果最终还有 hold violation就要认真检查约束、跨时钟路径、IO 约束和不合理的时钟关系。5. WNS 是什么WNS 全称是Worst Negative Slack直白翻译最差的一条负 slack也可以理解成Vivado 在所有 setup/recovery 相关路径里找到最差的那条路径它的 slack 就是 WNS。例如 timing summary 里看到WNS -0.238 ns意思是最差的 setup 路径差了 0.238 ns如果看到WNS 0.120 ns意思是最差的 setup 路径也还有 0.120 ns 余量注意一点WNS 只代表最差那条路径不代表所有路径的情况。所以 WNS 很重要但不能只看 WNS。6. TNS 是什么TNS 全称是Total Negative Slack直白理解总的负 slack更工程化一点说TNS 反映的是 setup 违例的整体严重程度。举例WNS -0.500 ns TNS -0.500 ns Failing Endpoints 1这通常说明只有一个 endpoint 失败而且最差就是这一个。再看另一个例子WNS -0.050 ns TNS -20.000 ns Failing Endpoints 800这时候虽然 WNS 只差 0.050 ns看起来不大但失败的 endpoint 很多整体问题很严重。所以看 setup timing 不能只看 WNS也要看 TNS 和 failing endpoints。可以这样判断WNS 很负最差路径很严重 TNS 很负失败路径很多整体收敛差 Failing Endpoints 多影响范围大7. WHS 和 THS 是什么WNS、TNS 主要看 setup/recovery。hold 相关要看WHSWorst Hold Slack THSTotal Hold Slack可以类比理解WNS最差 setup slack TNS总 setup 负 slack WHS最差 hold slack THS总 hold 负 slack如果看到WHS -0.080 ns THS -1.200 ns说明存在 hold violation。hold violation 不要随便在 RTL 里加 LUT、加反相器、加一堆无意义逻辑去“凑延迟”。这种写法很危险换个器件、换个版本、换次布局布线就可能失效。更合理的做法是先检查约束是否正确 再检查是否有错误的跨时钟路径 再看是否有不合理的 generated clock / false path / multicycle path 最后再结合实现结果分析8. Vivado timing summary 应该怎么看很多新人打开 timing summary一堆表格不知道从哪里看。建议按这个顺序1. 先看 Check Timing 2. 再看 Design Timing Summary 3. 再看 Intra-Clock Paths 4. 再看 Inter-Clock Paths 5. 最后点进具体 timing path9. 第一步先看 Check Timing在看 WNS/TNS 之前建议先看Check Timing。原因很简单如果约束本身不完整WNS/TNS 的参考价值就会下降。Check Timing 里常见问题包括no_clock unconstrained endpoint missing generated clock input/output delay 缺失 clock relationship 不清楚尤其是no_clock和unconstrained endpoint新人一定要重视。如果某些路径没有被时钟约束覆盖Vivado 可能根本没有正确分析这些路径。这时候你看到的 timing pass 可能是假象。也就是说timing met 但存在大量 unconstrained path不代表设计真的安全。工程里要先保证该约束的时钟都约束了 该约束的 IO delay 都约束了 该声明的异步路径正确声明了 不该 false path 的路径不要乱 false path10. 第二步看 Design Timing SummaryDesign Timing Summary 通常会有类似信息WNS(ns) TNS(ns) Failing Endpoints -0.238 -12.560 143 WHS(ns) THS(ns) Failing Endpoints 0.045 0.000 0这段信息可以这样读WNS -0.238说明 setup 最差路径差 0.238 ns。TNS -12.560说明 setup 失败不是一个孤立点整体累计负 slack 比较多。Failing Endpoints 143说明有 143 个 endpoint 存在 setup 违例。WHS 0.045说明 hold 最差路径还有 0.045 ns 余量。THS 0.000说明没有 hold 负 slack。这时候结论就是setup failed hold passed接下来应该优先分析 setup 路径。11. 第三步看 Intra-Clock 和 Inter-ClockVivado 的 timing summary 通常会把路径分成Intra-Clock Paths同一个时钟域内的路径 Inter-Clock Paths不同时钟之间的路径11.1 Intra-Clock 失败如果是 Intra-Clock 路径失败常见原因是组合逻辑太深 一个周期内做的事情太多 模块层级之间没有打拍 大 fanout 信号拖慢 DSP/BRAM 使用方式不合理 布线太远解决方向通常是加流水线 拆组合逻辑 减少一个周期内的计算量 关键控制信号打一拍 降低 fanout 让 DSP/BRAM 输出寄存 必要时做 floorplan11.2 Inter-Clock 失败如果是 Inter-Clock 路径失败要更小心。先问一个问题这两个时钟到底是不是同步关系如果两个时钟同源、频率有明确关系可能应该正常做时序分析。如果两个时钟异步就不能直接当普通同步路径处理。异步跨时钟需要 CDC 设计例如单 bit 控制信号两级同步器 多 bit 数据异步 FIFO 握手信号req/ack 结构 脉冲信号脉冲同步或 toggle 同步同时还要配合正确的 timing exception。但是不要看到跨时钟失败就直接写set_false_path -from [get_clocks clk_a] -to [get_clocks clk_b]这很危险。set_false_path的意思不是“帮我修好跨时钟”而是“这条路径不需要做常规时序分析”。如果你的 CDC 结构本身是错的false path 只会把问题藏起来。12. 第四步点进具体 timing path只看 WNS/TNS 不够真正定位问题要点进最差路径。一条 timing path 里重点看这些字段Startpoint Endpoint Path Group Path Type Requirement Data Path Delay Logic Levels Clock Path Skew Clock Uncertainty Slack下面逐个解释。13. Startpoint 和 EndpointStartpoint 是数据从哪里出发。Endpoint 是数据到哪里被采样。常见形式Startpoint: u_a/reg_data_reg[3]/C Endpoint : u_b/reg_sum_reg[3]/D这说明数据从u_a里的某个寄存器出来最后到u_b里的某个寄存器 D 端。新人排查时先根据 startpoint 和 endpoint 找到对应 RTL。你要搞清楚这条路径属于哪个模块 这条路径完成什么功能 这条路径是不是必须一个周期完成 中间有没有很长的组合逻辑14. Requirement 是什么Requirement 可以理解成这条路径被要求在多长时间内完成如果是 100 MHz 时钟周期是 10 ns。同一个时钟域内普通寄存器到寄存器路径的 setup requirement 通常接近一个时钟周期。但实际报告里不会简单等于 10 ns因为还要考虑时钟偏斜 时钟不确定性 时钟树延迟 setup time multicycle path max delay 约束如果你看到 requirement 非常小比如Requirement 0.200 ns就要警惕。这可能不是 RTL 逻辑真的那么差而是时钟关系或约束有问题。常见原因两个时钟关系定义不合理 generated clock 没写对 跨时钟路径没有正确处理 multicycle path 写错 时钟频率或相位约束不符合实际15. Data Path Delay 是什么Data Path Delay 是数据路径本身的延迟。它通常包括寄存器 clock-to-Q 延迟 组合逻辑延迟 net 布线延迟如果 Data Path Delay 很大一般要继续看Logic Delay 大还是 Route Delay 大15.1 Logic Delay 大说明组合逻辑复杂。常见情况一拍里做了太多 if/else 一拍里做了大位宽加法、比较、乘法 case 逻辑很深 优先级判断太长 没有合理使用 DSP BRAM 输出没有寄存优化方向加流水线 拆分组合逻辑 减少优先级链 把复杂运算分多拍 使用 DSP/BRAM 内部寄存器15.2 Route Delay 大说明布线延迟大。常见情况模块距离太远 fanout 太大 控制信号驱动太多地方 资源利用率太高 跨 SLR 或跨很远区域 布局拥塞优化方向降低 fanout 复制寄存器 减少全局大范围控制信号 使用 phys_opt_design 必要时做 floorplan 优化模块层次和数据流方向注意先改结构再考虑 floorplan。新人不要一上来就手动摆布局。16. Logic Levels 是什么Logic Levels 表示这条路径经过了多少级逻辑。如果 Logic Levels 很高通常说明组合逻辑太深。比如Logic Levels: 12这对高频设计来说就比较危险。新人可以先粗略理解逻辑级数越多setup 越难过。常见优化方法还是加寄存器 拆组合逻辑 把一拍完成的事拆成多拍17. Clock Skew 和 Clock Uncertainty 不要乱忽略timing path 里还会出现 clock skew、clock uncertainty。新人不需要一开始就深挖每个细节但要知道Vivado 的 slack 不是只看数据路径。它还会考虑时钟路径延迟 时钟抖动 相位误差 用户设置的不确定性 时钟树差异所以有时候你觉得数据路径延迟 9.8 ns 时钟周期 10 ns 应该刚好能过但 Vivado 可能仍然报失败。原因就是实际可用时间不是简单的 10 ns18. timing failed 后正确排查顺序建议新人按这个流程排查第一步确认约束完整 第二步确认失败类型是 setup 还是 hold 第三步确认失败路径是同时钟还是跨时钟 第四步查看最差 path 的 startpoint/endpoint 第五步判断是 logic delay 大还是 route delay 大 第六步根据原因修改 RTL 或约束 第七步重新综合实现看 WNS/TNS 是否改善不要一看到 failed 就乱改。更不要直接降低时钟频率然后假装问题解决。降低频率当然可能让 setup 变好但它没有回答这个问题这条路径为什么这么慢工程里要知道原因。19. 常见场景 1WNS 很负TNS 不大例子WNS -2.100 ns TNS -2.300 ns Failing Endpoints 2这种情况说明失败路径不多但最差路径很严重。排查重点找到最差 path 看 startpoint/endpoint 看是否某个模块里有超长组合逻辑 看是否某个约束写错导致 requirement 异常如果是一条真实的数据计算路径通常需要改 RTL比如加流水线。20. 常见场景 2WNS 不大TNS 很大例子WNS -0.080 ns TNS -35.000 ns Failing Endpoints 1200这种情况说明单条路径差得不多但失败范围很大。常见原因设计整体频率压得太紧 某个高 fanout 控制信号影响很多 endpoint 布局布线拥塞 某个模块整体没有做好流水处理方法先看失败路径是否集中在某个 clock domain 再看是否集中在某个模块 再看是否有大 fanout 信号 最后考虑整体架构是否需要加 pipeline21. 常见场景 3setup 过了hold failed例子WNS 0.120 ns TNS 0.000 ns WHS -0.030 ns THS -0.500 ns这说明 setup 没问题但 hold 有问题。新人容易犯的错误是在 RTL 里手动加几级 LUT 延迟不建议这样做。正确排查方向检查时钟约束是否正确 检查 generated clock 是否正确 检查跨时钟路径是否误分析 检查 IO delay 是否合理 检查是否有错误的 min delay / false path / multicycle path如果约束没有问题再看实现阶段是否可以通过工具优化解决。22. 常见场景 4有 unconstrained paths如果 timing summary 里有 unconstrained paths要优先处理。因为这代表有些路径没有被正确时序分析。常见原因没有 create_clock generated clock 缺失 输入输出端口没有 set_input_delay / set_output_delay 异步路径没有合理声明 IP 相关约束没有加入工程这类问题比 WNS 小负数更值得重视。因为 WNS 至少说明 Vivado 在分析它。unconstrained path 可能是 Vivado 根本没有按你的真实工作条件分析。23. 常用 Tcl 命令下面这些命令建议新人熟悉。23.1 查看 timing summaryreport_timing_summary更完整一点report_timing_summary -delay_type min_max -report_unconstrained23.2 只看 setupreport_timing_summary -setup23.3 只看 holdreport_timing_summary -hold23.4 查看最差路径report_timing -max_paths 10 -nworst 123.5 检查约束问题check_timing23.6 查看时钟report_clocks23.7 查看时钟交互report_clock_interaction23.8 查看 CDCreport_cdc24. 新人最容易犯的几个错误错误 1只看 WNS不看 TNSWNS 只代表最差路径。TNS 和 failing endpoints 才能反映失败范围。错误 2看到 timing failed 就降频降频可能能过但不一定是工程上的正确解决方式。你至少要知道是哪条路径慢为什么慢。错误 3跨时钟路径一律 set_false_path这是非常危险的。false path 不是 CDC 设计。CDC 要靠同步器、异步 FIFO、握手协议等结构解决。错误 4有 unconstrained path 还说 timing clean不完整约束下的 timing pass 没有太大意义。约束不完整报告就不可信。错误 5hold failed 就在 RTL 里凑延迟不要随便用 LUT、反相器、无意义逻辑去凑 hold 延迟。这种写法不稳定也不利于维护。25. 一个简单的阅读模板以后看到 timing failed可以照这个模板看1. Check Timing 有没有 no_clock / unconstrained path 2. Design Timing Summary 里是 setup failed 还是 hold failed 3. WNS/WHS 最差是多少 4. TNS/THS 总量大不大 5. Failing Endpoints 有多少 6. 失败集中在哪个 clock domain 7. 是 Intra-Clock 还是 Inter-Clock 8. 最差路径的 startpoint 和 endpoint 是什么 9. Data Path Delay 里 logic delay 大还是 route delay 大 10. RTL、约束、CDC、布局布线哪个最可能是根因这个顺序比盯着一个 WNS 数字更有用。26. 总结Vivado timing failed 不可怕。可怕的是不知道怎么看报告然后乱改。新人先记住这几个结论slack 是时序余量 slack 为正表示通过 slack 为负表示失败 WNS 看最差 setup 路径 TNS 看 setup 失败总量 WHS 看最差 hold 路径 THS 看 hold 失败总量 setup failed 通常是数据路径太慢 hold failed 通常是数据变化太早或约束/时钟关系需要检查 看 timing report 之前先看 Check Timing 有 unconstrained path 时不要轻易说 timing clean真正做工程时时序收敛不是简单地“让 WNS 变正”。更重要的是约束完整 时钟关系清楚 CDC 结构正确 关键路径能解释 RTL 结构能优化 最终 post-route timing clean能做到这些才算真正开始入门 FPGA 时序分析。