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