热度 12| |
后端论坛看到几个有关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。
Clock arrival time (-4.489) – data arrival time (5.015) – setup requirement (0.030) - uncertainty (0.5) = -10.034。
这是非常大的负值,过于悲观了,但把问题放大了,可以把不懂行的老板吓一跳,有震慑效果。
这种过度的悲观对non-seq hold也是有影响的。
可以看到non-seq hold过于乐观了。
可以用set_multicycle_path把这种过度的悲观去掉。
set_multicycle_path -setup -to u_dffsn/SDN 1
再看加了multicycle path约束后Tempus的报告。
这两个报告看上去reasonable多了。
这里要提一下,新增的MCP约束虽然只是针对-setup,实际上工具默认把hold的沿也移动了。注意:不是所有的工具都是这样的行为,最好还是report_timing确认一下。
4. Innovus与non-seq, data-to-data check有关的设置
这些都可以在UG, TCR里查到,就不展开细说了。
timing_disable_library_data_to_data_checks
timing_disable_user_data_to_data_checks
LUI: setOptMode -enableDataToDataChecks true
CUI: set_db opt_enable_data_to_data_checks true
5. 总结
总结一下。
使用同时带有同时带有复位和置位的DFF要特别小心,一开始就要意识到复位和置位之间的non-seq timing要求。没有特别强有力的理由,避免使用这种非常特殊的DFF,避免给后端造成不必要的麻烦。
如果必须使用这种特殊的DFF,或是设计中必须用到set_data_check约束,设计者要理解zero-cycle概念,最好在设计中就保证timing,在SDC里加好约束,不给后端挖坑埋雷。
参考文献
1) C家: What are data-to-data (non-sequential) timing checks
2) C家: What is data-to-data (non-sequential) timing check and how is it handled in Genus
3) C家: Innovus UG, TCR; Tempus UG, TCR
4) S家: What is the Difference Between set_data_check and Non-Sequential Library Arcs
补充1:
5# haier822网友的总结值得参考。
https://bbs.eetop.cn/forum.php?mod=viewthread&tid=961779&page=1#pid11115169
感谢haier822网友!