在四月的尾巴終于把第一次流片交出去了。許多前輩曾告誡我流片如何困難，而想要請教卻很難得到統一的回答。經過這一輪流片切身怯魅，積攢了一些淺薄的流片 know how 經驗分享。

流片要見實物，而想要讓數百萬千萬至數億晶體管老老實實守本分工作并不是那么輕松。從算法到編譯器到RTL到網表到GDS到電路板，龐大的工作量必須要分工合作；并且流片一批白銀萬兩，創新點差了點頂多是降低一下文章檔次，而流片失敗則是徹徹底底打了幾百萬水漂了。

學術流片還有獨特的困難之處：首先，主力軍大多是學生，流片經驗相對不足；其次，學生的核心訴求是發文章畢業，而流片對大多數同學在成本角度往往站不住，流片周期勞動力付出大于創新探索，不符合“小而美”“快而深”的實驗室產出，文章掛名也是僧多粥少，導致學術流片往往集中在一倆個核心成員 cover 大部分流程，而流片又涉及多個環節的專業知識，極為考驗核心成員的綜合素質。

流片工程流程

完整的一次數字流片需要經過以上環節，其中大致根據隨著時間項目進展順序排序位置，藍色表示更偏向軟件設計、綠色表示硬件設計、黃色則是大量的驗證檢查。

這次流片后對流片特點總結如下：

• 流片難以進行持續開發
• 流片極其吃經驗
• 流片磨片更磨人

流片開工前問問這三個問題評估流片可行性：“是否有清晰明確的設計方案？是否有至少一位具備完整流片經驗的成員參與或指導？流片團隊是否具有戰斗力？”

流片難以進行持續開發

在前文博客中已論證架構工程的劃分是一個 NP 問題，即使實現同一個功能，不同的模塊劃分方式會導致工程量差距極大，因此對模塊接口的劃分極其重要^[1]。流片中最忌憚頻繁變動，寫代碼容易維護代碼難，并且對于多環節多人員參與的項目，變動帶來的后果不僅是上下游全部迭代更新，并且版本混亂帶來額外的管理困難。

最理想當然是前一個階段徹底固定再進行下一個階段，但時間成本有限，為了充分發揮人員效率往往需要并行開發。怎么能夠在最短的時間內，付出最少的必要努力，將系統大部分固定下來？

RTL 是設計的最終手段

迭代會出現在于流程中存在難以預測的事件——必須要走到那一步才能獲得相應反饋。但獲取相同信息反饋的方法不止一種，比如要預測系統性能，既可以完成 RTL 設計得到網表過能耗仿真；也可以基于假設提取主要能耗，在 simulator 甚至 excel 中計算能耗。做出判斷需要的信息精度需求可能沒那么高，而獲取信息反饋方法之間的實現成本天壤之別，盡可能讓問題在項目早期暴露。其中以 RTL 開發最為關鍵，RTL 迭代維護成本極大，并且一旦 RTL 變動，后續所有綜合后端都要相應變化，RTL freeze 是最為關鍵的節點之一。應當把 RTL 當作設計的最終階段，而非設計的開始；應當尋求一切更加輕量的方法迭代驗證系統設計，而非先寫一版本 RTL 再迭代代碼。

進一步將 RTL 開發分為架構設計和代碼實現，前者回答怎樣的芯片有學術創新價值，后者回答怎樣具體實現這樣的系統，甚至評估實現的復雜度。

• 架構迭代可以通過 simulator 探索，比如 AI 芯片主要性能開銷集中在數據流上，即使不考慮相對復雜的控制流，分析精度也足夠精準，如果系統 software-hardware codesign 創新點很重要，且必須要借助更具體細節才能評估，盡量在早期完成虛擬原型和軟件棧編譯器，不然到寫測試環節也要吃虧；
• 實現迭代要重視寫 SPEC 文檔的環節，特別是接口的信號定義和時序邏輯，寫 SPEC 的時間應當和 RTL 設計在一個數量級甚至更多；
• 此外遵循 top-to-bottom 的方式設計，迭代中增添模塊可能都會引發蝴蝶效應導致整體接口邏輯變動。

行動前評估實現復雜度

即使確認系統功能準確可實現，也要控制保證實現復雜度在時間-人力的限制范圍之內。不然 RTL coding 中經常出現：“腦中明明已經有這個電路了，但為何遲遲工程推進不出來？”的奇怪現象。在文檔階段無法預料到的實現困難主要集中在復雜的控制流，這里分享一套根據接口時序半定性評估實現復雜度的方法。

硬件開發難處在于同時可能存在交互關系的變量太多，舉幾種編程模式對比。（1）理解難度最低是單線程編程。序列性的單線程編程滿足人腦對文本的處理邏輯，過去創建的變量對程序員不需要考慮，而在執行上靠內存回收機制“遺忘”。程序員僅需要考慮比較短上下文內部的變量交互邏輯；（2）再難一點是并行程序開發，程序員不僅需要考慮單線程上下文窗口內的邏輯交互，也需要考慮線程之間同步交互，當然較遠歷史變量大部分同樣可以利用回收機制；（3）而最難的是硬件開發，硬件開發一個信號就是實打實的一個變量，生存周期貫穿整個功能，并且包含各類模塊之間并行的交互。^[2]

