前言Vivado 跑完综合或实现后经常会看到这样的结果WNS -0.325 ns TNS -18.640 ns Failing Endpoints 126很多新人看到负数只知道“时序失败了”但不知道应该先看什么、怎么定位。这篇文章用尽量简洁的方式讲清楚WNS、TNS 分别表示什么两个指标应该怎么看如何定位具体的违例路径常见问题应该怎么修改。一、先理解 Slack对于 Setup 时序Slack 可以简单理解为Slack 要求到达时间 - 实际到达时间例如一个数据要求在10 ns内到达要求到达时间10.000 ns 实际到达时间10.325 ns Slack -0.325 ns数据晚了0.325 ns因此时序失败。判断规则很简单Slack含义大于 0时序满足等于 0刚好满足余量很小小于 0时序违例二、WNS 是什么WNS 全称Worst Negative Slack它表示整个设计中最差的一条 Setup 路径的 Slack。例如有三条路径路径 ASlack -0.325 ns 路径 BSlack -0.120 ns 路径 CSlack 0.450 ns那么WNS -0.325 ns也就是最差路径还缺少0.325 ns。需要注意虽然名称叫 Worst Negative Slack但 WNS 也可能是正数。WNS 0.280 ns说明最差的一条路径仍然有0.280 ns的正裕量Setup 时序满足。三、TNS 是什么TNS 全称Total Negative Slack它表示所有违例端点负 Slack 的总和。例如端点 A-0.325 ns 端点 B-0.120 ns 端点 C-0.080 ns 端点 D 0.450 ns那么TNS -0.325 - 0.120 - 0.080 -0.525 ns正 Slack 不参与计算。因此WNS反映最差路径有多差 TNS反映整个设计的违例范围有多大四、WNS 和 TNS 应该一起看只看一个指标很容易误判问题规模。情况一WNS 很差TNS 较小WNS -2.000 ns TNS -2.500 ns Failing Endpoints 2说明违例路径数量不多但其中有一条路径非常差。常见原因组合逻辑层级太深DSP、BRAM 前后没有流水线跨模块路径过长约束要求不合理。这种情况优先处理最差路径。情况二WNS 不太差TNS 很大WNS -0.150 ns TNS -80.000 ns Failing Endpoints 1000说明单条路径只差一点但大量路径都存在小幅违例。常见原因整体频率设置偏高布局拥塞高扇出控制信号某个公共模块影响了大量路径约束或时钟定义存在问题。这种情况不能只盯着第一条关键路径应找出重复出现的模块、时钟域和路径类型。情况三WNS 为正TNS 为 0WNS 0.210 ns TNS 0.000 ns说明 Setup 时序通过。但还需要继续检查WHS THS Unconstrained Paths Check Timing因为 Setup 通过不代表 Hold、时钟约束和未约束路径都没有问题。五、在哪里查看 WNS、TNS在 Vivado 中打开Open Implemented Design ↓ Reports ↓ Timing ↓ Report Timing Summary也可以在 Tcl Console 中执行report_timing_summary建议重点看实现完成后的报告尤其是post-route timing综合后的时序报告中布线延迟主要是估算值完成布局布线后的结果才更接近最终硬件。六、看到 WNS 为负应该怎么分析推荐按照下面的顺序分析不要一上来就随便加流水线。第一步先确认约束是否完整先看 Timing Summary 中是否存在No Clock Unconstrained Paths Missing Input Delay Missing Output Delay常用命令check_timing report_clocks report_clock_interaction如果时钟没有正确定义后面的 WNS、TNS 可能没有分析意义。例如主时钟约束create_clock -name sys_clk -period 10.000 [get_ports sys_clk]10 ns对应100 MHz。不要为了让时序变绿直接把真实同步路径设置成 false path。set_false_path ...只有功能上确实不需要进行同步时序检查的路径才能设置为 false path。第二步确认是哪一个时钟域失败Timing Summary 中通常会按照时钟或 Path Group 分类。例如Clock WNS TNS sys_clk -0.325 -8.420 pixel_clk 0.180 0.000 axi_clk -0.060 -1.200可以看出sys_clk 是主要问题 axi_clk 只有轻微违例 pixel_clk 已经通过先处理 WNS 最差、TNS 最大的时钟域。第三步打开最差路径在 Timing Summary 中展开违例路径重点看Source Destination Path Group Logic Levels Data Path Delay Logic Delay Route Delay Clock Skew Slack可以把一条路径简化成源寄存器 ↓ 组合逻辑 ↓ 布线 ↓ 目标寄存器重点判断延迟主要来自逻辑还是布线。七、逻辑延迟大怎么处理如果报告中出现Logic Levels 很多 Logic Delay 占比高说明组合逻辑可能太深。例如always (posedge clk) begin result ((a b) * c d) threshold; end一拍内同时完成加法、乘法、再次加法和比较容易形成较长路径。可以增加流水线reg [31:0] add_r; reg [63:0] mult_r; reg [63:0] sum_r; always (posedge clk) begin add_r a b; mult_r add_r * c; sum_r mult_r d; result sum_r threshold; end常见优化方法增加流水级减少一拍内的运算数量拆分大位宽加法和比较逻辑优化过深的if-else或case使用 DSP、BRAM 的输入输出寄存器避免一拍内完成过多级联运算。八、布线延迟大怎么处理如果Route Delay 占比高 Logic Levels 并不多问题通常不只是 RTL 组合逻辑而可能与布局布线有关。常见原因源寄存器和目标寄存器距离过远跨 SLR设计拥塞高扇出信号驱动大量寄存器模块之间连接过于分散。常见处理方法给长距离路径增加寄存器复制高扇出控制信号减少全局使能、复位对大量逻辑的直接驱动检查器件利用率和拥塞检查跨 SLR 路径必要时使用合理的 Pblock 或物理约束。不要认为“代码看起来很简单时序就一定好”。有些路径只有一两级逻辑但物理距离很远仍然可能失败。九、几个常见误区误区一WNS 为正就全部完成了错误。WNS 通常反映 Setup 最大延迟分析还要检查WHS / THS 时钟约束 未约束路径 CDC 脉宽检查误区二TNS 是所有负路径直接相加更准确地说Vivado 会按违例端点统计最差 Slack再进行累计。因此 TNS 适合判断整体违例规模但不能简单理解成报告中所有负 Slack 行的机械求和。误区三把时钟周期改大就是优化完成例如从create_clock -period 5.000改成create_clock -period 10.000WNS 很可能立刻变正。但这不是优化而是把目标频率从200 MHz降到了100 MHz。只有系统确实允许降频时这种修改才合理。误区四随便设置 false path错误的 false path 会让 Vivado 不再检查真实存在的时序路径。结果可能是报告变绿 硬件运行不稳定约束的作用是描述真实硬件关系不是隐藏违例。十、推荐分析流程看到 Timing Failed 后可以按照下面的顺序处理1. 检查时钟和 I/O 约束 ↓ 2. 检查是否存在未约束路径 ↓ 3. 找出 WNS 最差的时钟域 ↓ 4. 打开最差路径 ↓ 5. 判断是逻辑延迟还是布线延迟 ↓ 6. 找出是否存在大量相似违例 ↓ 7. 修改 RTL、流水线或物理结构 ↓ 8. 重新综合、布局布线常用 Tcl 命令report_timing_summary report_timing -delay_type max -max_paths 10 check_timing report_clocks report_clock_interaction report_high_fanout_nets report_design_analysis总结分析 Vivado 的 WNS、TNS可以记住四句话WNS 看最差路径。 TNS 看整体违例规模。 WNS 为负说明至少有一条 Setup 路径失败。 TNS 越负通常说明受影响的违例端点越多或违例越严重。真正处理时序问题时不要只看一个负数而要继续查看哪个时钟域失败 起点和终点在哪里 逻辑延迟大还是布线延迟大 是少数严重违例还是大量轻微违例 约束是否正确只有回答完这些问题才能决定应该增加流水线、优化逻辑、处理高扇出、改善布局还是修改错误的时序约束。