jake的个人空间 https://blog.eetop.cn/1592 [收藏] [复制] [分享] [RSS]

空间首页 动态 记录 日志 相册 主题 分享 留言板 个人资料

日志

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

热度 10已有 2960 次阅读| 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)

DFCSNQD1_lib_partial.png

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

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

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


同理,以CDNrising 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/DATedge为参考基准,U6/EN必须:

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

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

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

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



2. Non-seq check实例一

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

s1_schematic.png

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

为了演示non_seqSDC里加了这两句,等于是把rst_npre_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

s1_data_setup_report.png

这里有个特别重要的概念,non-seq, data-to-data setup checkzero-cycles,非常重要。一般datapathsetup checklaunch用时钟沿Ncapture用的是下一个时钟沿N+1,俗称next cycle analysis。而non-seq, data-to-data setup check用的是同一个沿!

上面这个例子里,这个时钟沿是t=0时的clk上升沿,launchcapture都用这个沿。

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

Capture 用同一个时钟沿t=0为起点,加上SDCrst_n set_input_delay (0.5),计算出SDNarrival 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也属于maxreport_timing -late可能最先报的是criticaldata path上的setup,用-check_type data_setup精准一些。


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

s1_data_hold_report.png

哇,slack9.922,惊不惊喜。仔细一看,这里有个phase shift -10.000。为什么会这样呢?再次回到non-seq zero cycles这个重要概念上。我们知道普通的setup checknext cycle analysis,而普通的hold checksame cycle analysis non-seq setupzero cycle analysis,相当于same cyclenon-seq hold就变成了-1

在上面这个例子里,launch edge仍然是t=0时的clk沿,再加上SDCrst_nset_input_delay,算出CDNarrival time 5.027

Capture edge则是从t=0时的clk沿开始,加上SDCpre_nset_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实例二

改动一下小电路,增加点趣味性,看看Tempusnon-seq STA有什么变化。

s3_schematic.png

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

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

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


接着看Tempus怎么分析non-seq setupnon-seq hold

s3_data_setup_report_SDN_ref.png

s3_data_hold_report_SDN_ref.png

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


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

s3_data_setup_report_CDN_ref.png

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

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

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

具体的计算是这样的。

Launch clock edge仍然是t=0时的clk上升沿。加上SDCpre_nset_input_delay (5), data arrival time5.015

Capture path源自于u_dff/CP,因为u_dff/CP的时钟有个反向,如果是普通setup checkcapture edge就是t=5这个地方的clk下降沿。加上CK->Q delay,到达u_dffsn/CDN的时间是5.511。因为要遵循zero cycle原则,必须往前移一个cycle,加上phase shift -10.000effective 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也是有影响的。

s3_data_hold_report_CDN_ref.png

可以看到non-seq hold过于乐观了。


可以用set_multicycle_path把这种过度的悲观去掉。

set_multicycle_path -setup -to u_dffsn/SDN 1


再看加了multicycle path约束后Tempus的报告。

s3_data_setup_report_CDN_ref_post_MCP.png

s3_data_hold_report_CDN_ref_post_MCP.png

这两个报告看上去reasonable多了。

这里要提一下,新增的MCP约束虽然只是针对-setup,实际上工具默认把hold的沿也移动了。注意:不是所有的工具都是这样的行为,最好还是report_timing确认一下。



4. Innovusnon-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网友!


10

点赞

刚表态过的朋友 (10 人)

发表评论 评论 (2 个评论)

回复 菜鸟一号 2024-1-3 15:04
大佬牛逼
回复 好吧好吧 2024-7-19 17:50
今天就碰到一个这种问题   谢谢大佬的解释

facelist

您需要登录后才可以评论 登录 | 注册

  • 关注TA
  • 加好友
  • 联系TA
  • 0

    周排名
  • 0

    月排名
  • 0

    总排名
  • 1

    关注
  • 269

    粉丝
  • 96

    好友
  • 340

    获赞
  • 293

    评论
  • 2529

    访问数
关闭

站长推荐 上一条 /1 下一条


小黑屋| 手机版| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-11-8 13:35 , Processed in 0.017679 second(s), 8 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
返回顶部