静态时序分析(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命令来指定的自定义路径。