因此硬件開發可以粗糙通過信號數量大致衡量系統實現復雜度，需要考慮的信號數量和實現復雜度并不是線性關系，一個 100 接口的系統實現難度要大于 10 個 10 接口系統實現難度。并且顯然同構的設計并不增加系統復雜度，實現 100 個加法器和實現 1 個加法器沒有什么不同。具體來說要衡量信號對設計復雜度，也就是其涵蓋的信息量的多少。如果兩個信號有同步關系，應該認為是一種信號，比如信號A工作時信號B一定工作，信號A不用時信號B一定不用；同步的一組信號，如果存在不同延時也要考慮相應的復雜度，比如 SRAM macro 讀時序，地址和使能在同一個周期給出，而數據在下一個周期讀出，這要分作兩種信號來考慮。

在本次流片中，早期系統控制流花費兩周仍然沒能實現跑通，后評估實現復雜度過高，犧牲硬件資源重構架構后，僅僅在一個周末內實現了系統控制流。

流片極其吃經驗

流片中存在著大大小小的坑，而半導體行業又極其封閉，發展這么多年了甚至很難找到一篇完整介紹流片的教程或者書籍。很多困難并非能力而僅僅是單純經驗的差距。又因為流片中經常出現各種奇奇怪怪難以追蹤的問題，使得半導體頗有“老中醫”或“規則怪談”的味道，過往的經歷具象為了一條條操作規范，只能說遵循這樣做比較保險，但究竟這樣做會出什么問題難以說清。這也是流片不得不品的一環。

將本次流片遇到的問題總結如下，其中特別要謹慎出現問題源頭和發現問題環節間隔過長的問題，這些問題早期隱蔽，極大可能導致項目在晚期被迫重新迭代更新：

說明：

• 代碼不可綜合： 大部分同學第一版代碼都會存在這個問題，在培訓的時候要特別強調，或者采用分而治之分模塊綜合；
• 浮點方案： 浮點計算不滿足交換律，涉及浮點計算要特意留意虛擬原型的浮點計算方案，比如 torch 默認 bf16 累加在 fp32 中完成。此類差異會導致虛擬原型和硬件設計無法對齊；
• 寄存器使用異步復位+復位值： 如果一個寄存器下一個周期的值和自身上一個周期有關，比如 counter <= counter + 1'b1; ，此時某 fab 標準單元庫 verilog 建模 + VCS 環境下無法正確仿真未定態傳播，導致仿真出錯。若同步復位復位端會從 Dff 的 D 端傳入無法正確復位，導致無法進行后仿環節。這種寄存器必須使用異步復位生成帶復位的 Dff 單元才能仿真通過；或者在激勵中手動給寄存器賦予初始值，但這極大增加了工程量和復雜度；
• 常量限定位寬：Verilog 標準中規定未注明位寬的常量為 32bit，a = -1 * a 使用 DC compile 綜合時生成了一個 32 bit 比特的乘法器導致時序違例，使用 compile_ultra 可能可以避免，但無法說清 DC 綜合過程中是否受此影響，應該從源頭上避免這種壞習慣；
• 激勵數據信號邊沿和伴隨時鐘邊沿錯開： 伴隨時鐘即時鐘信號和數據信號一起通過 IO 打入， 很多標準單元對上升沿和下降沿的延時不一致，如果數據變化邊沿對齊時鐘采樣沿，會導致某種電平信號脈沖少于一個周期進而無法正確被同步電路采樣，需要在激勵中將信號邊沿錯開時鐘采樣邊沿，最極端是錯開半個周期，當然這樣可能會引發 setup 違例

此外還有 IO 太密導致封裝 DRC 違例，需要提前和封裝廠商量是否能做；控制流設計對打拍參數化方便 STA 違例修時序等等。但可以寫成規則的坑踩過一次就可以避免，更多的坑是要決策者在項目遠遠不如預期的條件下，評估現狀，果斷大膽抉擇調整方向。

流片磨片更磨人

流片逃離不開多人合作，既然學術流片存在流片工程難度和人員吃緊的核心矛盾，流片遇到各種亂七八糟的困難基本是百分百發生，并且流片是工程機械化的勞動成份占據主流，很容易讓人感到乏趣枯燥，此時便更加考驗團隊的戰斗力。學術小規模團隊合作經驗如下：

• 小規模團隊建議按模塊分工而非按環節分工，將設計和驗證耦合，每個人負責一個模塊的完整流程；
• 流片需要保證人員 full-time 參與，流片周期長，困難雜，在各個階段都需要高度交流合作，人員變動十分影響項目推進；
• 核心成員保持戰斗力和信心。

總結

這次流片挑戰對我來說主要是工程和管理的挑戰。工程的問題經過一次流片已能鼓起信心面對下次流片，可管理上卻沒有信心下次能夠做得更好。以往學習研究，大多都是單打獨斗，單打獨斗也足夠了，多人合作也大都是些無關痛癢的比賽，試錯成本較低，這是第一次項目管理如此重要。

一方面挑戰是工作方式的變化，和供應商外包商對接、內部流程匯報、對接各個成員進度，還有自己負責的部分，思緒很容易就在各種微信消息和郵件中迷失了，回復各種消息往往一天就過了大半，算是切身體會了異步系統的復雜性；

另一方面是流片的心理壓力，幾乎每一個節點都落后于預期，作為領導者看到的信息最多，也最了解問題的困難，常常感受“項目要做不完了，想放棄”，可一旦自己表現出泄氣，必然影響整個團隊的斗志，進而導致擔心的事情真就發生了。半夜經常失眠，十分考驗磨練心性。

好在雖然有不少遺憾，也算是完完整整走完這一次流程。特別感謝整個團隊的支持以及關鍵時刻給予指點幫助的前輩們。