4. 建立时间与保持时间：定义、检查机制与违例修复思路

各位同学，今天我们来聊聊时序分析里最核心的两个概念——建立时间与保持时间。说实话，我见过不少工程师，做了三五年设计，对这两个概念还是模模糊糊的。嗯，这其实很危险。你想想看，流片一次几百万，如果因为setup或hold违例导致芯片无法正常工作，那代价可就大了去了。

4.1 建立时间（Setup Time）的定义

建立时间，说白了就是数据在时钟有效沿到来之前，必须提前稳定下来的最短时间。为什么要有这个要求？因为寄存器内部需要时间去采样数据，就像你拍照，得先对焦再按快门，对吧？

我个人习惯把建立时间想象成一个「门槛」。数据必须在时钟沿到来前跨过这个门槛，否则寄存器就可能采到错误的值。我在项目中遇到过这样一个案例：一个高速接口的setup margin只剩了20ps，结果芯片在高温低压下频繁出错。后来查出来，就是建立时间余量不够。

4.2 保持时间（Hold Time）的定义

保持时间呢，刚好反过来。它要求数据在时钟有效沿之后，还要再稳定一段时间。为什么？因为寄存器内部采样完成后，还需要一点时间来「锁住」这个值。如果数据变化太快，刚采完就变了，那采到的值就不对了。

你可能会问：「那保持时间违例是不是比建立时间更麻烦？」嗯，我个人觉得，保持时间违例其实更棘手。因为建立时间违例可以通过降频来临时解决，但保持时间违例，你降频也没用。它跟时钟频率无关，只跟路径延迟有关。

4.3 检查机制

时序分析工具是怎么检查setup和hold的呢？我们来看看公式。

4.3.1 建立时间检查

建立时间的检查公式是这样的：

Setup Slack = Tclk + Tskew - Tcq - Tcomb - Tsetup

其中：

• Tclk：时钟周期
• Tskew：时钟偏斜（目的时钟减去源时钟）
• Tcq：寄存器时钟到输出的延迟
• Tcomb：组合逻辑延迟
• Tsetup：寄存器的建立时间要求

如果Setup Slack大于0，说明建立时间满足要求。如果小于0，那就是违例了。

4.3.2 保持时间检查

保持时间的检查公式：

Hold Slack = Tcq + Tcomb - Thold - Tskew

这里：

• Thold：寄存器的保持时间要求
• 其他参数同上

Hold Slack也必须大于0。注意，保持时间检查用的是最短路径，而不是最长路径。为什么？因为保持时间违例通常发生在数据变化太快的时候，所以我们要考虑最坏情况——数据路径最短、时钟偏斜最不利。

4.4 违例修复思路

好了，理论讲完了，咱们来点实际的。遇到违例怎么办？

4.4.1 建立时间违例修复

建立时间违例，说白了就是数据跑得太慢了。修复思路就是让数据跑快一点：

1. 插入流水线：在长路径中间加寄存器，把一个大组合逻辑拆成两段。这是最常用的方法。
2. 逻辑优化：减少组合逻辑的级数，比如把多级MUX改成并行结构。
3. 使用高速单元：把路径上的标准单元换成驱动能力更强的型号。但要注意，这会增加功耗。
4. 调整时钟偏斜：让目的时钟晚到一点，给数据更多时间。但这招要慎用，容易引发保持时间问题。
5. 降低频率：这是最后的办法，实在不行就降频吧。

4.4.2 保持时间违例修复

保持时间违例，是数据跑得太快了。修复思路就是让数据慢一点：

1. 插入缓冲器：在短路径上加buffer，增加延迟。这是最直接的方法。
2. 使用延迟单元：有些工艺库提供专门的延迟单元，比buffer更可控。
3. 调整时钟偏斜：让目的时钟早到一点，减少数据需要保持的时间。
4. 增加负载：在路径上增加扇出，也能增加延迟。

4.5 实际案例分析

我记得有一次，一个DDR控制器项目，在post-layout阶段发现了一条hold违例。路径很短，只有两个寄存器直连，中间没有任何逻辑。按理说这种路径不应该有问题，但偏偏就违例了。

查了半天，发现是时钟偏斜的问题。源寄存器的时钟比目的寄存器晚了200ps，导致数据到达后，目的寄存器的时钟已经过去了，hold时间不够。

修复方案很简单：在路径上插了两个buffer，增加了300ps的延迟。hold slack从负的50ps变成了正的250ps。嗯，搞定。

违例类型	根本原因	修复方法	注意事项
Setup违例	数据路径太长	插流水线、逻辑优化	注意流水线深度
Hold违例	数据路径太短	加buffer、延迟单元	避免影响setup
两者同时违例	时钟偏斜问题	调整时钟树	需要全局考虑

最后说一句，setup和hold其实是矛盾的。你修setup时，可能会让hold变差；修hold时，又可能影响setup。所以，做时序分析一定要有全局观，不能头痛医头、脚痛医脚。

好了，这一章就到这里。下一章我们聊聊时钟域和跨时钟域处理，那又是一个大坑。