STA系列 - 特殊时序分析 across clock domain分析/multiple clocks分析

本篇文章介绍的是跨时钟分析和多时钟域分析
本篇文章是视频笔记加上自己的感悟理解：

10-特殊时序检查-多时钟

across clock domain分析

slow to fast

从slow时钟到fast时钟的分析：
如下图所示，CLKM假如period为20ns，CLKP的period为5ns

如下图所示，默认check，setup的check位置为5ns。

如下图所示，CLKM为slow clk， CLKP为fast clk， PT将会以最严格的方式去check setup。 因此require time的起点为5ns。


通常情况下，慢时钟往往因为计算得比较慢（如果design中确实是这样的），假如我们希望是在第四个period才真正的去capture data。

fast to slow

这种case通常发生在两个时钟为同源时钟，但为不同的分频时钟。
如下图所示，从fast to slow， 对于setup check来说，选择最严格的setup，也就是setup 4.



可以看出对setup是非常严格的，如果design中不需要这么严格，可以使用multicycel去放松。

如下图所示，将**-start将launch clk的位置往前面推1个cycle，从而到10ns**的起点位置。
而hold check的位置，默认是在default launch edge的check位置为0，现在往前推1个cycle，应该是在第10ns的位置。因此，下面图中的关系是有画错的，setup的check没错，hold的check 实际上是在launch edge的位置。

注意，对于-start，指的是对以源时钟为base进行挪动，如果是-end，则是基于目的时钟为base进行挪动。

Multiple clock

整数倍的时钟关系

对于有common period的时钟，如何分析timing？
如下图所示，有公共倍数周期 20ns

如下图所示，检查最严格的setup relationship：
CLKP—>CLKM
launch edge为15ns
capture edge为20ns

非整数倍的时钟check

对于如下图所示，CLKM和CLKP并非整数倍的时钟关系：

对于存在这样的data path，取最小公倍数，比如如下 5 和 8的公倍数是40.
因此需要扩展到周期40ns。

如下图所示，我们将周期扩展到40ns，数据是从24(CLKM)—>25(CLKP)的setup最严格。如果这个时候，slack满足要求，那么其他data path一定能正确踩到。
反之如果有CLKP—>CLKM , 那么此时setup最严格只有1ns可以fix。
对于hold来说，都在0ns是最严格的。

如下图所示，是相位移动的timing check，非常类似于半周期check，对于hold time比较友好，对于setup，比较难fix。

如下图所示，对于setup来说，非常难以fix，因为require time的check时间位于0.5ns之前到来。


对于hold check来说：
如下图所示，对于atrrival time来讲，new data的冲刷会在2ns的时候才开始，也就是说新数据在2ns的时候才开始launch，而require time的时刻在0.5 ns，因此hold非常容易满足。