第二章：STA工具入门：主流STA工具介绍与SDC约束基础
各位同学，欢迎来到STA实战的第二讲。
上一章我们聊了STA的基本概念，说白了就是搞清楚芯片能不能按时序要求跑起来。今天咱们来点实在的——工具怎么用，约束怎么写。
我刚开始学STA那会儿，对着PrimeTime的界面发呆了整整一下午。后来才发现，工具其实没那么神秘，关键是你得知道它要什么，你给它什么。
2.1 主流STA工具：PrimeTime vs Tempus
目前业界主流的STA工具就两家：Synopsys的PrimeTime和Cadence的Tempus。我个人的习惯是，前端设计阶段用PrimeTime多一些，后端sign-off时两个都会跑一遍，互相验证。
PrimeTime（PT）：
- 业界黄金标准，几乎所有Foundry都认它的结果
- 支持Tcl脚本，可定制性极强
- 我遇到过最头疼的问题：PT跑出来的setup违例，在Tempus里可能不违例——嗯，这就是工具差异，你得心里有数
Tempus：
- Cadence家的产品，近几年进步很快
- 多核并行能力强，跑大设计比PT快不少
- 我曾经用Tempus跑一个500万门的模块，比PT快了将近40%
核心建议：不管用哪个工具，SDC约束文件是通用的。你只要把SDC写好了，两个工具都能跑。我个人的经验是——先把SDC搞扎实，工具只是执行者。
2.2 SDC约束文件基础
SDC（Synopsys Design Constraints）是STA的灵魂。你想想看，工具不知道你的时钟频率是多少，不知道数据什么时候来，它怎么分析？所以SDC就是告诉工具这些信息的。
最常用的几条SDC命令：
| 命令 | 作用 | 示例 |
|---|---|---|
| create_clock | 定义时钟 | create_clock -period 10 [get_ports clk] |
| set_input_delay | 定义输入延迟 | set_input_delay -max 5 -clock clk [get_ports data_in] |
| set_output_delay | 定义输出延迟 | set_output_delay -max 4 -clock clk [get_ports data_out] |
| set_max_fanout | 限制扇出 | set_max_fanout 20 [current_design] |
小技巧：写SDC时，我习惯先定义所有时钟，再定义输入输出延迟，最后加例外约束（false_path、multicycle_path等）。顺序乱了，后面查问题会很痛苦。
2.3 启动STA流程
启动STA其实就三步：读设计、读约束、跑分析。听起来简单，但每一步都有坑。
典型启动脚本（PrimeTime）：
# 第一步：读入网表和库
read_verilog ./output/top_netlist.v
read_db ./lib/slow_v1_1v08_125c.db
link_design top
# 第二步：读入SDC约束
source ./constraints/top.sdc
# 第三步：运行分析
report_timing -max_paths 10 -nworst 5 > ./reports/setup.rpt
report_timing -delay_type min -max_paths 10 > ./reports/hold.rpt我曾经犯过一个低级错误：读库文件时漏了一个memory的lib，结果PT报了一堆unresolved reference。排查了整整半天才发现是库没读全。嗯，这种坑踩过一次就记住了。
注意：启动STA前，务必确认以下几点：
- 网表是综合后的门级网表，不是RTL
- 库文件包含所有用到的标准单元和macro
- SDC中的时钟名和网表中的端口名完全一致
2.4 实战小贴士
最后分享几个我这些年积累的经验：
- SDC版本管理：每个版本的SDC都要用git管理，我见过太多人改完SDC忘了备份，结果回退不了
- 先跑小模块：别一上来就跑全芯片，先拿一个子模块验证SDC的正确性
- 看log文件：PT启动时的log里会告诉你哪些约束没认到，哪些库没找到——这些信息比report_timing还重要
好了，这一章的内容就到这里。工具和SDC是STA的左右手，缺一不可。下一章我们会深入讲解时序路径的组成，到时候你会看到setup和hold到底是怎么算出来的。
可可精品资料库