中端設計在IC開發(fā)中的價值和思考

IC設計中通常基于設計時間線/業(yè)務線分為前端設計和后端實現，這個也是大家通常所能理解和接受的。類似下圖

可以看到這里的FE/BE有一個明顯的橋接地帶，就是邏輯綜合（synthesis），所以在實際的公司業(yè)務部門分布上，會有下列三種情形存在：

• 將綜合部分會劃歸為前端
• 將綜合劃歸為后端
• 將綜合單獨出來，變?yōu)橹卸耍∕E：middle-end）

這里的三種方式筆者都有接觸，相對于不同業(yè)務各有優(yōu)缺點，但是從芯片的整體規(guī)模日益增大的趨勢下，第三種的情形未來應該會越來越多

這個話題放到前幾年，可能還不是很敏感，從2020年開始，國內的初創(chuàng)公司多了很多，大部分都是BEless的模式。從保護自身核心利益出發(fā)，RTL代碼是不便于公開的，所以采用網表交付就成為最優(yōu)解，上述基本流程變成了

公司的中端部門基本就是公司的對外數據交付部門了，所有的數據出口都是這里，后端外包團隊的結果會直接去到FAB進行TO。這里的中端組的權責就是：給外包團隊提供數據和業(yè)務支撐，確保最終流片。

這種模式主要是服務于初創(chuàng)公司第一版的業(yè)務模式，快并且時間可控，費用自然會高。當然，簡單的用一把資金能解決的問題一定只是部分解決。這種模式里的傷與痛，也只有真正經歷過的同學可以體會的到吧。這個流程也是一種中間產物，從業(yè)務收斂上講，最后還是會回歸本文的開票所述的三種模式之一。

從結構圖上看，中端猶如項目的腰（類核心力量），承上而啟下，這個部位的帶寬一定要足，確保前后端無縫銜接，猶如連接兩個馬達之間的傳動軸，一定是需要細心呵護和用心經營的。

隨著芯片規(guī)模和復雜的不斷地增大，前兩種模式通過類似一種刷前端/后端機時的方式已經很難在高速的發(fā)展中繼續(xù)跟進了，專業(yè)的人做專業(yè)的事，獨立的中端部門可以很好的解決下面的問題場景

• SDC質量：不是不好，是不夠好
• 時鐘有，但是不全
• gen-clock都有，但是和master的關系不清楚
• clock的定義點不太合適
• CGU的寫法對于后端實現的友好性
• DFT對SDC的影響考量
• clock 結構優(yōu)化
• 使用MCP替換Falsepath
• IO約束的合理性
• 時鐘樹的重聚和細節(jié)（launch vs capture）
• 等等
• UPF的各種小issue
• load_upf可以，但是check_mv有error
• isolation/LS插入的質量細節(jié)商榷
• power-domain/power-state的合并和優(yōu)化
• 對層次化設計的支持
• 全芯片rail的logic和physical的布局
• 等等

以上種種，看起來都什么大問題，但是對于大芯片而言，哪個細節(jié)出問題都是會導致大問題。芯片設計是一個很難收斂的硬設計，要保證系統(tǒng)的穩(wěn)定性（stability），就必須降低/剪除系統(tǒng)的冗余性（Redundancy）/多義性（ambiguity）。這個特點對于靜態(tài)的時序分析和低功耗分析的挑戰(zhàn)尤甚，如果還是對此不太理解的話，可以想象一下RTL在跑linting的時候的信息量，就可以感知到靜態(tài)分析的威力了。

類似的，對于綜合（DC/Genus），靜態(tài)時序分析（PT/Tempus），低功耗分析（vclp/LEC_low-power）的各種信息分類：info，warning和error（嚴格上講，error是需要全部消滅的），也是需要中端團隊查驗的，

中端的任務是平抑前后端的差異，最終的服務對象還是后端團隊，這里有一些簡單的案例可以分享給大家，可能一點點的工作，就可以讓后端的實施變得平滑通過是提高項目靜態(tài)質量。

時鐘的定義點必須是leaf cell的output pin：有時候為了方便，前端會把時鐘的點位定義點放到CGU的一個hierarchy的輸出pin，這樣很容易下約束，但是會面臨port punch的挑戰(zhàn)，最慘代價就是在BE側，導致這個時鐘丟失。

綜合view

APR cts view

這個情形，clock_out依然是一個clock point，但是由于APR 工具的push port，這個點依然是有clock 屬性，但是卻沒法真實的驅動后面的邏輯了，也就相當于把這個clock弄丟了。

時鐘的定義點需要尊重原著：有時候，clock是從外部的PAD進來的，但是由于PAD都是雙向口，那么進來的那一支一定是固定的pin，可能會有同學用這個點定義clock， 譬如這里的C pin

這個從原理上講，沒有問題，但是卻沒有精確反應實際情形，有實際的風險，真實且正確的定義是這樣的：

這樣做是有它的道理的，不僅僅是點位的問題，一起看一下下圖

可以看到，從PAD進到C的timing arc在rise和falling的線性度不是非常一致，這里在核算min-pulse width之類問題的時候，結果會比之前定義到C點上要悲觀很多；如果定義到C點，會導致sign-off樂觀，往往芯片最怕樂觀，這種木桶效應的傷害，都是每個經歷者的終身遺憾啊！所以這里的clock的定義點需要修正到PAD上。