set_data_check用法解析(一) lib库中的data check解析-开发者社区

1. data check简介

建立时间和保持时间检查也可以在任意两个数据引脚之间进行。一个引脚为约束引脚（constrained pin），其作用类似于触发器的数据引脚，而另一个引脚为相关引脚（related pin），其作用类似于触发器的时钟引脚。这种时序检查就是我们通常所说的data check，它可以用来约束两个信号到达时间的差值。

对于两个信号之间关系的约束需求有两种方式实现：

lib库中自带的timing要求
通过约束方式实现，也就是set_data_check语法实现。

2. lib库中data check举例

先来看第1种方式，lib库中存在如下几种data check类型的timing_arc：

non_seq_setup_rising：constrained pin要比related pin的上升沿早到一定时间，类似于时钟上升沿的setup检查
non_seq_setup_falling：constrained pin要比related pin的下降沿早到一定时间，类似于时钟下降沿的setup检查
non_seq_hold_rising：constrained pin要比related pin的上升沿晚到一定时间，类似于时钟上升沿的hold检查
non_seq_hold_falling：constrained pin要比related pin的下降沿晚到一定时间，类似于时钟下降沿的hold检查
比如说，lib库中描述EFUSE hard IP的PGMEN信号必须早到于AEN信号100ns。也就是PGMEN相对于AEN信号的setup time=100ns。

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 path，path中都可能出现CK->Q的现象。
想要通过report_timing定向报datacheck类型的path，可以

report_timing-to<constrained_port>

4. Timing lib中规定的non_seq_hold_rising或者non_seq_hold_falling，PT工具会默认capture沿是上一个时钟有效沿，如下图所示：

该检查可能不符合检查意图(过于放松），因此需要根据设计的检查意图决定是否要设置Multicycle将检查沿移动至同沿，如下图所示：

移动方法为：

set_multicycle_path1-setup-to<constrained pin>

5.当lib库中的data check比较紧张，实际分析了发现可以放松时，也可以通过设置max delay或者min_delay来对data check进行timing放松，设置方法为：

set_min_delay<min_delay_value>-to<constrained pin>set_max_delay<max_delay_value>-to<constrained pin>

4. QA

Q1：在进行datacheck分析时，对于related pin，有的是non_seq_setup_rising，有的是non_seq_setup_falling，工具在timing分析时，如何判断当前信号变化是rising还是falling？
A1：同一个信号，不同的极性穿过同一个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同沿check，hold上一个launch有效沿check。
乍一看，这样就万事大吉了。但是实际上，PT工具默认的分析方法需要具体问题具体看待。对于constrained pin而言，存在两种情况：
情况1：designer的设计意图是，constrained pin到达时间要早于同拍的related pin，但是不能太早，又要晚于上一个周期的related pin。

情况2：designer的设计意图是，constrained pin到达时间要晚于同拍拍出的related pin，但是不能太晚，又要早于下一个周期的related pin。

上述两种情况都满足timing lib中data check的需求。具体需要designer来根据自己的设计意图来自行判断的。若是情况1，则不需要任何特殊exception处理，PT工具天然的分析过程即为如此。若是情况2，则需要设置mcp=1，将setup的检查沿往后挪一拍，hold的沿自动变成当拍检查。