3. 建立时间违例分析
建立时间违例，说白了就是数据跑得太慢，时钟来得太快。我刚开始做时序分析那会儿，看到建立时间违例就头大，总觉得是工具在跟我作对。后来摸爬滚打多了，才发现这其实是芯片设计中最常见的“老朋友”。
3.1 建立时间公式推导
我们先从最基本的公式说起。建立时间检查，核心就是看数据能不能在时钟沿到来之前稳定下来。公式长这样：
T_launch + T_clk_q + T_logic + T_setup <= T_capture + T_cycle拆开来看：
- T_launch：时钟从源头到发起触发器的延迟
- T_clk_q：触发器从时钟沿到数据输出的时间
- T_logic：组合逻辑的传播延迟
- T_setup：目标触发器的建立时间要求
- T_capture：时钟到目标触发器的延迟
- T_cycle：时钟周期
把公式移项，得到建立时间裕量：
Slack = T_capture + T_cycle - (T_launch + T_clk_q + T_logic + T_setup)嗯，这里要注意。如果 Slack 是负数，那就是违例了。我习惯把这个公式贴在工位上，每次分析违例时都对照着看，哪个变量出了问题一目了然。
核心要点：建立时间违例的本质是数据路径延迟 > 时钟周期 + 时钟偏差。说白了，就是数据没在规定时间内到达。
3.2 违例原因分析
实际项目中，建立时间违例的原因就那么几类。我一个个说。
3.2.1 组合逻辑过长
这是最常见的原因。你想想看，一个时钟周期内塞了太多级逻辑，数据自然跑不快。
我在项目中遇到过这样一个案例：一个 500MHz 的设计，某条路径上串了 40 级逻辑。算下来每级延迟 20ps，总延迟 800ps，而时钟周期才 2000ps。加上触发器和走线延迟，Slack 直接负了 300ps。
为什么会这样？说白了就是设计者图省事，把所有逻辑都堆在了一个时钟域里。我当时的做法是：
- 插入流水线寄存器，把长路径切成两段
- 每段逻辑控制在 15 级以内
- 重新综合，优化逻辑深度
我的经验：一般建议组合逻辑不超过 20 级。超过这个数，你就得考虑插寄存器了。别等到时序报告出来再改，那会儿就晚了。
3.2.2 负载过大
负载过大，说白了就是一个信号要驱动太多东西。驱动能力不够，信号上升/下降时间变长，延迟自然就大了。
我曾经碰到过一个时钟使能信号，扇出了 200 多个触发器。结果呢？这个信号的延迟比其他信号多了 500ps。整个模块的时序都崩了。
解决负载问题，我一般用这几招：
- 复制寄存器：把高扇出的信号复制几份，每份驱动一部分负载
- 插入缓冲器：在关键路径上加 buffer，增强驱动能力
- 调整综合策略：设置 max_fanout 约束，让工具自动优化
注意：复制寄存器时要注意时钟域同步问题。我曾经因为复制时钟使能信号时没处理好，导致两个副本之间出现了毛刺。嗯，那次 debug 花了我整整两天。
3.2.3 电压温度影响
这个因素容易被新手忽略。芯片在实际工作中，电压和温度是变化的。温度高了，晶体管变慢；电压低了，驱动能力下降。
我习惯用下表来评估 PVT 影响：
| 条件 | 温度 | 电压 | 延迟变化 |
|---|---|---|---|
| 最差情况 (WC) | 125°C | 0.9V | +30%~+50% |
| 典型情况 (TT) | 25°C | 1.0V | 基准 |
| 最好情况 (BC) | -40°C | 1.1V | -20%~-30% |
你看，最差情况下延迟能增加 50%。也就是说，你常温下测出来刚好满足时序的路径，到了高温低压下肯定违例。
我曾经有个设计，在 25°C 下所有路径都满足时序。结果做温度循环测试时，85°C 下直接挂了。后来一查，就是没考虑温度对组合逻辑的影响。从那以后，我每次做 STA 都强制用最差条件。
避坑指南：做建立时间分析时，一定要用最差工艺角（WC）。别想着“差不多就行”，芯片流片回来可没有后悔药吃。
3.3 知识体系总览
下面这张图是我自己总结的建立时间违例分析框架，你一看就明白了：
这张图把建立时间违例的三个主要原因和对应的解决方案都串起来了。你分析违例时，对着这张图一个个排查，基本不会漏。
我的习惯：每次拿到时序报告，我先看违例路径的 T_logic 是不是太大。如果是，优先查组合逻辑级数；如果不是，再看扇出和 PVT 条件。这个顺序帮我省了不少时间。
好了，建立时间违例的分析就讲到这里。记住，分析违例不是目的，找到根因并修复才是关键。下一节我们聊保持时间违例，那个更隐蔽，也更坑。
可可精品资料库