1. 时序告警基础：什么是时序告警、为什么会产生、分类

各位同学好，我是老李。今天咱们来聊聊时序告警的基础。说实话，我见过不少工程师一看到时序告警就头大，其实这东西没那么玄乎。说白了，时序告警就是芯片设计里的“交通警察”——它告诉你，你的数据在路上跑得合不合规矩。

1.1 什么是时序告警

时序告警，简单讲就是静态时序分析（STA）工具发现你的设计不满足时序约束。嗯，这里要注意，它不是仿真报错，而是基于数学模型的检查。

我打个比方。你设计了一个寄存器，时钟上升沿来的时候，数据必须稳定。如果数据来得太晚，或者走得不够快，工具就会报告警。这就是时序告警。

我个人习惯把时序告警分成两类看：一种是“真告警”，不改设计芯片就废了；另一种是“假告警”，约束没写对或者路径不需要关心。我在项目中遇到过，有人花了两周去修一个假告警，结果发现是约束文件里多写了一个时钟。你说冤不冤？

1.2 为什么会产生时序告警

为什么会这样？原因其实就几个，我帮你捋一捋。

• 逻辑太深：组合逻辑级数太多，信号传播慢。比如你搞了个64位加法器，还串了一堆MUX，不告警才怪。
• 负载太重：一个驱动门接了太多负载，驱动能力不够。我记得有一次，一个扇出到了200多，那信号波形简直没法看。
• 时钟太快：目标频率设得太高，路径根本跑不到。你想想看，1GHz的时钟，周期才1ns，减去时钟偏斜和建立时间，留给逻辑的窗口可能就0.5ns。
• 工艺偏差：PVT（工艺、电压、温度）变化导致延迟波动。我曾经在低温下时序全过，高温下全挂，这就是温度反转效应。

1.3 时序告警的分类

时序告警主要分三类。我按重要性排个序，你心里有个数。

告警类型	检查内容	后果	修复难度
建立时间违例	数据在时钟沿前是否稳定	采样错误，功能失效	中等
保持时间违例	数据在时钟沿后是否稳定	数据被覆盖，功能失效	较难
跨时钟域告警	异步时钟域间的数据同步	亚稳态，系统崩溃	较易（但易遗漏）

1.3.1 建立时间违例

建立时间，说白了就是数据必须提前到。比如你的寄存器要求建立时间0.2ns，那数据就得在时钟沿之前0.2ns就稳定下来。

公式很简单：T_clk - T_setup - T_skew > T_logic + T_net。如果左边小于右边，就违例了。

我在项目中遇到过最夸张的建立时间违例，一条路径上串了40多级逻辑。那会儿我一看报告，slack是负的2.3ns。怎么办？插流水线呗，一级不够就两级。

1.3.2 保持时间违例

保持时间，就是数据在时钟沿之后还得待一会儿。这个跟建立时间相反，它怕数据跑得太快。

公式：T_hold + T_skew < T_logic_min + T_net_min。如果左边大于右边，数据就被冲掉了。

保持时间违例修起来比较麻烦。你想想看，数据跑太快了，你得让它慢下来。加buffer、加延迟单元，但加多了又影响建立时间。这是个平衡的艺术。

我记得有一次，一个保持时间违例修了三天。最后发现是时钟树综合时，某个寄存器的时钟偏斜太大，导致保持时间窗口被压缩了。嗯，这里要注意，保持时间违例往往跟时钟树设计有关。

1.3.3 跨时钟域告警

跨时钟域（CDC）告警，这是新手最容易忽略的。两个不同时钟域的信号直接交互，没有做同步处理，工具就会报CDC告警。

为什么会有这个问题？因为异步时钟域之间，信号到达的时间是不确定的。如果直接采样，可能采到亚稳态——就是信号既不是0也不是1，在那晃悠。

我个人的经验是，CDC告警不能只看STA报告，还得用专门的CDC工具跑一遍。我曾经在一个项目中，STA报告全绿，但CDC工具跑出来200多个告警。最后发现是跨时钟域路径没加同步器。

1.4 知识体系总览

下面这张图，我把时序告警的核心逻辑画出来了。你一看就明白。

这张图把时序告警的三大类、各自的原因和修复方法都串起来了。你保存下来，以后看时序报告的时候对着这张图，思路会清晰很多。

好了，这一章就到这里。记住，时序告警不可怕，可怕的是不知道怎么分析。下一章咱们会深入讲如何读懂时序报告，到时候我会拿一个真实的项目案例来拆解。