源自：微信公众号 “数字芯片实验室”
静态时序分析时序是同步电路综合和物理实现主要考虑的因素之一。
静态时序分析在worst case检查所有可能的时序违规路径，验证设计的时序性能。 它主要考虑通过每个逻辑门的最差延迟，而不是电路的逻辑功能。与动态仿真相比，静态时序分析不需要测试向量，能更快地检查所有worst case下的时序。
时序，面积和功耗是驱动综合和物理实现。芯片设计的初衷是在最短的run time，使用最小的面积和功耗，综合出网表，然后进行布局和布线。EDA工具根据设计者设定的约束条件在速度，面积，功耗和runtime之间进行trade-offs。
芯片必须满足时序约束才能以预期的时钟速率运行，因此时序是最重要的设计约束。
静态时序分析总是在确认一个问题： “是否在所有的情况下（multi-mode multi-corner），当时钟边沿到达时，正确的数据已经存在于每个同步设备（synchronous device，例如触发器）的数据输入端？”
在图1-1中，虚线箭头表示时序路径。数据信号必须在时钟边沿从触发器FF1时钟端到触发器FF2时钟端之前传播到触发器FF2的数据端，以此来可靠地锁存数据。
图1-2显示了此路径的时序。 时钟边沿到达FF1时会锁存输入到FF1.D的数据。在触发器的CLK-to-Q延迟之后将数据放在触发器输出FF1.Q上。 这称为时序路径的launch event。
该信号以一定的延时，通过组合逻辑输出到触发器FF2的输入端FF2.D。 信号到达此处的时间称为路径的arrival time。
FF2.D的值在时钟边沿到达FF2的时钟端之前变化，至少要提前触发器的建立时间。 最小的允许到达时间称为路径required time。 FF2的数据锁存称为时序路径的capture event。
满足时序约束的时间裕量称为slack。 如果信号早于必要的时间到达，那么slack就是正的。 如果信号恰好在required time到达，则slack为零。 如果信号到达的时间晚于required time，那么slack就是负的。 在所有三种情况下，slack是required time减去arrival time。
上述时序检查称为setup检查，用于验证数据是否在时序电路的每个时钟边沿之前很快到达。 这是驱动综合和优化最多的时序检查类型。
hold检查用来验证时钟边沿到达之后，数据仍然有效的时间量。如果从launch到capture的数据路径上的组合延迟非常短，从launch时钟边沿到capture时钟边沿的延迟非常长，则可能发生hold违规。如图1-3和图1-4所示。
在图1-3中，数据时序路径从FF1到FF2具有非常短的组合延迟，由单个NAND门组成。 同时，由于存在三个缓冲器，时钟信号有很长的延迟。
图1-4显示了这种情况下的可能时序。很容易满足setup约束，因为数据在setup time之前到达。但是，因为FF2的D输入端的数据不能保持足够长的时间，所以hold约束不能满足。数据在时钟CLKB锁存之前发生变化。可以通过缩短时钟线的延迟或增加数据路径的延迟来修复这种类型的违规。
默认情况下，综合或物理实现工具仅修复setup违规，但不会修复hold违规，因为setup要求更难以满足。让工具同时修复hold违规以及setup违规，可以使用set_fix_hold命令。此命令设置指定时钟的fix_hold属性，指示工具检查并修复hold违规。
每种类型的时序检查都考虑了不同的最坏情况（worst-case conditions）。例如，一个setup检查考虑最长的组合逻辑和最慢的数据路径，以及相对于launch时钟边沿，最早的capture时钟边沿。相反，hold检查考虑最短和最快的数据路径，以及相对于launch时钟边沿最晚的capture时钟边沿。
图1-5显示了通过同一个模块不同组合逻辑路径的示例。 在数据路径中，setup检查会考虑较长的延迟（通过三个门），而hold检查将考虑较短的路径（通过两个门）。
如果觉得《java时序图工具_静态时序分析》对你有帮助，请点赞、收藏，并留下你的观点哦！
