3、路径分析：时序路径的组成与关键路径识别
时序分析，说白了就是看信号能不能在规定时间内走完该走的路。我刚开始做STA时，总觉得这玩意儿玄乎，后来才发现——只要你把路径拆开看，一切都清清楚楚。
3.1 一条时序路径的“三段式”结构
每一条时序路径，都可以拆成三部分：
- Launch Clock Path：从时钟源到发起触发器的时钟端
- Data Path：从发起触发器的Q端到捕获触发器的D端
- Capture Clock Path：从时钟源到捕获触发器的时钟端
嗯，这里要注意——很多人只盯着data path看，忽略了clock path上的延迟差异。我在项目中遇到过好几次，明明data path算下来没问题，但时序就是不过，最后发现是clock path上的OCV（片上偏差）在作怪。
核心公式（setup检查）：
Data Arrival Time = Launch Clock Delay + Tclk2q + Data Path Delay
Data Required Time = Capture Clock Delay + Tcycle - Tsetup
Slack = Data Required Time - Data Arrival TimeSlack为正，时序通过；为负，路径违例。
3.2 Launch Clock vs Capture Clock
你想想看，同一个时钟源，分了两条路走。一条去启动数据，一条去抓取数据。这两条路的延迟差，直接决定了你的时序裕量。
| 路径类型 | 作用 | 常见问题 |
|---|---|---|
| Launch Clock Path | 决定数据何时从起点出发 | 时钟树不平衡导致延迟过大 |
| Capture Clock Path | 决定数据何时被终点捕获 | 时钟门控引入额外延迟 |
| Data Path | 数据从起点到终点的传播 | 组合逻辑级数过多、负载过重 |
我个人习惯，在分析违例路径时，先看clock path的延迟差。如果launch和capture的clock delay相差超过10%，那多半是时钟树设计有问题。
3.3 关键路径识别——别被“最长路径”骗了
很多人以为关键路径就是最长的路径。其实不然。关键路径是时序裕量最小的那条路。它可能不是最长的，但它的slack最紧。
我曾经在一个项目中，花了两天去优化一条看起来最长的路径，结果发现另一条中等长度的路径因为clock skew太大，slack反而更差。从那以后，我识别关键路径时一定会看三个指标：
- Data Path Delay：组合逻辑+线延迟
- Clock Skew：launch与capture的时钟延迟差
- Transition Time：信号上升/下降时间是否超标
避坑指南：我曾经在28nm工艺下遇到一条路径，data path delay只有2ns，但clock skew达到了0.5ns，加上transition time过大，setup slack直接为负。所以别只看data path，clock path和transition同样致命。
3.4 路径分类——STA工具怎么“看”你的设计
STA工具会把所有路径分成四类，每一类都有不同的检查方式：
- reg-to-reg路径：最典型，也是最容易分析的
- input-to-reg路径：从输入端口到触发器，受input delay约束
- reg-to-output路径：从触发器到输出端口，受output delay约束
- input-to-output路径：纯组合路径，较少见但容易忽略
我个人经验，input-to-reg和reg-to-output这两类路径最容易出问题，因为外部约束（input/output delay）往往给得不准。你想想看，前端工程师给的约束，有时候只是拍脑袋估的。
3.5 关键路径识别流程图
下面这张图，是我自己总结的关键路径识别流程。每次拿到新的违例报告，我都会按这个步骤走一遍：
⚠️ 重要提醒：不要只看最差的那条路径。我见过太多人只盯着worst slack修，结果修完一条，另一条又冒出来。建议把top 10%的违例路径都列出来，按优先级逐个处理。
3.6 实战小技巧——如何快速定位关键路径
在Primetime或Tempus里，我一般会用这几条命令：
# 列出所有违例路径，按slack排序
report_timing -nworst 50 -delay_type max
# 只看reg-to-reg路径
report_timing -from [all_registers] -to [all_registers] -nworst 20
# 查看路径的详细组成
report_timing -path_type full_clock -nworst 10嗯，这里有个小技巧——加上-path_type full_clock参数，就能看到clock path和data path的完整延迟分解。我每次分析违例路径，第一件事就是跑这个命令，看看到底是clock path拖了后腿，还是data path本身太慢。
总结一下：
- 时序路径 = launch clock + data path + capture clock
- 关键路径 ≠ 最长路径，而是slack最小的路径
- 分析时别忽略clock skew和transition time
- 用工具命令快速分解路径延迟，定位瓶颈
说白了，路径分析就是一层窗户纸。捅破了，你会发现STA其实没那么可怕。关键是养成拆解的习惯——每一条违例路径，都按launch clock、data path、capture clock三段去分析，问题自然就浮出水面了。