最近看到一篇非常好的文章，是关于一个外国团队做了不同数字芯片实现工具的效果比较，更确切的说是Cadence和Synopsys全系列的Digital Implementation工具在大规模复杂设计优化上的最终PPA结果比较。大家知道比较广义的数字芯片实现流程包括从综合到signoff的所有阶段，而这里主要比较的将是下图高亮的部分，也就是综合、DFT、PnR加上STA的部分，大致如下如所示：
而针对这些步骤，Synopsys和Cadence分别提供了全套的工具来支持：
在这里我们只讨论针对先进工艺的次世代实现工具，因此ICC和Encounter不在讨论之列。上述工具中大部分大家应该都熟悉，或者至少听说过。Fusion Compiler作为Synopsys提出的fusion技术的集大成者，将RTL2GDS流程融合到同一个工具中，并在综合和PnR中调用ICC2和DC的优化算法，旨在进一步提高PPA。而Cadence以Innovus为突破口配合Genus和Modus，已经具备完整的实现工具流程，加上QRC+Tempus已经取得台积电7nm认证，补齐可数字实现的时序signoff工具，已经具有相当实力。
为了全面对比PPA和runtime，本次对比专门设计了一个规模较大，频率较高的设计，并配合使用先进工艺来全面评估各种工具的实力。本次结果对比所使用的设计样本的基本信息如下:
针对上述设计规模和时钟频率，一共采用了几种流程来进行综合、DFT、PnR和时序signoff：
我们一起看看他们各自的表现如何：
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
相关文章
如果大家有任何后端技术与职业发展方面的问题，抑或关于数字后端感兴趣的技术话题想要了解和探讨，欢迎关注我的知乎专栏： 数字IC后端设计工程师修炼之路同时欢迎关注微信公众号：数字后端芯讲堂，一起探讨技术，共同提升!
本极术专栏也会同步更新芯片设计后端的技术干货，也请关注数字IC后端设计工程师修炼之路。
