第一章 读懂时序报告：Setup/Hold Slack、关键路径定位、Worst Negative Slack解读
各位同行，咱们做FPGA或者ASIC的，上板调试最怕什么？我最怕那种“功能仿真全对，一上板就挂”的情况。这时候，时序报告就是你最好的朋友——前提是，你得看得懂它。
我刚开始带项目那会儿，有个同事跑完综合，看了一眼时序报告，说了句“全是绿的，没问题”，结果上板跑起来，数据时不时就错一拍。后来我帮他一看，WNS（Worst Negative Slack）虽然没负多少，但那条关键路径的余量只有几十皮秒，温度一高、电压一抖，立马就崩了。所以今天咱们就好好聊聊，时序报告到底该怎么看。
核心观点：时序报告不是用来“通过”的，是用来“诊断”的。你要学会从数字里读出电路的真实健康状况。
1.1 Setup Slack 与 Hold Slack——两个最基本的“生死线”
说白了，Setup Slack 检查的是数据能不能在时钟沿到来之前稳定下来。Hold Slack 检查的是数据能不能在时钟沿之后保持足够长的时间。这两个概念，我估计大家在学校都学过，但实际看报告时，很多人容易忽略一个细节：Setup 和 Hold 的检查对象是不同的。
Setup Slack 的计算公式很简单：
Setup Slack = 时钟周期 - (数据路径延迟 + 建立时间 + 时钟偏斜)Hold Slack 则是：
Hold Slack = 数据路径延迟 - (保持时间 + 时钟偏斜)嗯，这里要注意：Setup Slack 是“正”的才安全，Hold Slack 也是“正”的才安全。但实际项目中，我见过不少新手只盯着 Setup Slack 看，觉得 Hold Slack 无所谓。我曾经就因为这个吃过亏——一个 DDR 接口的 Hold 违例，导致数据采样总是不稳定，查了整整两天才定位到问题。
个人经验：我建议你在看时序报告时，先扫一眼所有路径的 Hold Slack。如果发现有负值，哪怕只有 -0.01ns，也要优先处理。因为 Hold 违例通常意味着电路存在“竞争冒险”，这种问题在温度、电压变化时最容易暴露。
1.2 关键路径定位——别被“最差”骗了
时序报告里通常会列出“Worst Negative Slack”（WNS）和“Total Negative Slack”（TNS）。WNS 是所有路径里最差的那一条，TNS 是所有负 Slack 路径的总和。
很多人拿到报告，第一反应就是看 WNS 是多少。如果 WNS 是正的，就觉得万事大吉。但我想说：WNS 正，不代表所有路径都安全。
举个例子，我去年调试一个视频处理芯片，WNS 显示 +0.2ns，看起来挺健康。但我仔细一看，有 300 多条路径的 Slack 都在 0 到 +0.05ns 之间。这意味着什么？意味着这些路径的余量非常脆弱。后来我们稍微调整了一下布局，温度一上来，这些路径就全红了。
避坑指南：我曾经见过一个团队，只盯着 WNS 修，修完 WNS 就以为时序收敛了。结果流片回来，芯片在高温下频繁出错。所以我的习惯是：先看 TNS，再看 WNS。如果 TNS 很大，说明有很多路径都处于“亚健康”状态，这时候光修最差的那一条是不够的。
1.3 Worst Negative Slack 解读——数字背后的故事
WNS 这个数字，其实能告诉你很多信息。我一般会从三个维度去解读：
- 数值大小：如果 WNS 是 -0.5ns 以内，通常可以通过调整约束、优化逻辑深度来解决。如果超过 -1ns，那就要考虑架构层面的改动了，比如插入流水线。
- 路径类型：是组合逻辑路径？还是跨时钟域路径？还是复位路径？不同类型的路径，处理方式完全不同。
- 出现频率：如果 WNS 只出现在一条路径上，那可能是局部问题。如果多条路径都有类似的负 Slack，那可能是整体约束或者时钟结构有问题。
我记得有一次，一个项目在综合后 WNS 是 -0.8ns，我一看，全是跨时钟域的路径。后来发现是异步 FIFO 的格雷码同步器没做好，导致路径延迟特别大。改完之后，WNS 直接变成了 +0.3ns。
关键点：WNS 不是用来“害怕”的，是用来“分析”的。你要问自己三个问题：为什么这条路径最差？它属于什么类型？我该怎么改？
1.4 知识体系总览
下面这张图，是我自己总结的时序报告解读流程。每次拿到新项目的时序报告，我都会按这个步骤走一遍，基本不会漏掉关键问题。
1.5 实战案例：一个典型的时序报告解读
假设你拿到这样一份报告摘要：
| 指标 | 数值 | 解读 |
|---|---|---|
| WNS | -0.35ns | 有一条路径违例，但程度不严重 |
| TNS | -2.1ns | 有多条路径存在违例，需要关注 |
| 最差路径类型 | 组合逻辑 | 可能是逻辑深度过大 |
| 最差路径起点 | u_top/u_dsp/mult_inst | 乘法器输出路径 |
我的分析思路是这样的：
- 先看 TNS：-2.1ns 说明不止一条路径有问题，不能只修 WNS 那条。
- 再看路径类型：全是组合逻辑路径，说明问题出在逻辑深度上，而不是跨时钟域或者复位。
- 定位起点：乘法器输出路径，那大概率是乘法器没有做流水线。
实际处理时，我一般会在乘法器内部插入两级流水线，然后重新综合。大部分情况下，WNS 和 TNS 都能变正。如果还不行，那就考虑换一个更快的乘法器 IP，或者调整综合策略。
小技巧：我习惯在综合脚本里加一句 report_timing -nworst 10，这样能一次性看到最差的 10 条路径，而不是只看一条。很多时候，问题模式会在前 10 条路径里重复出现，帮你快速定位根因。
1.6 总结
读懂时序报告，说白了就是三件事：看数值、看类型、看趋势。数值告诉你严不严重，类型告诉你问题出在哪，趋势告诉你是不是系统性问题。
我做了这么多年，最大的体会就是：时序报告不是用来“通过”检查的，它是你调试过程中最忠实的伙伴。每次上板前，我都会花至少半小时仔细看一遍时序报告，尤其是那些 Slack 接近零的路径。这个习惯，帮我避免了好几次流片失败。
嗯，今天就先聊到这儿。下一章咱们会深入讲讲如何用工具定位具体的违例路径，以及一些我常用的调试技巧。
可可精品资料库