日志

STA: non-seq check, data-to-data check

热度 8已有 927 次阅读| 2023-12-31 08:56 |系统分类:芯片设计

后端论坛看到几个有关non-seq check, data-to-data check的帖子，有感而发，把自己知道的写下来，跟大家分享一下。

1. Non-seq check, data-to-data check从何而来

一个来源是库文件.lib。下面是一个例子。这个cell是一个特殊的DFF，同时带有复位(CDN)和置位(SDN)。

红框的意思是以SDN的rising edge为参考，对CDN是有setup要求的。翻成大白话，CDN的变化与SDN的rising edge在时间上必须有一定距离。这个概念和DFF D pin的setup是类似的。

如果这个non_seq_setup_rising不满足，工具通常会报这样的timing violation：

Path 1: VIOLATED Data To Data Setup Check with Pin u_dffsn/SDN

同理，以CDN的rising edge为基准，对SDN也是有setup要求的。

这种特殊的DFF用得非常少，这些多出来的timing check往往一开始没有注意到，等到了后端才发现，fix就比较困难了。前端应该尽可能少用特殊的cell。

Non-seq check, data-to-data check的第二个来源是SDC中的约束。下面是一个S家文档的例子。

set_data_check -from U6/DAT -to U6/EN -setup 1.0

set_data_check -from U6/DAT -to U6/EN -hold 1.0

这两句的意思是以U6/DAT的edge为参考基准，U6/EN必须：

a) 在U6/DAT的edge之前一段时间就稳定下来(non-seq setup)

b) 在U6/DAT的edge后继续维持稳定一段时间(non-seq hold)

有正版的朋友建议浏览一下参考文献4)，会有收获。

从设计角度看，这种纯粹靠delay的做法是在给后端挖坑。真心不推荐这样做。好的设计应该是很robust的，设计本身保障各个PVT下都能正确工作，而不是靠后端的魔术师玩trick。

2. Non-seq check实例一

先搭个小电路，看看Tempus是怎么分析non-seq的。

电路挺简单，第一级是个普通的DFF，第二级是个同时带有复位(CDN)和置位(SDN) 的特殊DFF。为了简单，这里的DFF都是non-scan。

为了演示non_seq，SDC里加了这两句，等于是把rst_n，pre_n的沿一起放到了cycle中间，避免了removal/recovery的干扰，同时又能暴露non-seq。

set_input_delay -clock CLK [expr 0.5*$CLK_PER] [get_ports rst_n]

set_input_delay -clock CLK [expr 0.5*$CLK_PER] [get_ports pre_n]

时钟在SDC中的定义为：

set CLK_PER 10

set CLK_HPER [expr 0.5*$CLK_PER]

create_clock -name CLK -period $CLK_PER -waveform [list 0 $CLK_HPER] [get_port clk]

先看看Tempus怎么分析non-seq setup。

这里有个特别重要的概念，non-seq, data-to-data setup check是zero-cycles，非常重要。一般datapath的setup check，launch用时钟沿N，capture用的是下一个时钟沿N+1，俗称next cycle analysis。而non-seq, data-to-data setup check用的是同一个沿！

上面这个例子里，这个时钟沿是t=0时的clk上升沿，launch和capture都用这个沿。

Launch path以t=0时钟沿为起点，加上SDC里rst_n set_input_delay (0.5)，计算出CDN arrival time 5.027。这个5.027就相当于普通setup check里的data arrival time。

Capture 用同一个时钟沿t=0为起点，加上SDC里rst_n set_input_delay (0.5)，计算出SDN的arrival time 5.015，相当于就相当于普通setup check里的capture clock arrival time。

Clock arrival time (5.015) – data arrival time (5.027) – setup requirement (0.101) - uncertainty (0.5) = -0.613。因为负值，工具报了violation。

这里还有一个小技巧 -- report_timing用了-check_type data_setup。虽然non-seq setup也属于max，report_timing -late可能最先报的是critical的data path上的setup，用-check_type data_setup精准一些。

再看看Tempus怎么分析non-seq hold。

哇，slack有9.922，惊不惊喜。仔细一看，这里有个phase shift -10.000。为什么会这样呢？再次回到non-seq zero cycles这个重要概念上。我们知道普通的setup check是next cycle analysis，而普通的hold check是same cycle analysis。而non-seq setup是zero cycle analysis，相当于same cycle，non-seq hold就变成了-1。

在上面这个例子里，launch edge仍然是t=0时的clk沿，再加上SDC里rst_n的set_input_delay，算出CDN的arrival time 5.027。

Capture edge则是从t=0时的clk沿开始，加上SDC里pre_n的set_input_delay，得到5.015，再往回退一个cycle (-10.000)，arrival time为-4.985。

Data arrival time (5.027) – clock arrival time (-4.985) – hold requirement (0.04) - uncertainty (0.050) = 9.922。

3. Non-seq check实例二

改动一下小电路，增加点趣味性，看看Tempus的non-seq STA有什么变化。

电路里加了个inverter，第一级时钟反向。第一级的输出作为第二级的复位。注意，这里为了简略仍然没有考虑DFT。如果考虑DFT，内部产生的复位也必须加上DFT mux，否则要么报DFT DRC error，要么覆盖率大打折扣。

因为第一级时钟反向，第一级的输出到第二级的复位(CDN)大致在cycle中间。为了暴露non-seq check，SDC里加了下面这句：

set_input_delay -clock CLK [expr 0.5*$CLK_PER] [get_ports pre_n]

接着看Tempus怎么分析non-seq setup，non-seq hold。

和前面的例子差不多，就不细说了。

来个惊喜。我们知道复位(CDN)和置位(SDN)之间的non-seq check是相互的。以SDN的上升沿为参考，CDN的变化相对于SDN上升沿要满足non-seq setup/hold；同样，以CDN的上升沿为参考，SDN的变化相对于SDN上升沿也要满足non-seq setup/hold。接着看Tempus是怎么分析的。

第一眼看过去，slack -10.034很刺眼。再一看，这里phase shift -10.000是主要原因。为什么会这样？

假设这是一条普通的clk上升沿到clk下降沿的datapath。做为普通datapath setup check，launch edge就是t=0的clk上升沿。根据普通setup check next edge的原则，capture edge是下一个edge，也就是t=5这个地方的clk下降沿。

前面讲过了，non-seq setup check遵循的是 setup zero cycles的原则。我们必须把普通setup check的capture edge往前移一个周期。Tempus就是这么做的，所以加了phase shift -10.000。

具体的计算是这样的。

Launch clock edge仍然是t=0时的clk上升沿。加上SDC里pre_n的set_input_delay (5), data arrival time为5.015。

Capture path源自于u_dff/CP，因为u_dff/CP的时钟有个反向，如果是普通setup check，capture edge就是t=5这个地方的clk下降沿。加上CK->Q delay，到达u_dffsn/CDN的时间是5.511。因为要遵循zero cycle原则，必须往前移一个cycle，加上phase shift -10.000，effective clock arrival time为-4.489。