1. data check简介建立时间和保持时间检查也可以在任意两个数据引脚之间进行。一个引脚为约束引脚constrained pin其作用类似于触发器的数据引脚而另一个引脚为相关引脚related pin其作用类似于触发器的时钟引脚。这种时序检查就是我们通常所说的data check它可以用来约束两个信号到达时间的差值。对于两个信号之间关系的约束需求有两种方式实现lib库中自带的timing要求通过约束方式实现也就是set_data_check语法实现。2. lib库中data check举例先来看第1种方式lib库中存在如下几种data check类型的timing_arcnon_seq_setup_risingconstrained pin要比related pin的上升沿早到一定时间类似于时钟上升沿的setup检查non_seq_setup_fallingconstrained pin要比related pin的下降沿早到一定时间类似于时钟下降沿的setup检查non_seq_hold_risingconstrained pin要比related pin的上升沿晚到一定时间类似于时钟上升沿的hold检查non_seq_hold_fallingconstrained pin要比related pin的下降沿晚到一定时间类似于时钟下降沿的hold检查比如说lib库中描述EFUSE hard IP的PGMEN信号必须早到于AEN信号100ns。也就是PGMEN相对于AEN信号的setup time100ns。timing报告如下Point Incr Path ---------------------------------------------------------------------- clock sclk (rise edge) 0.000 0.000 clock network delay (propagated) 19.118 19.118 u_efuse_ctrl/pgmen_reg/CK (DRNQV1_7TV50) 0.000 19.118 r u_efuse_ctrl/pgmen_reg/Q (DRNQV1_7TV50) 5.234 24.353 r IP_CDM_DIODE_u_efuse_PGMEN/Z (BUFV2_7TV50) 1.990 26.342 r u_efuse/PGMEN (S018BCDAEFUSE_PIP064B4M_AG1) -0.043 26.299 r data arrival time 26.299 clock sclk (rise edge) 0.000 0.000 clock network delay (propagated) 17.753 17.753 clock reconvergence pessimism 1.365 19.118 clock uncertainty -0.200 18.918 u_efuse_ctrl/aen_reg/CK (DRNQV1_7TV50) 0.000 18.918 r u_efuse_ctrl/aen_reg/Q (DRNQV1_7TV50) 4.691 23.609 r IP_CDM_DIODE_u_efuse_AEN/Z (BUFV2_7TV50) 1.551 25.160 r u_efuse/AEN (S018BCDAEFUSE_PIP064B4M_AG1) -0.057 25.102 r data check setup time -100.000 -74.898 data required time -74.898 ---------------------------------------------------------------------- data required time -74.898 data arrival time -26.299 ---------------------------------------------------------------------- slack (VIOLATED) -101.197上述情况中这种情况无需我们去额外设置约束lib库都做好了。3. data check和setup/hold check的区别数据到数据的建立时间检查setup data check是在与发起沿相同的沿上执行的不同于触发器的常规建立时间检查其中捕获时钟边沿通常会距离发起时钟沿一个周期。保持时间的check(hold data check)是在发起沿的上一个沿进行的。因此数据到数据的建立时间检查setup data check也称为零周期检查zero-cycle checks或同周期检查same-cycle checks。如下图所示对于data check类型的timing报告注意这里所说的setup和hold的检查沿表示的是related data和constrained data launch的相对时间沿。data to data的check通常在timing报告中launch的path和capture的path都是data pathpath中都可能出现CK-Q的现象。想要通过report_timing定向报datacheck类型的path可以report_timing-toconstrained_port4. Timing lib中规定的non_seq_hold_rising或者non_seq_hold_fallingPT工具会默认capture沿是上一个时钟有效沿如下图所示该检查可能不符合检查意图(过于放松因此需要根据设计的检查意图决定是否要设置Multicycle将检查沿移动至同沿如下图所示移动方法为set_multicycle_path1-setup-toconstrained pin5.当lib库中的data check比较紧张实际分析了发现可以放松时也可以通过设置max delay或者min_delay来对data check进行timing放松设置方法为set_min_delaymin_delay_value-toconstrained pinset_max_delaymax_delay_value-toconstrained pin4. QAQ1在进行datacheck分析时对于related pin有的是non_seq_setup_rising有的是non_seq_setup_falling工具在timing分析时如何判断当前信号变化是rising还是fallingA1同一个信号不同的极性穿过同一个cell时其延时是不同的。其PT工具会对输入输出的信号边沿进行穷举推导选择最差的一条报出来。比如说普通的DFF其CK-Q端的timing arc有rise_edge也有fall_edge其延时是不一样的。以rise_edge分析的path为例如下所示Startpoint: launch_reg/Q (rising edge-triggered flip-flop clocked by clk) Endpoint: capture_reg/D (rising edge-triggered flip-flop clocked by clk) Path Group: clk Path Type: max (Setup Check) Point Incr Path ----------------------------------------------------------- clock clk (rise edge) 0.000 0.000 clock network delay (propagated) 0.080 0.080 launch_reg/CK 0.000 0.080 r launch_reg/Q 0.120 0.200 r # CK-Q rise delay net u_launch_to_buf 0.045 0.245 r buf0/Y 0.072 0.317 r # BUF rise delay net u_buf_to_cap 0.033 0.350 r capture_reg/D 0.000 0.350 r ----------------------------------------------------------- Data Arrival Time 0.350 clock clk (rise edge) 2.000 2.000 clock network delay (propagated) 0.080 2.080 capture_reg/CK 0.000 2.080 r library setup time 0.050 2.130 ----------------------------------------------------------- Data Required Time 2.130 Slack (MET): 1.780以fall_edge分析的path为例如下所示Startpoint: launch_reg/Q (rising edge-triggered flip-flop clocked by clk) Endpoint: capture_reg/D (rising edge-triggered flip-flop clocked by clk) Path Group: clk Path Type: max (Setup Check) Point Incr Path ----------------------------------------------------------- clock clk (rise edge) 0.000 0.000 clock network delay (propagated) 0.080 0.080 launch_reg/CK 0.000 0.080 r launch_reg/Q 0.135 0.215 f # CK-Q fall delay更大 net u_launch_to_buf 0.042 0.257 f buf0/Y 0.068 0.325 f # BUF fall delay net u_buf_to_cap 0.031 0.356 f capture_reg/D 0.000 0.356 f ----------------------------------------------------------- Data Arrival Time 0.356 clock clk (rise edge) 2.000 2.000 clock network delay (propagated) 0.080 2.080 capture_reg/CK 0.000 2.080 r library setup time 0.050 2.130 ----------------------------------------------------------- Data Required Time 2.130 Slack (MET): 1.774综上对于non_seq_setup_rising就以related data的rising edge到达时间计算对于non_seq_setup_falling就以related data的falling edge到达时间计算。Q2:有没有可能出现某个related pin又有non_seq_setup_rising检查又有non_seq_hold_rising检查需求的A2:存在。这种乍一看感觉很奇怪constrained又要比related pin晚到又要比related pin早到设计怎么实现呢这里提一句其实cell的timing lib库并不关心designer的设计意图它只关心单元cell需要满足预设的timing需求才能保证不出错。也就是timing lib的本意是对于related pin的rising edge对constrained pin规定一段不可跳变的窗口constrained pin只有在这个窗口之外跳变才能保证其function的正确性。将constrained pin的到达时间约束在一个合理范围内就可以同时满足non_seq_setup_rising和non_seq_hold_rising的需求。Cell timing lib描述的timing intent如下所示其实这种检查可以类比setup和hold的检查唯一的区别在前文提到过data check的时候setup同沿checkhold上一个launch有效沿check。乍一看这样就万事大吉了。但是实际上PT工具默认的分析方法需要具体问题具体看待。对于constrained pin而言存在两种情况情况1designer的设计意图是constrained pin到达时间要早于同拍的related pin但是不能太早又要晚于上一个周期的related pin。情况2designer的设计意图是constrained pin到达时间要晚于同拍拍出的related pin但是不能太晚又要早于下一个周期的related pin。上述两种情况都满足timing lib中data check的需求。具体需要designer来根据自己的设计意图来自行判断的。若是情况1则不需要任何特殊exception处理PT工具天然的分析过程即为如此。若是情况2则需要设置mcp1将setup的检查沿往后挪一拍hold的沿自动变成当拍检查。Q3若timing lib中只描述了non_seq_hold_rising或non_seq_hold_falling检查也是按照发起沿的上一个沿进行检查吗A3是的不管有没有定义non_seq_setup类型的检查hold的检查都是按照上一个发起沿进行的。