一、告警基础：什么是时序告警、告警的分类与解读
各位同学好，我是老李。做芯片设计十几年了，今天咱们聊聊时序告警。说实话，我刚入行那会儿，看到STA报告里一堆红色告警，心里就发怵。后来踩的坑多了，慢慢就摸清了门道。
时序告警是什么？说白了，就是工具告诉你——你设计的电路，在某个路径上，信号跑得不够快，或者跑得太快了。不够快就是setup违例，太快了就是hold违例。嗯，就这么简单。
核心概念：时序告警是静态时序分析（STA）工具在检查设计时序约束时，发现的不满足要求的路径。它直接告诉你：芯片能不能在目标频率下正常工作。
1.1 告警的分类
我个人习惯把时序告警分成三大类。你想想看，这样分类后，定位问题会清晰很多。
| 告警类型 | 英文名称 | 本质问题 |
|---|---|---|
| 建立时间违例 | Setup Violation | 数据到达太晚，时钟捕获太早 |
| 保持时间违例 | Hold Violation | 数据变化太快，时钟捕获太晚 |
| 时钟门控检查 | Clock Gating Check | 门控信号与时钟沿的时序关系不满足 |
建立时间违例，这是最常见的。我在项目中遇到过最夸张的一次，一条路径的setup slack是负的500ps。当时整个团队都慌了，后来发现是综合时约束写错了。setup违例的本质是：数据从起点寄存器出发，经过组合逻辑，到达终点寄存器时，已经超过了时钟沿允许的最晚到达时间。
保持时间违例，这个比较隐蔽。我记得有一次流片回来，芯片在低温下工作异常，查了两个月才发现是hold违例。hold违例的意思是：数据变化太快，在时钟沿之后还没稳定住，就被下一个时钟沿捕获了。说白了就是数据跑得太快，hold不住。
时钟门控检查，这个很多新手容易忽略。时钟门控（clock gating）是现代芯片降低功耗的常用手段。但门控使能信号必须在时钟沿前后保持稳定，否则会产生毛刺。我曾经因为一个门控检查没修干净，导致芯片在特定场景下功能紊乱，排查了整整一周。
1.2 告警信息的解读
拿到一份STA报告，怎么看？我教你一个方法，三步走。
- 看违例类型：是setup还是hold？这决定了你的修复方向完全不同。
- 看slack值：负多少？-10ps和-500ps的严重程度天差地别。
- 看路径起点和终点：从哪个寄存器到哪个寄存器？中间经过了什么逻辑？
举个例子，一条典型的setup违例报告长这样：
Startpoint: u_core/u_reg1/Q (rising edge-triggered flip-flop clocked by clk)
Endpoint: u_core/u_reg2/D (rising edge-triggered flip-flop clocked by clk)
Path Group: clk
Path Type: max (setup)
Point Incr Path
-----------------------------------------------------------
clock clk (rise edge) 0.0000 0.0000
clock network delay (propagated) 0.2000 0.2000
u_core/u_reg1/Q (reg) 0.1500 0.3500 r
u_core/nand2_inst/ZN (nand2) 0.1200 0.4700 f
u_core/inv_inst/ZN (inv) 0.0800 0.5500 r
u_core/buf_inst/Z (buf) 0.1000 0.6500 r
u_core/u_reg2/D (reg) 0.0000 0.6500 r
data arrival time 0.6500
clock clk (rise edge) 1.0000 1.0000
clock network delay (propagated) 0.2000 1.2000
clock uncertainty -0.0500 1.1500
u_core/u_reg2/D (setup time) -0.0300 1.1200
data required time 1.1200
-----------------------------------------------------------
data required time 1.1200
data arrival time -0.6500
-----------------------------------------------------------
slack (MET) 0.4700
小技巧：看报告时，重点关注两个数字——data arrival time和data required time。前者是数据实际到达的时间，后者是数据最晚必须到达的时间。slack = required - arrival。正值表示满足，负值表示违例。
上面这个例子slack是正的0.47ns，说明这条路径是满足的。如果slack是负的，比如-0.15ns，那就需要修了。
1.3 告警的严重程度
不是所有告警都需要修。我个人有个经验法则：
- slack > -10ps：可以忽略，工具精度误差范围内
- -50ps < slack < -10ps：建议修，但不紧急
- slack < -50ps：必须修，否则芯片大概率出问题
注意：这个经验值不是的。如果芯片工作频率很高（比如5GHz以上），或者工艺节点很先进（比如5nm以下），那-10ps的违例也可能致命。我曾经在7nm项目上，-5ps的hold违例都导致芯片在高温下失效。
1.4 知识体系总览
下面这张图，是我自己总结的时序告警知识体系。你把它记在脑子里，后面学起来会轻松很多。
这张图把时序告警的核心内容都串起来了。从上到下，先搞清楚告警分哪几类，再学会怎么解读报告，最后知道什么程度的违例需要处理。嗯，这就是本章要掌握的全部内容。
我的建议：刚开始学STA的同学，别急着去修违例。先把报告读明白，搞清楚每条告警说的是什么。我见过太多人，拿到报告就盲目插buffer、调size，结果越修越糟。读懂告警，是修复的第一步，也是最重要的一步。
好了，关于时序告警的基础知识就讲到这里。记住，告警不可怕，可怕的是看不懂告警。下一节我们聊聊setup违例的具体修复方法，到时候我会拿一个真实项目中的案例来讲解。
可可精品资料库