静态时序为何同时寻找最快路径和最慢路径

芯片时序报告中，最慢路径与最快路径都可能成为关注对象。只把“快”理解为好、“慢”理解为坏，会漏掉两类不同的检查问题。Synopsys《Transistor Level Static Timing Analysis with NanoTime》白皮书第2至3页，提供了理解这种区别的具体说明。本文围绕该文的路径追踪概念展开，不把它当成全部设计的签核规则。

白皮书解释，时序验证要关注信号是否来得过早或过晚。静态时序分析使用子组件延迟估计及图分析方法，寻找最慢和最快路径。这里“静态”的重点并不是电路信号不变化，而是所述工具不依赖把整个电路在所有可能输入序列下逐一动态仿真，才开始寻找这些路径。

在Path Tracing段，路径到达时序元件后，会与要求到达时间进行比较；该要求与控制这一元件的时钟信号有关。因此，判断数据到达是否合适，不能只看数据路径本身花了多少时间，还要看作为比较对象的时钟路径。这解释了为什么报告讨论的是路径之间的关系，而不只是某个元件的单一速度。

原文给出的组合很明确：检查setup时，追踪最慢、即max数据路径，并与最快时钟路径比较，以表达该项检查的最坏情况；检查hold时，则用最快、即min数据路径与最慢时钟路径比较。两项检查各自寻找不利的快慢组合，因此“只要把所有路径变快”不能从这段原理直接推出为通用结论。本文所述组合限于这份白皮书的说明，不替读者设置约束或制定修改方案。

slack也是这一比较中的量，而不是脱离目标的延迟排名。白皮书把它联系到数据路径到达时间与要求时间之间的差异，并说明正slack表示达到该路径的时序目标，负slack表示时序违例。阅读报告时，应同时识别是哪一种检查、哪一条数据路径以及对应的时间要求，再理解这个结果的意义。

对需要整理时序分析资料的读者，这一框架的用途是把“过晚”和“过早”分开，把数据路径与时钟路径分开。它讨论的是到达关系，与单独核对逻辑功能是否正确不是同一个问题。所采用白皮书段落未给出可确认的发布日期，本文也未据此比较当前软件版本；文中的解释不构成设计签核、约束设置或电路修复建议。