第4章：时序报告解读
时序报告，说白了就是STA工具给你的「体检单」。我刚入行那会儿，看到PrimeTime吐出来的报告就头大——密密麻麻的数字，根本不知道看哪里。后来被老工程师带着读了几次，才慢慢摸到门道。
今天我就把自己这些年读报告的经验，掰开揉碎了讲给你听。
4.1 Slack是什么？怎么算的？
Slack，中文叫「时序余量」。它衡量的是：你的路径到底有多「紧」。
公式很简单：
Slack = 要求到达时间 - 实际到达时间如果Slack是正数，说明路径有富余，没问题。
如果Slack是负数，说明路径违例了，必须修。
关键点：Slack不是凭空来的。它取决于你设的时钟周期、时钟偏斜、以及路径上所有器件的延迟。
举个例子：你设了500MHz（周期2ns），一条路径从寄存器A到寄存器B。时钟到达A的时间是0ns，到达B的时间是0.1ns（因为有偏斜）。路径上组合逻辑加走线一共花了1.8ns。那么：
要求到达时间 = 2ns + 0.1ns = 2.1ns
实际到达时间 = 0ns + 1.8ns = 1.8ns
Slack = 2.1 - 1.8 = 0.3ns ✅嗯，这里要注意：setup slack和hold slack的计算方式不同。上面是setup的算法。hold slack是反过来的：
Hold Slack = 实际到达时间 - 要求到达时间为什么会这样？因为hold检查的是数据不能跑得太快，不能比时钟早太多到达。
4.2 读懂PrimeTime的时序报告
我个人习惯用PrimeTime的report_timing命令。它的输出结构很清晰，但新手容易看花眼。
先看一个典型报告：
****************************************
Report : timing
-path_type full_clock
-delay_type max
-max_paths 1
****************************************
Startpoint: reg_A (rising edge-triggered flip-flop clocked by clk)
Endpoint: reg_B (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type: max (setup)
Point Incr Path
---------------------------------------------------------------- ----------
clock clk (rise edge) 0.000 0.000
clock network delay (propagated) 0.200 0.200
reg_A/CK (DFFQ_X1) 0.000 0.200 r
reg_A/Q (DFFQ_X1) 0.150 0.350 r
U1/A (NAND2_X1) 0.080 0.430 r
U1/ZN (NAND2_X1) 0.120 0.550 f
U2/A (INV_X1) 0.050 0.600 f
U2/ZN (INV_X1) 0.100 0.700 r
U3/A (NAND2_X1) 0.080 0.780 r
U3/ZN (NAND2_X1) 0.110 0.890 f
reg_B/D (DFFQ_X1) 0.000 0.890 f
data arrival time 0.890
clock clk (rise edge) 2.000 2.000
clock network delay (propagated) 0.250 2.250
clock reconvergence pessimism 0.020 2.270
reg_B/CK (DFFQ_X1) 0.000 2.270 r
library setup time -0.050 2.220
data required time 2.220
---------------------------------------------------------------- ----------
data required time 2.220
data arrival time -0.890
---------------------------------------------------------------- ----------
slack (MET) 1.330读这份报告，我建议你按这个顺序来：
- 先看Slack值——正还是负？多大？
- 看Startpoint和Endpoint——哪两个寄存器之间出了问题？
- 看Path Group——属于哪个时钟域？
- 看关键路径——哪一段延迟最大？
我的小技巧：报告里Incr列是每一级的延迟，Path列是累计延迟。我一般先扫一眼Incr列，找数值最大的那几行——那就是瓶颈所在。
4.3 关键路径分析：到底谁在拖后腿？
关键路径，就是整个设计里延迟最大的那条路。它决定了你的芯片能跑多快。
我在项目中遇到过一条路径，Slack是-0.5ns。一开始以为是组合逻辑太多，结果一查，发现是走线绕了个大弯。你想想看，有时候问题不在逻辑级数，而在物理布局。
分析关键路径时，我一般关注这几个点：
- 逻辑级数——一般超过20级就要警惕了
- 扇出——一个门驱动太多负载，延迟会暴涨
- 走线延迟——后端阶段，走线延迟可能超过门延迟
- 时钟偏斜——有时候不是数据路径慢，而是时钟到达时间不一致
曾经有个坑：我遇到过一条路径，所有门延迟都很正常，但Slack就是负的。查了半天，发现是时钟树综合时把两个寄存器的时钟插入了不同的buffer，导致偏斜过大。从那以后，我每次看报告都会先瞄一眼clock network delay那两行。
4.4 Innovus的时序报告有什么不同？
Innovus是后端工具，它的时序报告和PrimeTime大同小异，但有几个地方要注意：
| 项目 | PrimeTime | Innovus |
|---|---|---|
| 报告命令 | report_timing | timeDesign -report |
| 延迟计算 | 更精确（SPEF反标） | 快速估算（RC提取） |
| 关键路径显示 | 文本为主 | GUI高亮显示 |
| 修复建议 | 不提供 | 提供ECO建议 |
说白了，PrimeTime是「裁判」，负责给出最终判决。Innovus是「运动员」，边跑边看自己的成绩。两者都要会读。
4.5 知识体系总览
下面这张图，是我自己总结的时序报告解读框架。你照着这个思路走，基本不会漏掉关键信息。
4.6 实战建议
最后，给你几个我自己的实操建议：
- 别只看最差路径——有时候TOP 10违例路径都是同一个原因造成的，修掉一个就全好了
- 关注report_timing的 -nworst 参数——我一般设成10，看前10条最差的
- 区分setup和hold——setup靠降频或优化逻辑，hold靠插buffer
- 用GUI高亮——Innovus里选中违例路径，看它在版图上的实际走线，比看文本直观得多
一个小习惯：每次跑完STA，我会把最差的5条路径截图保存。迭代优化后对比一下，看看有没有改善。这招帮我发现过好几次「修了A路径，结果B路径变差了」的连锁反应。
时序报告这东西，读多了就熟了。关键是别被数字吓到，一步一步来：先看Slack，再看路径，最后定位问题。嗯，今天就先聊到这儿。