建立&保持时间理论以及DFT中insert_chain策略&Timing思考

基础概念再捋一遍：

典型的时序模型由发起寄存器、组合逻辑和捕获寄存器3部分组成，如图1所示形成了三条时钟路径：原时钟路径（Source Clock path）、数据时钟路径（Data path）、目的时钟路径（Destination Clock path）

1 建立时间（setup）和保持时间（hold）

如图1所示，时钟上升边沿（Capture Edge 、Next Launch Edge）会将数据保存下来，但是必须要满足一定的条件：

A,建立时间Tsu：在时钟有效沿之前，数据必须保持稳定的最小时间；

B,保持时间Th：在时钟有效沿之后，数据必须保持稳定的最小时间；

这就相当于一个窗口时间，在有效边沿的窗口时间内，数据必须保持稳定；这里的时钟信号时序和数据信号时序，都是寄存器实际感受到的时序。

2 发起沿和捕获沿

如图1所示，发起沿和捕获沿通常相差一个时钟周期同时捕获沿也是下一个发起沿。

发起沿（LaunchEdge）：数据被launch的时钟边沿；也就是说，每一个启动沿，一般都会产生一个新的数据！

捕获沿（CaptureEdge）：数据被latch的时钟边沿；也就是说，每一个锁存沿，都会有一个新的数据被保存！

3 时序模型2

如图2所示：

Clk--时钟源 Rega--发起寄存器 Regb--捕获寄存器 Tclka--原时钟延时 Tclkb--目的时钟延时

Tco--发起沿有效到数据出现在发起寄存器Q端口所需时间

Tdata--数据延时（组合逻辑和走线延时） Tsu--捕获寄存器建立时间 Th--捕获寄存器保持时间

图2 时序模型2

4 数据到达时间（Data Arrival Time）

数据到达时间（Data Arrival Time）=Launch Edge +Tclka+Tco+Tdata

5 数据建立需求时间（setup）

数据建立需求时间（DataRequired Time(setup)） = Tclkb-Tsu-Clock Uncertainty

数据保持需求时间（DataRequired Time(hold)）=Tclkb +Th-Clock Uncertainty

建立时间裕量（SetupSlack）= Data Required Time(setup)-Data Arrival Time(setup)

等效：= Tck+Tskew-Tsetup-Tco-Tdata  (极限情况：考虑最慢工艺角slow_corner；最Delay max的组合逻辑；最快的CLKb)

同时clk最大频率只和setup有关。公式：Fmax=1/(Tsetup+Tdata+Tco-Tskew)

所以setup违例实在修不了，只能降频。

保持时间裕量（holdSlack）=DataRequired Time(hold)-Data Arrival Time(hold)

等效：= Tco+Tdata-Thold-Tskew（极限情况：考虑最快工艺角fast_corner；最Delay min的组合逻辑）

PR一般先保证hold违反尽量被修复clean（实际根据pr工程师经验是修不完全干净的，第一版给到DFT手里的sdf，需要我们自己理想化处理时序，即，在PT中hack_sdf.scrip脚本以加速仿真进度。）setup一般很容易修。所以后仿先保证fast_corner/best_corner_sdf先通过。

插链的策略决定设计最终的atpg的结果和scan的timing趋势，也决定最终的质量和成本问题。

1.测试成本主要取决chain_length长短和shift_clk的频率高低。

chain_length过长？？？？导致向量数爆增加

chain_length过短？？？？在channel_in&out数量一定的情况下（取决于top层分配的结果，一般无法任意更改，也限制了scan的结果，所以业界可以采用SSN架构或者和pin_mux相结合架构），导致EDT压缩比过大，效率较低，向量数增加，适得其反，也导致覆盖率降低。

所以必须try_run_atpg以找到最佳组合。一般大型设计chain_length经验值为300-350左右。

2.串chain采用mix_clk时，如果两异步时钟skew过大，导致Q到 SI的hold违反，工具一般默认插入latchup_cell来修hold，借半个周期，导致setup严格，hold放松。（这里也可以指定工具选择插入负沿reg来处理，防止两个latchup_cell 级联，容易导致时序问题），但是异步时钟分叉点可能很早，OCV过大，可能会把setup窗口全部吃掉，这样在shift_clk大于100Mhz 时，无法实现收敛时序。所以避免后仿出现问题，设计时尽量采用clk_domain来串chain。

3.occ_chain也需要考虑单独出chain（避免和其他reg混在一起，通过shift_in 值来在capture出pulse），在IO复用数量足够的情况的下，可以不让EDT压缩；一般先进工艺下大型chip，UO复用资源非常紧张，所以基本不会考虑给occ_chain留IO口，occ_chain和wrap_chain的都是要进ext_edt压缩（在模块级采用双EDT结构，缓解top层的压缩结构的效率压力）。但是也要考虑大型设计如果插入occ很多很多，导致occ_chain数量很多，也导致edt压缩结构对occ_chain的译码能力不足，难以出pat，导致覆盖率下降。

4.不同电源域的设计，根据UPF信息，根据电源域modules名，串chain，分不同chain_family。不同partion之间可能存在SCAN的连线，在低功耗设计和PD后，插入的ISO_cell导致scan_timing和后期PR处理存在难度。

5.core_chain串chain时，工具是按照一定的reg的名字字母排序等规则来串起来，并没有考虑后期pr布局布线的实际位置。大型设计本身模块可能就是狭长的布局，且想要实现shift_clk在100Mhz以上的高频，链首和链尾隔的很远，EDT_channel口子上打拍又无法兼顾所有的扫描链，为了时序收敛，需要对首尾插寄存器打拍处理。同时chain中也可能存在打拍的情况。所以在DFT设计完成后需要提供SCAN_EDF信息给PR参考。

 

6.为了解决后期func_eco插入的reg对原来已经balance_chain的干扰（导致chain_length改变，按照最长chain_length来计算，浪费cycles，导致shift_time变大；同样考虑ip_chain集成时，要知道ip-chain的max_length；同样在设计wrap_chain_length时，要保证length小于core_chain_length ），在串chain之前设计几条eco_chain，每条chain上挂1-2个dummy_reg（由mini_occ_clk或者专用OCC_clk来驱动）。后期eco来的reg就可以挂在这些eco_chain上。

7.对于ip_chain的集成，首先要清晰：ip_chain_length？shift_period是否和自身模块的shift_timing一致？ip_chain链首是负沿reg？（若是负沿reg，无需处理；若是正延，则需要预埋latch—cell）链尾是否加了latctup_cell？

同时考虑测试时ip_chain对core_chain的干扰，需要加bypass结构。

8.对于一个既定的设计，逻辑量决定了pat很难优化，此时为了降低测试时间，依靠scan_shift的提频主要分两部分：一、scan_channel和inter_chain的pipeline_cell打拍；二、采用自研的硬件解决方案（scan_icg_tp_ip和rst_tp_ip接管，已经经过多款大型实际芯片流片验证）。