这个项目最重要的模块就交给你了！
不然项目组那里不好交代，是吧？
你就要被搞了！
随着摩尔定律持续演进，更高性能、低成本的电子产品利益了全人类。
大家都知道手机上可以吃鸡了，AI芯片可以下围棋了……
早在六年前，S就意识到这个挑战，即刻决定投资一个持续数年的项目，目标是要建立一个全新的数字设计平台。 在2018年底推出了成品，也就是今天的Fusion Compiler。作为史上第一且唯一RTL-to-GDSII全流程工具，迅速在业内被大规模采用，它基于单一数据库模型的设计平台，共享数据库让平台上所有的综合引擎，物理引擎，优化引擎，还有机器学习延伸出来的方法，在整个平台上任何一个环节上都可以自由启用，达到更高层次的PPA……（此处略去1000字）
说了这么多，但是，本公众号却迟迟没有写点Fusion Compiler相关的文章。为啥哩？
首先是因为我心里发虚。最近一年我都在做Machine Learning相关的东西，没有啥机会跑FC。看到同事们天天跑FC，跑一个，成功一个，恨的我牙痒痒的。然并卵，老板还是没有给我机会做FC。所以，以我有限的FC经验来写FC的文章，真的有些发虚，怕把一个好好的技术给讲错了。
其次是同事们太忙了，跟好几个FC专家约过稿，但未果。跟我说现在FC的engagement太多，忙不过来呀。耽误了他的engagement就是耽误他promotion的机会。我靠，都这么说了，我就不好意思再催稿了。只能祝你们早日升principle，scientist，fellow，CEO……
然而时不我待，等大家都会用FC之后，再写FC的文章就意义不大了。所以，得硬着头皮，来写点FC的东西，希望对大家有用。水平有限，错误难免，请多多包涵！
FC 是Fusion Compiler的简称，是
单个工具，能完成综合和布局布线
。
即输入RTL，输出GDS，故称RTL2GDS的工具。
个人理解，FC是芯片逻辑综合历史上的第三次工业革命。第一次是Synopsys发明的DC，用工具来做综合；第二次是十多年前的DCT/DCG的出现，即带物理信息的综合，大大的提高了综合的质量，让普通的公司做高频设计不再是梦想。第三次就是FC的出现，不仅把综合和布局布线融合在一起，还引入了大量新的技术，再一次大大的提升了芯片的QoR和设计周期！
● 单个工具里完成综合、布局和布线， 统一的UI和数据库
● 和ICC2完全兼容的command，app option和database
● 其他各种先进feature。比如无缝整合StarRC跟PrimeTime的引擎；CCD everywhere；DPS for better IR Drop
FC的流程可简单分为三步：
重点在第一步compile_fusion，第二步和第三步与ICC2的流程基本一样。
第一步compile_fusion是做综合和布局。其包含了若干子步骤，包括逻辑映射，逻辑初步综合，place，带物理信息的综合，pre-route 优化，legalization等等。compile_fusion结束后，是一个已经做好place和legalize的database，可以直接做CTS了。
要注意的是：
●
DFT的插入也是在compile_fusion里完成的。
●
我们也可以简单理解，FC的compile_fusion是把DCG的综合和ICC2 的place两者融合在一起了。注意，这么表达是为了好理解，实际上FC绝不是把两者合在一起这么简单！
●
FC里的综合和布局不再是独立的两个步骤了，而是融合在一起，你中有我，我中有你。双剑合璧，玉女心经……
FC采用和ICC2一模一样的ndm的database，和ICC2完全兼容。
我们看看过去，以前的流程是DCG+ICC2，或者更先进点的DC-NXT + ICC2。这套经典流程是物理综合和P&R分开来做，一般也是两个team来做的。在过去10年中，被产业界广泛使用。然而再好的东西，也有被超越的一天。因为它在先进工艺、高PPA需求、大规模的设计面前，渐渐力不从心。比如runtime：
● FC的综合引擎代码是全部重新写过的，构架和算法是全新的。相比较以前的综合工具，就像是高铁和汽车的区别，这速度嗷嗷的。
● 在传统的流程中，很多步骤会重复多次，像placement，global route，pre-route optimizaiton等。比如DCG一般做两次compile_ultra，然后在ICC2里，即使走SPG flow，也会再跑两次place和两次optimization。如果不走SPG flow，则重复步骤更多了。而FC就非常简洁，每一个步骤都不浪费，所以相对于传统flow，FC的runtime节省非常多。
● 从correlation角度考虑，以前由于物理综合和P&R的引擎不会100%一样，加上如果脚本不一样，物理信息不一样等等，导致综合和P&R的correlation会变化，可能会导致来回多次迭代。而FC没有任何correlation的问题，省却了很多迭代的时间。
●
综合的代码重写，多数布局和优化的核心代码也重写。新构架和新算法带来很多PPA的收益。
●
步骤融合在一起带来很多好处。比如compile_fusion不等于简单的“综合+布局”，所谓fusion，“融合”，就是综合、布局、优化等放在一起做，而不再是分开的步骤。举个例子，initial_opto这个步骤，不仅仅做优化，而还会做物理综合、布局、CCD，CTS，ICG优化，layer promotion等等。
●
有些后端优化技术提前做，有些前端综合技术往后做，对PPA收敛都会有很大帮助。
● 其实这不是一个新的概念，但是以前一直没有很大的突破。因为在传统的流程里面，前端跟后端工具不是在一个基础架构上，所以把前端引擎移植到后端的工具里面，或是把后端的引擎移植到前端工具里面都不是很容易做到。最后就是做了两套工具各自想办法去解决关联的问题。
● 而在Fusion Compiler这个新的平台上面，所有的引擎都在同一个数据模型上面，所以说所有的这些方法跟引擎可以自由的在任何环节都可以启用。比如说在逻辑综合的过程中要去启用一些布局绕线或是时钟优化的引擎确保收敛，或是绕线的过程中去启用一些局部综合的手法解决congestion等等，都能够轻松做到，而且同时确保设计收敛。因为不论在哪里启用，都是同一个引擎，设计意图，方法或者是这些优化模型都是一致的，确保不会造成不必要的来回，免去掉任何设计收敛的风险。
● 没有correlation问题，所有步骤的引擎都是一样的。complie_fusion阶段不用再加那么多margin，所以能带来非常巨大的power和area收益。
FC的dynamic power shaping， 简称DPS， 能够识别寄存器组，从而制造时钟时序的偏差，错开翻转的时机，把电流分布开，降低电流高峰。
DPS的独特功能，使用FC的CCD everywhere功能，能够在设计的早期，甚至综合的过程中就能启用的压降优化，达到一个从基础架构上就能经得起压降的设计。‘’
CCD是Concurrent Clock Data Optimization的缩写，也就是类似useful skew的意思啦，工具会同时去调整时钟树和优化data path，达到最好的性能。
那everywhere呢，就是哪里都有ccd。比如综合里会调用ccd，布局会调用ccd，CTS会调用ccd，pre-route optimization会，post-route optimization也会。每个阶段都去调整始终树，就会得到更好的功耗/面积和频率。特别是在综合阶段就看ccd，对功耗和面积的好处非常的明显。
DC里有的，比如 Core wrapper，串链等，在FC里面都有。
DC里没有的，比如MBIST，CODEC，OCC这些，FC里面也可以做。
由于FC的DFT功能太强大，下次可以开个专题详谈。
任何设计都可以用FC。
先进工艺，大规模的设计，会有更多的收益。能减少关键模块的TAT，提高关键模块的PPA。
小公司的前后端可能都是一个人做。但大公司分工较细，前后端是不同的team做。传统流程，前后端各用一个工具，前端人员给netlist和DEF给后端。然而如果用FC，前后端如何分工呢？这个智者见智，仁者见仁，根据自己公司的情况来安排。一般来说有以下几种情况：
● 后端人员来做综合和P&R，一个人全部搞定。
● 前端人员做综合，看initial_opto的结果，并以此来判断综合的质量。交付又分为二种，一种是把RTL交付给后端人员，后端人员用自己的环境重新做综合；第二种是把initial_opto的database或者netlist交付给后端人员，后端工程师接着往下做final_place和final_opto。
● 前端人员做综合，直接做到final_opto，并把final_opto的database交付给后端，后端人员只需要接着跑CTS即可。
如果你是ICC2的user，上手会非常快，因为命令和app option都是和ICC2一样的风格，database也是一样的。
如果你只是熟悉DC，那也不难，S提供了DC到FC的自动转换脚本！
个人认为FC这个平台是数字设计的未来。推出不到两年，在FC这个全新的平台上已经看到非常显著的好处，而且这个只是这个平台的第一步，未来会继续去探索还有哪一些机会利用这个平台，在不同的环节上启用在传统流程里受局限的一些优化方法。在不久的将来一定可以利用这个平台解锁更多更多的设计优化潜力。
/////////
