require time：就是时钟的采样check位置，比如说对于setup的check，那么就是check 一个period的位置。对于hold的check，就是check当前时刻，根据setup check/hold check， require time（需求时间）当然不同。
arrive time： 就是数据到达时刻，对于setup check，就是check new data到达时刻，对于hold check，也是计算new data 到达时刻，但前者是为了check数据能否正确采，后者是为了避免new data冲刷。
如下图所示，在某些设计中，比如乘法器，加法器，一个时钟无法计算输出一个稳定的结果。
如下图所示，logic需要耗时3个cycle。
如下图所示，将STA设置为3 -setup 从而放松对setup的检查。
另外，因为hold的check，默认情况下是在setup的前一个，当setup multicycle = 3的时候，那么对于hold的check 默认也就在setup的前面一个。
hold的check是为了告诉工具，数据不能在此刻位置被new data冲刷掉。
那么也就是说，数据要一直维持稳定，从launch之后就一直不能被冲掉，直到default hold check的位置。
而实际上，我们只需要数据在launch的位置去check hold violation即可，之后任意数据怎么变动。
因此需要将下面的default位置往前挪两个。
对hold的check：
如上图所示，紫色圈圈里面，本来default 位置是在period*2 为起点， 现在设置值2 -hold之后，将check位置归为0。
如果我们没有设置hold的multicycle为2
将会得到如下的结果：
如上图所示，我们可以看到require time的起点时刻为20，new 数据到达的时间在0.33，但是时钟在20.19到来。
我们希望的是new 数据的到达（冲刷时刻）时间晚一点，也就是arrive time 减去 require time。但是明显，-19.85是无法满足。
如下图所示，对于TE—>LE 的path
这种case存在于比如我们串scan，mix edge的时候
如下图所示，对于setup check：
launch 的时候，如下图，在6ns的位置launch；capture的位置是在12ns，数据需要你在11.74ns到达，然而数据在6.31ns的位置就到达了，因此，slack为5.43ns。
对于hold check：
所以如下图所示，launch的起点为6ns，data arrival time为6.31ns。
对于require time 为0.13ns，也就是说只要你new data在require time =0.13ns之后来就没关系。
从下图中，也可以看到很容易满足。
于是我们看到slack为6.18 非常容易满足。
其实想想也很简单：正是因为在LE clk之后，有足足半个周期都没有冲刷数据，直到6ns之后，才开始有launch clk打出clk去冲刷数据，所以hold当然很容易满足，然而对于setup来说其实比较难fix，因为需要fix到倍频。
如下图所示，在任何时候，scan时钟和系统时钟都不会有path，或者可以将mux/S设置为falth path
