1、默认情况下工具怎样进行时序分析？

如下图所示，当前时序路径只有一个时钟，在这种情况下PT是怎么去检查setup和hold的，默认情况下，PT会在下图所示的time=10去检查time=0时刻打出的数据能否被正确采样，如果下图所示的组合逻辑延时过大，不满足setup要求就会报setup 违例；同理，PT检查hold的目的是确保在time=0时刻打出的数据不会太快的传输到FF2，如果下图所示的组合逻辑延时过小，不满足hold要求就会报hold违例。

2、什么是timing exception

我们知道，在进行STA分析的时候，默认情况下，PrimeTime假设startpoint是当前时钟上升沿（下降沿）算起，而endpoint则是下一个时钟的上升沿（下降沿）；但是在实际设计中，如果对于其中的某些paths，我们不想让PT按上面所述的默认方式检查时序，那么我们需要将这些paths设定成timing exception，否则工具得到的结果将不是我们期望的。

在实际设计中，我们可以指定以下三种timing exception，具体见下表所示：

上述的timing exception命令既可以单独指定一条特定路径，也可以指定到一组相关路径上，当我们想查看当前设计中存在哪些timing exception，可以通过命令report_exception。

当我们设置了timing exception后，想重新设置或将之前设置重置可以使用reset_path命令。

2.1、 False paths

所谓的False paths就是在PT分析中，我们不需要工具去进行时序分析的路径，例如下面命令设置从pin

FFB1/CP 到pin FFB2/D的路径为false paths：

set_false_path -from [get_pins FFB1/CP] -to [get_pins FFB2/D]

设置了false path后，PT还是会计算两个pin之间的传输延时，但是并不会对其违例与否进行报告，同时会继

续优化这条数据路径上的DRC（例如max_transition,max_capcitance,max_fanout等）。

在这里需要注意的是set_false_path这条命令在PT内部是一个点对点的命令，这是与set_disable_timing命

令的区别，例如如果我们想设置通过某一pin的所有路径都不考虑时序，则可以通过set_disable_timing命令设置，例如：通过set_disable_timing [get_pins pin_name]将通过该pin的路径都设置成false。

通过下面命令我们可以将两个时钟域的路径都设置为false path：

set_false_path -from [get_clocks ck1] -to [get_clocks ck2]

2.2、 Maximum and Minimum Path Delays

默认情况下，PT是基于时钟沿去考虑最大以及最小路径延时的，如实际设计中我们需要重新定义最大最小路

径延迟，可以通过命令set_max_delay和set_min_delay设置。例如可以通过下面命令设置寄存器REGA和寄存器REGB之间的最大路径延迟为12。

set_max_delay 12 -from [get_cells REGA] -to [get_cells REGB]

通过上述命令后，PT在进行时序分析中，就会忽略时钟关系。如果上述的路径延时大于12 - setup_require，工具就会报出timing 违例，与2.1节中的默认时序分析不一样。

同理，通过下述命令可以设置寄存器REGA和寄存器REGB之间的最小路径延迟为2。同样，在工具时序分析中，如果上述的路径延时小于2 - hold_require，工具就会报timing违例。

set_min_delay 2.0 -from [get_cells REGA] -to [get_cells REGB]

2.3、Multicycle Paths

在设计中，当某条路径的延时从startpoint 到endpoint需要几个时钟周期，那么我们可以使用set_multicycle_path命令进行设置，这个时候PT也会根据命令设置去进行setup 和hold的时序检查。

例如下图所示，从FF4到FF5这条路径的延时需要在两个clk时钟周期后的上升沿进行时序检查，而默认情况下PT都是下一个时钟沿进行时序检查，固此时我们需要将这条路径设置一个timing exception即multicycle paths。当然对于上述的这个例子，对于FF4到FF5这条路径，同样可以使用set_max_delay进行约束，但是最好还是用set_multicycle_path，因为利用set_multicycle_path它会随着时钟周期自动变换，而不需要我们人为去进行干预。

set_multicycle_path -setup 2 -from [get_cells FF4] -to [get_cells FF5]

上述命令告诉PT以下图所示的clk沿关系进行setup检查，而不是默认的setup检查时序关系。

我们知道，setup检查的时序关系同时会影响hold的检查，因为hold的检查都是与有效的setup检查相关的，在上图所示的setup检查关系下，工具默认情况下的hold检查时序关系如下图所示。

这个工具默认的hold检查时序关系，也有可能并不是我们设计希望看到的，如果我们期望对上图的hold检查发生在CLK FF5的第一个时钟上升沿，那么我们同样需要设置一个timing exception命令即（当然也可以通过命令set_min_delay设置）：

set_multicycle_path -hold 1 -from [get_cells FF4] -to [get_cells FF5]

通过上述命令后，PT将会按照下图所示进行hold和setup检查。

通过上述命令的设置我们可以看出，PT对于setup和hold命令后面的options理解是不同的：

1）、对于setup那么其后面跟的数字指的是基于launch时钟沿向后延迟的时钟周期个数，不指定默认情况下该值为1；

2）、对于hold那么其后面跟的数字指的是基于当前setup得到的hold时序关系后，然后向后移动的时钟周期个数，不指定默认情况下该值为0；

• 看下面例子，如果不指定timing exception那么工具默认进行的setup检查的时序关系是setup1，hold检查是hold；如果实际设计中如果下图所示的两个DFF之间数据是缓变的话，那么我们可以通过下面命令将setup的检查延迟到下图所示的setup，那么此时hold的检查默认情况下就是hold1，如果想改变hold的检查为hold那么就需要下面两个timing exception命令。

set_multicycle_path -setup 5 -from [get_cells FF1] -to [get_cells FF2]

set_multicycle_path -hold 4 -from [get_cells FF1] -to [get_cells FF2]

3、通过上面的multicycle path的设置那么我们对setup和hold的检查分别是变严了还是变松了？

我们重新考虑上图所示的例子，重新画出其电路如下图所示，其中时钟路径的公共点到DFF1 CP端的延时为t1，到DFF2的CP端延时为t2，两个DFF之间的延时为tcomp。

那么对于setup分析而言，默认情况下，PT进行setup时序检查就是要确保下面公式满足，但是当我们通过multicycle设置了timing exception后，那么实际上就是增加了下面公式中的t_period为5*t_period，那么相当于间接放宽了两个DFF之间组合逻辑电路的延时，即对setup而言等于放宽了检查。

对于hold分析而言，默认情况下，PT进行hold时序检查就是要确保下面公式满足，那么当我们设置了setup的multicycle后，默认hold的时序关系是hold1，当我们把hold的时序关系通过multicycle设置为上图的hold后，相当于放松了对t_comp最小量约束，否则，在实际中可能需要在上图的timing path中加入过多buffers，去增加组合逻辑延迟；即通过set_multicycle_path -hold 4 -from [get_cells FF1] -to [get_cells FF2]设置后，放宽了hold检查。

最后需要说明的是，在具体的时序约束过程中，对于某些特定timing paths能不能设置成multicycle，这个完全取决于设计本身，如果在一个设计中，两个时序单元之间的数据交互不需要在每个时钟周期都变，那么此时这条路径可以设置成multicycle，当然如果这条时序路径能收下来，那么即便功能如此也不需要设置，即让工具按默认规则收时序即可。