教你轻松调DCT和ICC之间Timing与Congestion的一致性
文章右侧广告为官方硬广告,与吾爱IC社区无关,用户勿点。点击进去后出现任何损失与社区无关。
转眼间,小编的公众号已经运营了一个月了,粉丝数量也有六百了。在此感谢各位的支持,小编一定会不忘初心,砥砺前行,不断分享更多干货。希望下个月本公众号粉丝数能够翻一翻,希望各位多帮忙转发宣传下,感谢还是感谢!小编开通赞赏功能后,也获得了六位童鞋的赞赏,很是激动,感谢你们(虽然没多少钱,仍然很有成就感)!
前天小编推送了数字芯片设计实现中修复 setup 违例的方法汇总,这篇文章提到了 based DCT 的综合来优化时序。由于 DCT 和 ICC 所调用的 Timing engine 不一样,因此经常会出现时序的不一致性问题。比如做 DCT 综合后,多少的 setup 违例是可以接受的,可以拿去做数字后端布局布线?如果 DCT 综合出来没有时序问题,ICC/ICC2 中时序就一定是 OK 的吗?吾爱 IC 社区的小编希望通过今天的分享,让大家快速掌握如何 Fine-tune DCT 和 ICC 之间 Timing 和 Congestion 一致性等问题。值得注意的是,今天所讨论的 topic 是基于 PT 和 ICC 间的 timing correlation 是比较一致的情况。
在研究 DCT 和 ICC timing congestion correlation 问题时,最基本的东西需要准备好,小编整理了下一些相关需要检查的 key points 以及可以改善的地方。当你发现 DCT 和 ICC 之间 timing congestion 不一致时,可以有个明确的方向,从而帮助你快速完成设计实现。
- 逻辑库是否一致
这点很简单,就是 DCT 和 ICC 中用到的 target_library(std cell ,memory,IP 等)的 db 和 ICC 中用到的 db 是否同一个版本。对于比较先进的工艺,Foundary 和 Vendor 可能会经常 update 他们的 library,特别是前期的版本,各种版本的差异性会比较大。
- 物理参考库是否一致
综合创建 library 所用的 reference library 和 Tech file 是否与 ICC 中跑 flow 用的一致
create_mw_lib -technology tech.tf -mw_reference_library $ref_libr
- 估算 net delay 的 Tluplus 文件是否设好且与 ICC 用的一致
set_tlu_plus_files -max_tluplus $cmax_tluplus -tech2itf_map $mw_star_map
- clock uncertainty 和 timing derate 是否设置合理
这个设置是调 correlation 的核心。具体要设多少,没有一个定论,每个 design 情况都不太一样。这里值得提的是 derate 的设置。DCT 和 ICC 中有必 要按照 signoff 的要求来设置吗?如果是先进工艺,foundary 往往都要求最后 signoff 时对 cell_delay,net_delay 设置一个 derate 值,而且还要分别对 launch,capture 的 data path,clock path 设置 derate。由于 DCT 中只做一个 timing 的优化和初步的 placement,所以建议综合时按照 signoff 的标准来设 derate 值,而 ICC 中考虑 runtime 和复杂性,ICC 中可以相应做一个简化即可。
- set_delay_estimation_options 是否已设置
set_delay_estimation_options \
-max_unit_horizontal_capacitance_scaling_factor 1.03 \
-max_unit_vertical_capacitance_scaling_factor 1.03 \
-max_unit_horizontal_resistance_scaling_factor 1.03 \
-max_unit_vertical_resistance_scaling_factor 1.03
- ignore_layer 是否设置正确
这个设置直接会影响到 DCT 中 congestion 的估算和优化力度
set_ignored_layer -min M2
set_ignored_layer -max M6
-
dont_use ,dont_touch 的 cell 前后要一致
-
max_cell_density_threshold 变量是否设置合理
对于高性能的 design,需要将 max_cell_density_threshold 设的高点,比如 0.85。这样 tool 在做初步 placement 时逻辑分布会相对紧凑些,从而改善 timing。但是设置的值太高了,可能会引起 congestion 的问题,如下图所示。所以如果 DCT 中的 Timing 优化的很好,而 congestion 比较严重,此时肯定不能拿去做 P&R,而是想办法优化下 congestion。
-
set_congestion_options -max_util 0.7
-
based congestion 的 cell keepout margin 或者 route guide 是否设置一致
这步也是为了解决 DCT 中或者 ICC 中看到的 congestion 而做出的优化设计 congestion 的措施。通过对某些局部区域中的 cell 设置 keepout margin 来改善 congestion 以及通过对某些区域设置 signal route guide 来优化局部的 congestion。很多从事数字 IC 设计实现的工程师会觉得 congestion 优化本来就是在布局布线阶段来做的,与综合无关。其实不然,我们今天提到的综合其实已经是物理综合,而不仅仅是逻辑综合。因此,讨论 DCT 和 ICC 的一致性问题,本身就包含 Timing 和 congestion 的问题。
- 其他的一些 option
比如 max_transition, max_cap, 控制 ICG placement 的一些 option 等。
最后,小编列举数字 IC 设计实现中常见的几种情况,供大家参考和思考。
1.DCT 中 setup(为何只谈 setup? 如果你要谈 hold,那不是瞎扯嘛)没有或者有很小的 violation,ICC 中 timing 有比较大的 setup violation
这种情况很有可能就是 DCT 中 timing 计算偏乐观,或者预留的 timing margin 不够等因素导致的。限于篇幅,这里不详细阐述。
2.DCT 中 setup 没有 violation,ICC 中也看不到 setup violation
这种情况有问题没?需要重新做综合吗?需要重新 fine-tune icc 的 flow 吗?估计不少数字工程师会觉得没问题,因为他们觉得 setup 都没问题了,肯定没问题了。可是小编告诉你,这里一定有问题。一方面 DCT 综合出来的结果,很有可能不是最优的,比如。另外一方面 ICC/ICC2 的 flow 肯定也不是最优的。ICC/ICC2 中没有 setup violation 的 database 都好意思拿去抽 RC,修 hold(最终定版),这是不可取的。
一个资深工程师的价值不在于你会些什么,而在于同样的东西,你是否可以研究的比别人深入,理解的比别人更透彻,是否可以做的比别人更好。在数字 IC 设计中,衡量设计的好坏无非就是 IC 设计中的三要素 Performance,Power,Area(PPA)。在同样的性能下,你能否做到功耗比别人做的低,能否做到面积比别人的小。这才是你的价值所在。
3.DCT 中 setup 有很大的 violation(比如 400ps),ICC 中 timing 差不多是满足时序要求
这种情况显然是 DCT 中约束过于严格,导致 setup 时序存在较大的违例。DCT 中约束过于严苛,会导致过度优化,综合出一个较大的门级电路,最终体现就是面积更大。
4.DCT 中 setup 有很大的 violation,ICC 中 setup 也有较大的 violation
这种情况留给各位思考吧
**相关文章推荐(**快来点我 ****)
Scan chain reordering 怎么用你知道吗?
数字后端实现时 congestion 比较严重,你 hold 得住吗?
Final netlist release 前,你应该做好哪些工作?
深入浅出讲透 set_multicycle_path,从此彻底掌握它
数字后端实现时 congestion 比较严重,你 hold 得住吗?
时钟树综合(clock tree synthesis)基础篇
好了,今天的内容分享就到这里。另外,因为公众号更改推送规则,小编分享的每篇干货不一定能及时推送给各位。为了避免错过精彩内容,请关注星标公众号,点击 “在看”,点赞并分享到朋友圈,让推送算法知道你是社区的老铁,这样就不会错过任何精彩内容了。
如果你想和小编有更进一步的沟通交流的机会,欢迎加入小编知识星球,让我们一起学习成长,共同进步。相信在这里能让你成就一个更完美的自己。
小编知识星球简介(如果你渴望进步,期望高薪,喜欢交流,欢迎加入 ****):
在这里,目前已经规划并正着手做的事情:
-
ICC/ICC2 lab 的编写
-
基于 ARM CPU 的后端实现流程
-
利用 ICC 中 CCD(Concurrent Clock Data)实现高性能模块的设计实现
-
基于 ARM 四核 CPU 数字后端 Hierarchical Flow 实现教程
-
时钟树结构分析
-
低功耗设计实现
-
定期将项目中碰到的问题以案例的形式做技术分享
-
基于 90nm 项目案例实现教程(ICC 和 Innovus 配套教程)
-
数字 IC 行业百科全书
吾爱 IC 社区知识星球星主为公众号” 吾爱 IC 社区” 号主,从事数字 ic 后端设计实现工作近八年,拥有55nm,40nm,28nm,22nm,14nm等先进工艺节点成功流片经验,成功tapeout 过三十多颗芯片。
这里是一个数字 IC 设计实现高度垂直细分领域的知识社群,是数字 IC 设计实现领域中最大,最高端的知识交流和分享的社区,这里聚集了无数数字 ic 前端设计,后端实现,模拟 layout 工程师们。
在这里大家可以多建立连接,多交流,多拓展人脉圈,甚至可以组织线下活动。在这里你可以就数字 ic 后端设计实现领域的相关问题进行提问,也可以就职业发展规划问题进行咨询,也可以把困扰你的问题拿出来一起讨论交流。对于提问的问题尽量做到有问必答,如遇到不懂的,也会通过查阅资料或者请教专家来解答问题。在这里鼓励大家积极发表主题,提问,从而促进整个知识社群的良性循环。每个月小编会针对活跃用户进行打赏。
最重要的是在这里,能够借助这个知识社群,短期内实现年薪百万的梦想!不管你信不信,反正已经进来的朋友肯定是相信的!相遇是一种缘分,相识更是一种难能可贵的情分!如若有缘你我一定会相遇相识!知识星球二维码如下,可以扫描或者长按识别二维码进入。目前已经有 892 星球成员,感谢这892童鞋的支持!欢迎各位渴望进步,期望高薪的铁杆粉丝加入!终极目标是打造实现本知识星球全员年薪百万的宏伟目标。
欢迎关注 “吾爱 IC 社区”
微信号:ic-backend2018