wildgoat的个人空间 http://blog.eetop.cn/wildgoat [收藏] [复制] [RSS]

日志

[ZZ]Cadence or Synopsys?数字芯片实现工具大比拼!

热度 12已有 1549 次阅读2020-7-8 10:17 |个人分类:Digital|系统分类:芯片设计| 数字实现, Cadence, Synopsys, 流程, 工具, Cadence

From:https://zhuanlan.zhihu.com/p/149822832

最近看到一篇非常好的文章,是关于一个外国团队做了不同数字芯片实现工具的效果比较,更确切的说是Cadence和Synopsys全系列的Digital Implementation工具在大规模复杂设计优化上的最终PPA结果比较。大家知道比较广义的数字芯片实现流程包括从综合到signoff的所有阶段,而这里主要比较的将是下图高亮的部分,也就是综合、DFT、PnR加上STA的部分,大致如下如所示:

v2-62358054ad3163ac77fd4652236ae9b5_r.jpg

而针对这些步骤,Synopsys和Cadence分别提供了全套的工具来支持:

v2-2414101b0e985e7217ba068e0965678e_r.jpg

在这里我们只讨论针对先进工艺的次世代实现工具,因此ICC和Encounter不在讨论之列。上述工具中大部分大家应该都熟悉,或者至少听说过。Fusion Compiler作为Synopsys提出的fusion技术的集大成者,将RTL2GDS流程融合到同一个工具中,并在综合和PnR中调用ICC2和DC的优化算法,旨在进一步提高PPA。而Cadence以Innovus为突破口配合Genus和Modus,已经具备完整的实现工具流程,加上QRC+Tempus已经取得台积电7nm认证,补齐可数字实现的时序signoff工具,已经具有相当实力。

为了全面对比PPA和runtime,本次对比专门设计了一个规模较大,频率较高的设计,并配合使用先进工艺来全面评估各种工具的实力。本次结果对比所使用的设计样本的基本信息如下:

v2-df5ec3edbf9eeed0afdb66e233a7c189_r.jpg

针对上述设计规模和时钟频率,一共采用了几种流程来进行综合、DFT、PnR和时序signoff:

v2-e08265c55eb66fdc6c70e7ee49984461_r.jpg

我们一起看看他们各自的表现如何:

v2-9642d594fe0ce18a29028f75543df7f0_r.jpg

SNPS-Std: DC-> TestMAX -> ICC2 -> PT

这可以算是很长时间内业界的标准流程了,实验结果显示在runtime方面主要是DC太慢,而ICC2只能算中规中矩,因此花费了最长的时间;而由于ICC2的QoR不尽如人意,为了达成3.2GHz的目标,不得不进行多次优化迭代;PT属于标准流程,乏善可陈,但是PT-ECO的physical aware不好用,迭代次数较多,而且有些buffer竟然插到boundary外面去了,实在是让人不可思议。这个现象我倒是没遇到过,不过PT-ECO不好用确实深有体会。

SNPS-New: Fusion Compiler -> PT

在上述标准流程的结果不理想的情况下,该团队遂和Synopsys反馈他们遇到的的DC runtime和ICC2的QoR问题。Synopsys说等他们的新工具出来问题都能迎刃而解,我本人表示怀疑。而且这并不能解决现实问题,在和他们沟通的过程中,发现一共有两队人马分别开发维护DC和新工具'Descartes',后者貌似可能是DC2,但是新工具还不能开放使用,最后用Fusion Compiler来做实现,用PT来signoff。不过这个流程除了runtime,其他的竟然都是最差的。Fusion Compiler我自己也试过,后端部分基本上就是ICC2,脚本可以无缝切换,默认效果一般,此外会有一些advanced feature,不过有些需要额外的license,所以没有过多尝试。

Innovus-PT: DC-> TestMAX -> Innovus -> PT

这个流程只是把ICC2换成的Innovus,本来以为会有很多问题,但是却出奇的顺利,业界应该有不少公司在这个流程上做了大量工作和反馈,因此现阶段的流程比较成熟。Innovus在各个阶段展现都展现出了令人满意的结果,尤其是在pre-CTS阶段实现了复杂时钟树的嵌入,效果拔群。另外在Innovus实现阶段也没有开启任何advanced feature, 仅仅是比较标准的流程。基于这个流程的结果已经在Timing, Power和Runtime三个方面全面优于前面的流程,因此可以看出,根本性的差别确实出在ICC2和Innovus之间。

Innovus-Tempus: DC-> TestMAX -> Innovus -> Tempus

既然Tempus已经取得了台积电7nm认证,那么试试它也没有什么坏处。而且Cadence确认了Tempus的精度不输于PT,甚至可能更准,与Spectre的误差在3%之内。另外Cadence声称他们在所有数字工具中使用"common engines",好处之一就是可以直接在Innovus里面做Tempus ECO来加速收敛过程。我认为这里更重要的是可以不必在PnR阶段再去费时费力调correlation,或者增加额外的margin来应对PnR工具和STA工具的误差。

CDNS-All : Genus-> Modus -> Innovus -> Tempus

这里有两个大动作,一个是Genus做综合,另一个是Modus做DFT。由于设计本身的DFT电路已经放在RTL里面了,只用Modus做scan stiching就不难了。而Genus做综合的特别之处在于Cadence声称这是'true physical synthesis',即在综合早期既可以贴近Innovus的标准做placement,而结果也显示datapath上的组合逻辑确实有比较大的改善。其实Synopsys也一直想往DC里面嵌ICC2的引擎来做placement,不过目前效果都不是特别理想。这组整体上的QoR也是所有流程中最出色的,不仅完成了既定的3.2GHz目标,而且略有余量,总体功耗也最低,如此效果只能说amazing了。另外这里的RC提取换成了QRC,效果和StarRC没什么区别,不过QRT+Tempus的runtime比StarRC+PT要快1.5-2倍。

不得不说,如此结果让作为Synopsys长期用户的我吃惊不小,以前虽然双方工具都用过,也感觉得到Innovus优化方面做得更好,但是从未定性定量做过对比,也不知道实际数字上的差距如此惊人。做过后端的人都知道,100ns左右的TNS如果依靠工程师的分析,优化和调整来完全修干净是要花相当大的精力和时间的,而仅仅通过切换工具就能达成,工程师们简直不要太开心。另外也想借此机会对Synopsys提个建议:你们可长点心吧!要说ICC2被别人超越是有部分原因在于Innovus在开发和发布时机上的出奇制胜,那么作为传统护城河的DC和PT都要被攻克了,这难道不能说明问题了么?现阶段用户全部转Cadence工具的最大阻碍在于巨大的用户惯性和迁移成本,但是个人认为这种阻碍在绝对的PPA优势面前是很脆弱的。由衷期待后续双方再接再厉,再出精品,也让我们工作轻松一点。

感觉全文都在给Cadence打广告,Cadence应该给这个团队打钱,然后顺便分我一点...有兴趣读原文的请点下面链接。原文连接:http://www.deepchip.com/items/0587-01.html

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

回复 SuperLYL 2020-7-16 10:46
我们公司是C家的忠实用户
回复 mlgbb 2020-7-21 07:47
SuperLYL: 我们公司是C家的忠实用户
各有所长, 是否有个大一统的工具, 全能? 哪要工程师做什么?

facelist

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

关闭

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

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

GMT+8, 2020-8-6 08:27 , Processed in 0.033935 second(s), 8 queries , Gzip On, Redis On.

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

返回顶部