静态时序分析（STA）流程详解：输入文件、分析步骤、输出报告
说白了，STA就是拿着你设计的网表，加上一堆时序库和约束，然后让工具去算每条路径的延迟。我刚开始做这个的时候，觉得它跟仿真差不多，后来才发现完全是两码事。仿真要靠测试向量去“试”，STA则是穷举所有路径，只要约束合理，结果就靠谱。嗯，这里我特别想强调——STA不是跑仿真，它不需要测试向量。你想想看，一个百万级的模块，仿真可能跑一整天，STA几分钟就看完了。
3.1 输入文件：你得准备哪些东西？
很多新手问我，做STA到底要准备什么文件？我一般会列出这几样：
- 门级网表：通常综合完吐出来的.v或者.vg文件。必须是展平的或者层次的，工具都要能吃进去。我个人习惯用展平网表，查问题方便，但层次网表跑得更快。
- 时序库文件：也就是.lib文件。标准单元库、IO库、宏单元库都得备齐。我遇到过最头疼的事——库文件版本不匹配，比如一个库是慢工艺一个库是快工艺，算出来的结果根本不靠谱。
- 寄生参数文件：SPEF或者SDF格式的。这是从版图里提取出来的真实RC值。没有它，STA算的就是理想互连线，根本不能反映真实情况。我曾经在项目里偷懒没提SPEF，结果流片回来时序全崩了。
- 时序约束：一般用SDC文件（Synopsys Design Constraints）。这里头定义了时钟、输入延迟、输出延迟、时序例外等等。约束写得对，STA就成功了一半。
- 工艺库（.db格式）：其实它就是.lib的编译版，工具读起来更快。
核心要点：输入文件之间是有依赖关系的。比如，时序库里的“单元”必须和网表里的“例化名”完全一致，否则工具会报unknown cell error。我吃过的亏就是库名写错了大小写，结果折腾了两天才定位到。
3.2 分析步骤：工具是怎么算的？
STA流程其实不复杂，但步骤得按顺序做。我个人总结的“五步走”流程：
- 读入设计：先把网表、库、寄生参数、约束全部喂给工具。比如PrimeTime里用
read_verilog、read_liberty、read_spef、read_sdc。 - 链接设计：工具会把网表里的例化名跟库里的单元一一对应起来。如果链接失败，多半是没找到某个库单元。
- 约束检查：工具会检查SDC约束是否合理。比如时钟定义没冲突、输入延迟没超范围。我见过最离谱的约束是把时钟周期设成了0，工具直接报“无法分析”。
- 时序分析：工具开始计算每条路径的延迟，并比较
data_arrival_time和data_required_time。如果arrival比required晚，就是setup违例；如果data变化得太晚被下一个时钟沿采到，就是hold违例。 - 报告生成：工具会输出违例报告、时序路径报告、约束覆盖率报告等等。这部分是debug的核心依据。
为什么会分成这五步？因为每一步都是后一步的前提。比如约束没检查过，后面算出来的时序结果就可能不准。我记得有个项目，约束里写错了生成时钟，结果工具根本没能正确分析快时钟域，导致忽略了一堆违例。
我的习惯：在正式跑全芯片STA之前，我会先跑一个“最小化”版本——只读一个模块的网表和约束，快速检查setup和hold。等没问题了再合并全芯片。这样能节省大量调试时间。
3.3 输出报告：你看哪些关键信息？
跑完STA，工具会吐一堆报告。但大部分报告你其实不用全看。我会重点盯这几样：
- 时序违例报告：setup和hold的违例。工具会列出violated paths，每组路径都告诉你哪里慢了、哪里快了。我会先看最严重的违例，因为那通常是关键路径。
- 最差负余量：就是WNS（Worst Negative Slack）。如果WNS是负的，说明至少有一条路径时序不满足。数字越小，问题越严重。
- 总负余量：TNS（Total Negative Slack）。所有违例路径的slack值之和。TNS大的话，说明违例路径很多，不是单点问题。
- 约束覆盖率：工具会报告你定义了哪些约束，有多少路径被覆盖了。覆盖率低于90%通常意味着有路径没被约束到。
- 时钟报告：看看你定义的时钟周期、占空比、skew是否合理。要是时钟skew太大，直接吃掉setup margin。
| 报告类型 | 关键字段 | 正常范围 | 异常处理 |
|---|---|---|---|
| setup违例报告 | slack, endpoint, data_path | slack ≥ 0 | 检查最长路径是否逻辑深、负载大 |
| hold违例报告 | slack, endpoint, clock_skew | slack ≥ 0 | 检查最短路径是否过快、skew过大 |
| 时钟报告 | period, skew, latency | skew < 周期*5% | 调整时钟树合成参数 |
| 约束覆盖率 | percentage, uncovered_paths | ≥95% | 补充缺失的约束 |
注意：
- 报告里的slack值受工艺角影响。setup要在最慢工艺角下看，hold要在最快工艺角下看。
- 我曾经遇到一个案例：setup违例报告显示slack为-0.02ns，看起来很小。但综合后发现那个违例是由寄生参数提取错误导致的，把RC值夸大了一倍。回头重新提SPEF，违例就消失了。所以报告要结合物理信息一起看。
3.4 STA整体流程框架图
下面这张图总结了STA的输入、步骤和输出。我画得比较直观，方便你对照着理解。
我一开始看到这张图会有点蒙，但后来发现，只要记住一个核心——STA其实就是在算“数据什么时候到”和“数据最晚什么时候到”。输入是材料和约束，步骤是计算和检查，输出就是告诉你哪里合格、哪里不合格。这么一想，流程就不难理解了。
小结一下：
- 输入文件准备全了，STA就跑不歪。
- 步骤按顺序执行，每一步都有意义。
- 输出报告要读懂关键指标，不要被一堆数据吓到。
好，关于STA的输入、步骤和输出，我就聊到这儿。你想想看，其实这些知识都不难，真正要花功夫的是动手去做。我建议你找个简单的模块，照着这几个步骤跑一遍，遇到报错先自己想，实在卡住了再去查资料。做多了，你就能跟我一样，看到报告就知道问题出在哪。