读懂 Setup Slack 与 Hold Slack 报告
时序报告这东西，刚入行的时候看着真头疼。密密麻麻的数字，一堆英文缩写，不知道从哪看起。
我刚开始带项目那会儿，有个同事拿着报告跑来找我，说「这 slack 是负的，是不是芯片废了？」。我一看，其实只是条伪路径没设对。
所以今天咱们就好好聊聊，怎么读懂 Setup Slack 和 Hold Slack 报告。说白了，就是搞清楚你的电路到底有没有「迟到」或者「早退」。
Slack 到底是什么？
Slack，中文叫「时序裕量」。你可以把它理解成「余量」。
举个例子：你约了朋友下午 3 点见面。你 2 点 50 就到了，那你有 10 分钟的 slack。如果你 3 点 05 才到，那 slack 就是负的 5 分钟——你迟到了。
在芯片里也一样：
- Setup Slack：数据到达得太晚，超过了时钟沿的要求。这叫「建立时间违例」。
- Hold Slack：数据变化得太快，在时钟沿之后没稳住。这叫「保持时间违例」。
核心公式（记牢这两个）：
Setup Slack = 时钟周期 - (数据路径延迟 + 建立时间) + 时钟偏斜
Hold Slack = 数据路径延迟 - 保持时间 - 时钟偏斜嗯，公式看着有点枯燥。但你只要记住：Setup 看的是「最慢路径」，Hold 看的是「最快路径」。
读懂 Setup Slack 报告
我习惯先看 Setup。为什么呢？因为 Setup 违例通常更致命，直接限制你的芯片能跑多快。
一份典型的 Setup 报告，会告诉你这些信息：
| 字段 | 含义 | 我的经验 |
|---|---|---|
| Slack | 时序裕量，负值表示违例 | 看到负值别慌，先看数值大小。 -0.01ns 和 -1ns 的处理方式完全不同 |
| Data Path | 数据从起点到终点的延迟 | 这是大头，通常占了 80% 的延迟 |
| Clock Path | 时钟到达的时间 | 有时候时钟偏斜能帮你，有时候会害你 |
| Required Time | 数据必须到达的时间 | 这是你的「死线」 |
| Arrival Time | 数据实际到达的时间 | 跟 Required Time 一比较，slack 就出来了 |
举个例子，我遇到过这样一个情况：
Slack : -0.234ns
Source Clock : clk (posedge)
Destination Clock: clk (posedge)
Data Path : 3.456ns
Clock Path : 0.123ns
Required Time : 3.333ns
Arrival Time : 3.567ns你看，数据路径花了 3.456ns，但时钟周期是 3.333ns（假设 300MHz）。数据比要求晚了 0.234ns。这就是典型的 Setup 违例。
我的小技巧：看报告时，先看 Data Path 里的「最慢一段」。工具通常会标出哪一级逻辑延迟最大。我见过很多次，问题就出在一级很大的组合逻辑上——比如一个 64 位的加法器。
读懂 Hold Slack 报告
Hold 违例比 Setup 更隐蔽。为什么？因为 Setup 问题通常在低频测试时就能发现，但 Hold 问题要到高频或者特定工艺角才会冒出来。
我曾经吃过一次亏：一个设计在 slow corner 下完全没问题，结果到了 fast corner，芯片直接乱跑。查了两天才发现是 Hold 违例。
Hold 报告的结构跟 Setup 类似，但关注点不同：
| 字段 | 含义 | 注意点 |
|---|---|---|
| Slack | 同样，负值表示违例 | Hold 的负值哪怕只有 -0.001ns 也要修 |
| Data Path | 数据路径延迟 | 这里看的是「最短路径」，不是最长 |
| Clock Path | 时钟偏斜 | Hold 分析中，时钟偏斜会「帮倒忙」 |
你想想看，为什么 Hold 违例这么难抓？因为 Setup 可以通过降低频率来验证，但 Hold 跟频率无关。它只跟路径延迟有关。路径越短，越容易 Hold 违例。
避坑指南：我曾经在修 Setup 时，往路径里插了 buffer。结果 Setup 修好了，Hold 却违例了。因为 buffer 虽然增加了延迟，但也让数据路径变「快」了——嗯，这里要注意，修 Setup 和修 Hold 有时候是矛盾的。
如何快速定位问题？
拿到一份时序报告，我一般按这个顺序看：
- 先看 slack 数值：负多少？ -0.01ns 还是 -1ns？ 数值大小决定了修复难度。
- 看是哪条路径：是 reg-to-reg，还是 reg-to-output？ 不同路径的修复方法不一样。
- 看路径里的「瓶颈」：工具会列出每一级逻辑的延迟。找到最慢的那一级。
- 看时钟偏斜：有时候时钟偏斜能帮你解决 0.1ns 的违例。
说白了，读报告就是个「找茬」的过程。找到最慢的那一段，然后想办法优化它。
用一张图看懂时序分析
下面这张图，是我自己总结的时序分析流程。每次带新人，我都会先让他们看这个：
这张图的核心逻辑很简单：拿到报告 → 看 slack 正负 → 如果是负的，判断是 Setup 还是 Hold → 选择修复策略 → 重新跑 STA。循环直到收敛。
实战中的几个坑
最后分享几个我踩过的坑：
- 别只看 slack 数值：有时候 slack 是正的，但只有 0.001ns。这种「擦边球」在工艺波动下很容易翻车。我一般留 10% 的余量。
- 注意多时钟域：跨时钟域的路径，slack 报告可能会误导你。因为两个时钟的相位关系不确定。
- 伪路径要设对：我见过有人把真路径设成伪路径，结果 slack 全绿，芯片回来却跑不起来。
- Hold 违例别拖：Setup 违例可以靠降频临时解决，但 Hold 违例不行。它跟频率无关，必须修。
我的习惯：每次跑完 STA，我会把最差的 10 条路径列出来。不管 slack 是正是负，都看一眼。有时候你会发现一些「潜在风险」——比如某条路径虽然 slack 是正的，但逻辑级数特别深。这种路径在温度变化时容易出问题。
好了，关于 Setup 和 Hold 报告的解读，就聊到这儿。记住一句话：报告是死的，但解读报告的人是活的。多读、多看、多总结，你也能一眼看出问题在哪。