4. 时序路径分析：建立时间（Setup）与保持时间（Hold）检查机制、关键路径识别方法

时序分析，说白了就是看你的数据能不能在时钟节拍下「稳稳地」传递。我做了这么多年后端，见过太多芯片因为时序问题翻车。有的setup违规，芯片跑不到目标频率；有的hold违规，数据直接乱掉。今天咱们就把这两个检查机制和关键路径识别方法聊透。

4.1 建立时间（Setup）检查：别让数据「迟到」

建立时间检查，核心就一句话：数据必须在时钟有效沿之前稳定下来。这个稳定时间，就是建立时间（Tsetup）。

公式其实很简单：

Tlaunch + Tck2q + Tcomb + Tsetup ≤ Tcycle + Tcapture_skew

嗯，这里要注意，Tcapture_skew是时钟到达捕获触发器的延迟减去到达发射触发器的延迟。如果时钟树做得好，这个值通常是正的，能帮你一点忙。

我在项目中遇到过最头疼的情况：一个模块的setup slack只有-20ps。查了半天，发现是综合阶段把一条关键路径的cell驱动强度选小了。换了个大驱动cell，slack直接变成+50ps。你想想看，有时候就是这点细节。

4.2 保持时间（Hold）检查：别让数据「跑太快」

保持时间检查，很多人容易忽略。它的逻辑刚好相反：数据在时钟有效沿之后，必须保持稳定一段时间。这个时间就是保持时间（Thold）。

公式长这样：

Tlaunch + Tck2q + Tcomb ≥ Thold + Tcapture_skew

说白了，就是数据不能比时钟沿「冲」得太快。如果组合逻辑太短，或者时钟偏斜太大，hold就容易出问题。

4.3 关键路径识别方法

关键路径，就是整个设计里时序最紧的那条路。我一般用STA工具跑完后，按slack排序，从最差的开始看。但光靠工具不够，你得知道怎么「找」和「看」。

4.3.1 静态时序分析（STA）方法

STA工具会遍历所有路径，计算每条路径的setup和hold slack。我个人习惯用PrimeTime或者Tempus，跑完后直接看report_timing。

# 典型的PrimeTime命令
report_timing -from [get_pins {U1/A}] -to [get_pins {U2/D}] -delay_type max -nworst 10

这个命令会输出最差的10条setup路径。我建议你重点关注：

• slack最小的路径：这是你的瓶颈
• 路径上的cell类型：是不是用了太多大延迟的cell？
• 扇出和负载：是不是某个cell驱动能力不够？

4.3.2 动态仿真辅助

STA是静态的，但有时候动态仿真也能帮你发现一些「隐藏」的关键路径。比如，某些路径只在特定数据模式下才触发。我记得有一次，STA报告所有路径都满足，但仿真时发现一个多周期路径的约束写错了。嗯，这个坑我踩过。

4.4 知识体系图：时序路径分析核心逻辑

下面这张图，是我自己总结的时序路径分析流程。你可以把它当作一个检查清单：

4.5 关键路径识别实战技巧

光知道理论不够，我给你几个实战中常用的技巧：

1. 按路径类型分组：把关键路径分成reg-to-reg、reg-to-output、input-to-reg三类，分别处理。我习惯先修reg-to-reg，因为这类路径最多。
2. 看路径的「瓶颈点」：一条路径上，往往只有1-2个cell是真正的瓶颈。用report_timing的-transition_time和-capacitance选项，能快速定位。
3. 别忽略clock path：有时候数据路径没问题，但时钟路径的延迟太大，导致setup变差。我曾经在一个项目中，把时钟树上的一个buffer换成了低阈值电压的cell，setup slack直接改善了100ps。

4.6 常见问题与避坑

问题类型	典型表现	我的建议
Setup违规	路径延迟太大，slack为负	先看是不是cell驱动强度不够，再考虑插入流水线
Hold违规	短路径上数据跑太快	插入buffer增加延迟，注意不要影响setup
时钟偏斜过大	setup和hold同时变差	重新做时钟树综合，平衡各分支延迟
约束不准确	STA结果和仿真不一致	检查SDC文件，特别是多周期路径和false path

嗯，最后说一句。时序分析不是一次性工作。从综合到布局布线，每一步都要跑STA。我习惯在每个阶段都保存一份关键路径报告，这样后期出了问题，能快速回溯。记住：时序收敛，靠的是细心和耐心。

可可精品资料库