第4章：时序报告解读——slack、transition、capacitance、clock skew、data path与clock path分析
各位同学，咱们今天聊点实在的。时序报告，说白了就是STA工具给你的一张「成绩单」。你设计做得好不好，能不能跑起来，全在这张报告里。我见过不少工程师，跑完PrimeTime，看到一堆数字就头大，直接问我「这报告到底怎么看？」。嗯，今天我就带你把这份报告从头到尾捋一遍。
4.1 先看slack——这是你的「生死线」
Slack，就是时序余量。正数代表你还有富余，负数代表你已经违规了。我个人习惯，拿到报告第一件事就是看最差的负slack（WNS，Worst Negative Slack）。
核心公式：
slack = required_time - arrival_timesetup slack为正，说明数据到得比要求早；hold slack为正，说明数据到得比要求晚。
我在项目中遇到过一种情况：WNS只有-50ps，但TNS（Total Negative Slack）却很大，达到-5000ps。这说明什么？说明不是单一路径有问题，而是整片区域都有毛病。这时候你光修一条路径没用，得从全局找原因。
我的经验：WNS在-100ps以内，通常可以通过小规模ECO修复；超过-200ps，你可能得考虑调整floorplan或者重新综合了。
4.2 Transition和Capacitance——别让信号「变形」
Transition，就是信号从0到1或者从1到0的跳变时间。Capacitance，就是负载电容。这两个参数，直接决定了你的路径延迟。
为什么会这样？你想想看，一个信号如果跳变太慢，就像一个人走路拖拖拉拉，后面的逻辑门就得等它。等来等去，setup就崩了。
| 参数 | 典型违规值 | 常见原因 |
|---|---|---|
| Transition | > 0.5ns（取决于工艺） | 驱动能力不足、线太长 |
| Capacitance | > 库文件规定的max_capacitance | 扇出太大、走线过长 |
我曾经在一个28nm的项目里，发现一条路径的transition达到了0.8ns。查了半天，原来是一个buffer驱动了32个负载。嗯，这种问题，加两级buffer树就能解决。
注意：Transition违规往往比Capacitance违规更隐蔽。因为Capacitance超标，工具会直接报DRC错误；但Transition超标，有时候只是路径延迟变大，你以为是setup问题，其实根因是transition太差。
4.3 Clock Skew——时钟的「时间差」
Clock skew，就是同一个时钟到达不同寄存器的时刻差异。说白了，时钟信号在芯片上跑，不可能同时到达每个地方，总有个先后。
我个人习惯，把clock skew分成两类：
- Positive skew：捕获时钟比发射时钟晚到。这对setup有利，对hold有害。
- Negative skew：捕获时钟比发射时钟早到。这对hold有利，对setup有害。
你想想看，如果一条路径的setup slack是负的，你可以试着让捕获时钟晚到一点，也就是引入positive skew。但别高兴太早，hold可能会因此变差。
实战技巧：在PrimeTime里，用report_timing -skew可以单独看clock skew对路径的影响。我一般会对比「with skew」和「without skew」两种情况，看看skew到底贡献了多少。
4.4 Data Path vs Clock Path——两条腿走路
一条时序路径，由两部分组成：data path和clock path。很多人只看data path，忽略了clock path，这是大忌。
Data path：从发射寄存器的Q端，经过组合逻辑，到捕获寄存器的D端。
Clock path：从时钟源，经过各种buffer、门控单元，到寄存器的CK端。
我记得有一次，一个项目的setup总是修不好。我盯着data path看了半天，延迟已经压到极限了。后来我仔细看了clock path，发现捕获时钟路径上多了一个不必要的buffer。去掉之后，skew改善了，setup也过了。
我的建议：看报告时，别只盯着data path的延迟。把clock path的延迟也列出来，看看是不是有「时钟路径过长」或者「时钟路径上插了太多东西」的问题。
4.5 实战：手把手读一份时序报告
咱们拿一个实际例子来说。假设你看到这样一段报告：
Startpoint: reg_A (rising edge-triggered flip-flop)
Endpoint: reg_B (rising edge-triggered flip-flop)
Path Group: clk
Path Type: max (setup)
Point Incr Path
------------------------------------------------------------
clock clk (rise edge) 0.0000 0.0000
clock network delay (propagated) 0.2000 0.2000
reg_A/CK (DFFQ_X1) 0.0000 0.2000 r
reg_A/Q (DFFQ_X1) 0.1500 0.3500 r
U1/Z (INV_X1) 0.0800 0.4300 f
U2/Z (NAND2_X1) 0.1200 0.5500 r
U3/Z (INV_X2) 0.0900 0.6400 f
reg_B/D (DFFQ_X1) 0.0000 0.6400 f
data arrival time 0.6400
clock clk (rise edge) 1.0000 1.0000
clock network delay (propagated) 0.2500 1.2500
reg_B/CK (DFFQ_X1) 1.2500 r
library setup time -0.0500 1.2000
data required time 1.2000
------------------------------------------------------------
data required time 1.2000
data arrival time 0.6400
------------------------------------------------------------
slack (MET) 0.5600你看，这份报告里：
- Data path延迟：0.64ns
- Clock path延迟：发射端0.20ns，捕获端0.25ns
- Clock skew：0.25 - 0.20 = 0.05ns（positive skew）
- Slack：0.56ns，完全满足
如果slack是负的，我会先看transition。比如U2/Z的transition是不是太大？再看capacitance，是不是扇出太多？最后看clock skew，是不是捕获时钟路径太长？
避坑指南：我曾经遇到一个案例，报告里slack是正的，但芯片流片回来就是跑不到目标频率。后来发现，是因为clock path上的OCV（On-Chip Variation）没考虑。所以，看报告时别忘了检查是不是用了set_clock_uncertainty，以及有没有开启OCV分析。
4.6 总结一下
时序报告解读，说白了就是四个字：追根溯源。看到负slack，别急着修，先搞清楚是data path太慢，还是clock path有问题，还是transition/capacitance拖了后腿。
我个人习惯，每次拿到报告，先看WNS和TNS，再看最差路径的transition和capacitance，最后对比clock skew。这样一圈下来，问题基本就定位了。
嗯，今天就聊到这儿。下一章咱们讲ECO修复的实战技巧，到时候我会拿几个真实案例出来，手把手教你怎么修。