走进Prime Time系列 - PT的constraint - 02

本篇文章介绍的详细地介绍在PT中如何下达constrain。

pre-layout constranints

如上图所示，我们需要设置的是
1、时钟周期
2、set_clock_uncertainty 包括了skew和jilter等不确定因素，同意放在uncertainty中
3、set_clock_latency 指的是network delay，也就是时钟线net的延迟。
4、set_input_delay/set_output_delay 也就是数据data到达端口的延迟delay，以及数据输出后，在端口外的延迟delay。
5、set_false_path 指的是不用去分析的false path，比如异步时钟之间，我们不需要去分析。
如上图，也就是时钟3和时钟1之间的，以及时钟2和时钟4之间的path我们都不需要计算。

关于setup的算法如上图所示：
也就是数据必须要要求在clk的capture之前多少ns到达

关于hold的算法如上图所示：
也就是数据到达reg FF2之后，数据需要保持一段时间。

对于异步的clk 3和clk 4我们无法去分析，但是clk1 和clk 2是同步的倍频关系的时钟，我们是可以分析的。

Post-Layout constrain

可以看到在post-layout中，无需再去定义时钟，uncertainty之类的参数，只需要读取sdf，然后通过set_propagated_clock就可以定义时钟。

如上图所示，通过加了选项full_clock，也就是会把latency那一部分也会报告出来。
如下图所示，当加了full_clock之后，从clock的source到reg/CP ，也就是下面红框的部分，也会被报告出来，也就是0.42，即上上图中红色的部分的0.42标记

如下是报告date require time

pre-layout&post-layout clock constrains区别

可以看到，在post-layout中，因为有真实的绕线存在，所以使用set_progated_clock即可。

clock source latency

如下图所示，我们上面定义的只是network latency，但是在外部，比如机台，我们还有source latency，我们也需要设置出来，没法预估。

如下图所示，我们也可以通过report_timing
然后看出是post-layout还是pre-layout

generated clocks

对于CRG，时钟分频器，因为工具不会内部产生clock，它只会认为这是数据，然后去分析timing path。
所以需要告诉PT，这是内部的一个时钟波形。



值得注意的是如果source时钟信息、频率之类的发生改变，那么与之关联的internal clock也会自动改变。

如上图例子，通过update_timing强制工具刷新1.5ns那一部分，所以最好是在generated clock之后update_timing

keep clock clean

clock gating

我们知道PT是去分析reg/D-->reg/Q
那现在我们要分析的是如下图所示，寄存器FF1/Q—》U1/A1
也就是说需要把U1当成一个寄存器来处理。

如下图所示，我们把Cgate当成一个reg1/Q数据输出，首先我们要求，数据需要在时钟至少0.5ns之前到来，因此建立setup时间，另外我们需要确保数据在时钟下降沿的时刻的hold时间为0.4ns，也就是在下降沿来了之后，数据仍然可以保持0.4ns。
分别对上升沿的setup要求，以及对下降沿的hold要求。
从而保证Cgate的输出是符合下图中的要求的。


如上图描述：
report_clock_gating_check 可以show出所有的clock gating check infomation
使用set_clock_gating_clock 来告诉PT工具，将ICG当成一条timing path去处理。

PVT

在得到sdf之后，然后根据PVT去跑timing

如下图所示，因为有两种不同的timing path，因此在计算的时候，为了保险起见，计算setup的时候，我就用最不利的arrive time以及最不利的require time，然后去计算，两者都是不利的，在这种情况下setup都可以满足，那么当然实际也可以满足。

CRP【clock reconvergence pessimism】

但是上述会出现一个问题，也就是说arrive time我用最差的，require time我也用最差的。但是对于上面的U1 作为common clock and data path
实际上我们计算了两次。
在我计算setup slack的时候，
那么data arrive time 我希望越迟越worst，因此，我选用0.84。
但是对于require time来说，我希望clock越快越worst，因此我选用0.64.
但是实际上，一个cell，不可能说同时取两个不同的值。因此这里需要把这个差值补充上来，这个值的我们称之为CRP【clock reconvergence pessimism】，也就是修复悲观。

set timing_remove_clock_reconvergence_pessimism true
report_timing

如上图所示：我们从report_timing中可以看到，data arrival time 中的clock network delay为1.4 (这个数值1.4是选用的最worst的值，0.8+0.6=1.4)
但是对于data require time来讲，我也会选用最worst的值，因此是1.16（0.64+0.52=1.16）
然后通过clock recovergence adjustment加回来。