這個項目最重要的模塊就交給你了！
不然項目組那里不好交代，是吧？
你就要被搞了！
隨著摩爾定律持續演進，更高性能、低成本的電子產品利益了全人類。
大家都知道手機上可以吃雞了，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這個全新的平臺上已經看到非常顯著的好處，而且這個只是這個平臺的第一步，未來會繼續去探索還有哪一些機會利用這個平臺，在不同的環節上啟用在傳統流程里受局限的一些優化方法。在不久的將來一定可以利用這個平臺解鎖更多更多的設計優化潛力。
/////////
