STA 签核怎样判断芯片能跑多快：EDA 入门 04
本文承接 从 RTL 到 GDS 的签核阶段。STA 的基础概念见 静态时序分析 STA 入门，报告逐行读法见 STA 报告解读；本文讲签核工具口径、输入一致性和违例回流。
一、STA 不靠激励，为什么还能“穷尽”路径
仿真只能覆盖被激励跑到的周期；STA（Static Timing Analysis，静态时序分析）把设计展开成时序图，沿时序弧静态传播 arrival time、slew 和 load，不判断逻辑值，因此能在一次运行里枚举大量路径。
它检查的是时间关系，而不是功能正确性：
- setup：数据必须在捕获沿到来前稳定足够时间；频率太高、组合逻辑太长会失败。
- hold：数据不能在同一个捕获沿之后过快变化；短路径、时钟偏斜会导致失败。
- recovery/removal：异步复位/置位释放与时钟沿之间的时序要求。
- pulse width、min period、clock gating check：脉冲宽度、周期和门控单元检查。
- max transition/capacitance/fanout：电气设计规则。
STA 通过不证明功能对；功能要靠仿真、断言、形式验证和 LEC。反过来，仿真通过也不证明所有角落时序满足。
二、签核工具的四个核心输入
| 输入 | 回答的问题 | 常见错配 |
|---|---|---|
| 网表 | 有哪些单元、pin、时序元件和连接 | 网表版本与 GDS/ECO 不一致 |
| LIB/NLDM/CCS | 单元在不同负载和转换时间下延迟多少 | max/min 库、电压温度角选错 |
| SDC | 时钟周期、相位、IO 预算、例外是什么 | 漏 generated clock、错误 false path |
| SPEF | 真实金属线的 R/C/耦合是多少 | 角点错、层级不匹配、ECO 后未重提 |
| MMMC | 哪些模式和哪些工艺角一起检查 | view 漏 corner 或时钟定义不一致 |
| OCV/AOCV/POCV | 工艺偏差如何降额 | derate 范围和版本不符合签核基线 |
三、一条 reg-to-reg 路径在算什么
setup 检查可简化为：
到达时间 = launch clock 延迟 + Tco + 数据路径延迟
要求时间 = capture clock 延迟 + 周期 - setup - uncertainty
setup slack = 要求时间 - 到达时间hold 检查使用同一个捕获沿：
到达时间 = launch clock 延迟 + Tco + 最短数据路径延迟
要求时间 = capture clock 延迟 + hold
hold slack = 到达时间 - 要求时间- setup 为负：路径太慢，常通过降频、流水线、换强单元、降负载、优化 floorplan 解决。
- hold 为负：路径太快，常在终点前加 delay buffer；修 hold 可能增加面积和功耗。
- setup 与 hold 要在多个角点同时满足，不能只盯最慢角或最快角。
- 共享时钟路径存在相反方向的重复悲观，需要 CPPR 消除共同路径悲观。
四、为什么要有“黄金签核 STA”
P&R 工具内部也有 timing engine，用于 placement、CTS 和 routing 时实时优化；但流片前通常还要用晶圆厂和项目认证的独立 STA 工具复算。原因不是“后端工具不会算”，而是签核需要独立口径：
- 认证责任：foundry 对库、RC 表、derate、POCV 文件和工具版本有签核基线；
- 交叉验证：不同引擎发现的网表/SPEF/约束错配可降低单工具风险；
- 完整 MMMC：实现阶段可能用代表性 view 加速，签核必须覆盖所有模式/角点；
- ECO 闭环：黄金 STA 生成的 ECO 回到 P&R 改版图，再重提 SPEF 复核。
签核基线不是越严格越好，而是必须与代工厂文档、库版本、RC corner、金属栈和设计模式一致。擅自加 derate 会过度修时序，擅自删 view 则可能漏违例。
五、STA 失败时的分诊顺序
| 违例形态 | 可能原因 | 优先动作 |
|---|---|---|
| 大量路径同时差一点 | 周期、uncertainty、时钟树或库角错误 | 先核对时钟和 scenario |
| 单条路径很差 | 大 mux、跨宏、高扇出、未流水 | 查 RTL/floorplan，不只 resize |
| 所有 async 路径报 setup | CDC 没设约束或元同步器识别错 | 与 CDC 方案一起评审 |
| hold 大量违例 | CTS skew、min corner、短路径 | CTS/ECO 加延迟，注意别恶化 setup |
| IO 路径违例 | IO budget/virtual clock 漏定义 | 与封装/板级时序预算对齐 |
| P&R clean、PT 违例 | SPEF/MMMC/引擎设置不一致 | 对比 view、slew、clock latency |
时序例外要少而可证。set_false_path、set_multicycle_path 必须说明是真异步、真多周期还是设计协议保证；每个例外应有 owner、评审记录和有效期。
六、从 STA 到 ECO 的闭环
一次后期修复通常按下面循环进行：
- 签核 STA 在所有 required scenario 中出违例报告；
- 按 path group、WNS/TNS、模块、时钟域聚类，避免逐条人工处理；
- 生成 ECO：换尺寸、插缓冲、移动单元、修高扇out网；
- ECO 回到 P&R 工具合法化和局部重布线；
- 重新寄生提取，得到新 SPEF；
- STA、LEC、DRC/LVS、功耗/IR 全部复核；
- 更新 waiver 与签核记录，冻结网表、约束、版图和报告版本。
不要手工直接改网表后跳过 P&R；没有物理合法化和重布线，STA 使用的 SPEF 与真实版图不一致。
常见误区
| 误区 | 更准确的理解 |
|---|---|
| STA 通过说明功能正确 | STA 只检查时序和电气规则，不管逻辑语义 |
| setup 过了就不用看 hold | hold 与频率无关，芯片一上电就可能失败 |
| false path 是清理报告的快捷方式 | 错例外会让真实违例完全漏检 |
| P&R 内 timing clean 即可流片 | 还要认证库/角点/寄生下的独立黄金 STA |
| 违例都靠插 buffer | 架构、RTL、floorplan、CTS、约束都可能是根因 |
总结
STA 签核把网表、LIB、SDC、SPEF 和 MMMC 角点组合成一张时序图，在不依赖激励的情况下检查所有模式、工艺角和路径上的 setup/hold 与电气规则；它不是实现工具里的参考报告，而是流片前可追责的时间合同。 遇到负 slack，先核对时钟、例外和版本，再讨论 buffer 或 RTL 修改；每次 ECO 后都必须让版图、寄生、STA、LEC 和物理验证重新闭环。