静态时序分析(static timing analysis)

静态时序分析（static timing analysis，STA）会检测所有可能的路径来查找设计中是否存在时序违规(timing violation)。但STA只会去分析合适的时序，而不去管逻辑操作的正确性。

其实每一个设计的目的都相同，使用Design Compiler和IC Compile来得到最快的速度，最小的面积和最少的耗能。根据设计者提供的约束，这些工具会在面积，速度和耗能上做出权衡。

更深层的来看，STA一直都寻找一个问题的答案 ： 在所有条件下，当时钟沿到达时，数据会正确地在每个同步device的输入端正确显示吗？

这问题可以用下图来表示：

如图中所示，虚线表示了时序路径。两者使用了同一个时钟驱动，理想情况下FF1的数据变化之后在下个时钟沿能够准确到达FF2。

两者的时序图如下：

在FF1的时钟沿到来时，会把FF1的D端的数据送入flip-flop。在经过一个clock-to-Q的延时之后，数据会送入FF1的Q端。此过程叫做时序路径的launch event。

信号经过了两个FF之间的组合逻辑之后，到达了组合逻辑的输出，也就是FF2的输入端(FF2.D)，这个叫做arrival time。

然而数据并不是在时钟沿到达FF2的同时到达，而是要比时钟沿早到那么一点点。早到的这个时间叫做required time，不同的device的required time不一样。

数据装载到FF2的时间点叫做capture event。

device的required time和数据到达的时间(arrival time)两者之差则叫做slack。图中所示，数据比时钟早到很多，则slack为正。如果数据刚好在required time时间点到达，则slack为0，若是数据晚到的话则是负了。

例如required time是launch event之后的1.8ns，而arrival time是launch event之后的1.6ns，则slack = 1.8-1.6=0.2ns。

以上所述的时序check又叫做 setup check，用来检测数据能否在时钟沿到来之前能够快速到达。

还有一种时序check叫做 hold check，用来检测时钟沿到达之后，数据是否能够维持一定的时间的有效状态。

下图描述了一个hold check的例子：

如图所示，FF1 FF2之间的组合逻辑很短，只有一个NAND门，与此同时在两个FF的时钟却有很长的delay。

时序图如下所示：

FF1的内容和前例一样，在launch edge时候，FF1.D的内容载入到FF1，经过clock-to-Q延时之后到达FF1.Q。 经过一个很短的组合逻辑之后(NAND gate)，数据到达了FF2.D端。此情况下setup check 很容易满足，因为数据很早就到达了FF2.D。

然而来看FF2， FF2应该在CLK信号的第二个上升沿来抓取数据，然而数据并没有在capture edge之后保持足够的时间来满足hold check，数据在延时后的CLKB的上升沿之前产生了变化，传输的数据并不是我们想要的数据。

解决此问题的方法也很简单，增加组合逻辑的延时或者减少时钟的延时。

默认情况下，综合工具会自动修复setup violation，因为setup的修复会更困难。 使用 set_fix_hold命令的话会在compile阶段中修复hold violation。

两种时序检测会考虑不同的条件。例如对于setup check来说，它会考虑组合逻辑中最长最慢的路径，还有最早的arrival time路径。而对于hold check来说，它会检测最短最快的组合逻辑路径和最晚的arrival time。

下图描述了一个路径选择的例子：

如上图，setup check会检测更长的3个门，而hold会检测更短的2个门。

而路径的种类则如下图：

· clock path: 此路径从clock input port或者cell pin开始，通过一个或多个buffer或者inverter到达时序device的clock pin来检测数据的setup 和 hold

· Clock-gating path： 此路径从clock-gating element 开始来检测clock-gating的setup和hold

· Asynchrounous path： 从input port 到一个时序element的非同步set或clear pin来检测 recovery 和 removal

· Data-to-data： 使用set_data_check命令来指定的自定义路径。