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，可以
bash
report_timing -to <constrained_port>
- Timing lib中规定的non_seq_hold_rising或者non_seq_hold_falling，PT工具会默认capture沿是上一个时钟有效沿，如下图所示：
该检查可能不符合检查意图(过于放松），因此需要根据设计的检查意图决定是否要设置Multicycle将检查沿移动至同沿，如下图所示：
移动方法为：
bash
set_multicycle_path 1 -setup -to <constrained pin>5.当lib库中的data check比较紧张，实际分析了发现可以放松时，也可以通过设置max delay或者min_delay来对data check进行timing放松，设置方法为：
bash
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 rData 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.130Data 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的沿自动变成当拍检查。
- Q3：若timing lib中只描述了non_seq_hold_rising或non_seq_hold_falling，检查也是按照发起沿的上一个沿进行检查吗？
- A3：是的，不管有没有定义non_seq_setup类型的检查，hold的检查都是按照上一个发起沿进行的。