3. 时序报告解读：slack、WNS、TNS、FEP、路径组、关键路径识别
时序报告，说白了就是STA工具给你的「成绩单」。我刚入行那会儿，看到满屏的英文和数字就头大。后来带我的老工程师说了一句话，我记到现在——「你连报告都看不懂，怎么修时序？」嗯，今天我们就来把这几个核心指标掰开揉碎了讲清楚。
3.1 核心指标：slack、WNS、TNS
这三个指标，是时序报告里最基础、也最重要的。我每次拿到新设计，第一件事就是看WNS和TNS。为什么？因为它们能告诉你这个设计「病得有多重」。
3.1.1 Slack——时序裕量
Slack，就是时序裕量。说白了，就是你的路径「还剩多少时间」。公式很简单：
Slack = 要求到达时间 - 实际到达时间如果slack是正数，说明路径满足时序。如果是负数，那就是违例了。我在项目中遇到过最夸张的一次，slack是-2.3ns，整个芯片直接没法跑目标频率。
重要概念：
- Setup Slack（建立时间裕量）：数据必须在时钟沿之前稳定。负值表示数据来得太晚。
- Hold Slack（保持时间裕量）：数据必须在时钟沿之后保持稳定。负值表示数据变化太快。
我的习惯：看报告时，先看setup slack，再看hold slack。因为setup违例通常更难修，hold违例往往可以通过加buffer解决。
3.1.2 WNS——最差负时序裕量
WNS，全称Worst Negative Slack。它代表所有违例路径中，最差的那一条的slack值。你想想看，如果最差的路径都修好了，其他路径大概率也没问题。
我曾经接手过一个项目，WNS是-500ps。团队里有人说「先修小的吧，大的慢慢来」。我坚决反对。为什么？因为最差路径往往是瓶颈，修好它，整个设计的时序压力都会缓解。
注意：WNS只告诉你最差的那条路径，但它不告诉你违例路径有多少。这就是为什么我们还需要TNS。
3.1.3 TNS——总负时序裕量
TNS，Total Negative Slack。它是所有违例路径的slack值之和。举个例子：
路径1: slack = -100ps
路径2: slack = -200ps
路径3: slack = -300ps
TNS = 100 + 200 + 300 = 600psTNS越大，说明违例路径越多或者违例越严重。我一般这样判断：
- WNS差，TNS小：只有少数几条路径有问题，集中精力修就行。
- WNS差，TNS很大：整个设计都有问题，可能需要重新考虑floorplan或约束。
3.2 FEP——前端工程化参数
FEP，全称Front End Parameter。嗯，这个名词在不同工具里叫法不太一样。但核心意思是一样的——它反映了前端设计对时序的影响。
我个人理解，FEP就是「设计的可时序收敛性」。一个设计如果FEP很差，你后端再怎么努力也白搭。我记得有一次，一个模块的FEP报告显示逻辑级数高达60级。我当时就找前端同事聊了，最后他们优化了架构，逻辑级数降到了25级，时序一下子就收敛了。
FEP关注点：
- 逻辑级数（Logic Level）
- 扇出（Fanout）
- 扇入（Fanin）
- 组合逻辑复杂度
3.3 路径组与关键路径识别
时序报告里，路径是按「路径组」来组织的。每个路径组对应一个时钟域。比如：
- clk_a组：所有以clk_a为时钟的路径
- clk_b组：所有以clk_b为时钟的路径
- input_to_reg组：输入端口到寄存器的路径
- reg_to_output组：寄存器到输出端口的路径
关键路径，就是每个路径组里slack最差的那条。怎么识别？我一般这样做：
- 先看WNS，找到最差的路径组
- 在这个组里，找到slack最差的路径
- 分析这条路径的起点、终点、组合逻辑级数
- 看是cell delay大，还是net delay大
避坑指南：我曾经只看WNS，结果修完一条路径，另一条路径变成了新的WNS。后来我学乖了——修完一条关键路径后，一定要重新跑STA，看看WNS有没有变化。
3.4 知识体系图
下面这张图，是我自己总结的时序报告解读框架。你把它记在心里，看报告就不会乱了。
3.5 实战：如何快速定位关键路径
好了，理论讲完了。我们来点实际的。假设你拿到一份时序报告，怎么快速找到关键路径？
我一般按这个步骤来：
- 看WNS：找到最差的路径组。比如WNS在clk_a组，那就先看这个组。
- 看TNS：如果TNS很大，说明这个组里有很多违例路径。如果TNS很小，可能就一两条。
- 展开最差路径：看起点、终点、组合逻辑级数、cell delay、net delay。
- 判断瓶颈：是cell delay大？还是net delay大？还是逻辑级数太多？
举个例子：
Path Group: clk_a
WNS: -250ps (Path #1)
TNS: -1200ps (共8条违例路径)
Path #1 详情：
起点：reg_A/Q
终点：reg_B/D
逻辑级数：35级
Cell delay：180ps
Net delay：70ps从上面可以看出，逻辑级数35级是主要问题。Cell delay 180ps也偏大。修复方向：要么减少逻辑级数，要么换用更快的cell。
我的经验：如果cell delay占比超过70%，优先考虑换cell。如果net delay占比超过30%，优先考虑floorplan或布线优化。
3.6 常见误区
最后，说几个我踩过的坑：
- 只看WNS，不看TNS：修完WNS，发现TNS还是很大，说明还有很多违例路径没处理。
- 忽略路径组：不同时钟域的路径不能混在一起修。每个路径组要单独分析。
- 不看FEP：如果逻辑级数本身就有问题，后端再怎么优化也有限。
嗯，时序报告解读就讲到这里。记住一句话：报告是死的，人是活的。多读、多练、多总结，你也能成为时序分析的高手。