1. 數(shù)字后端流程中 place 環(huán)節(jié)的定位與整體思路數(shù)字后端設計里place布局這一步是繞不開的核心環(huán)節(jié)。簡單說前端綜合出來的網(wǎng)表只是一堆邏輯門和觸發(fā)器的連接關系沒有任何物理位置信息而 place 要做的事情就是把這些 std cell標準單元按照一定的規(guī)則擺放到芯片的版圖區(qū)域里。擺得好后續(xù)繞線順暢、時序容易收斂擺得不好congestion擁塞爆炸、setup 違例一堆后面再怎么修都事倍功半。我做了這些年后端最大的體會就是place 階段偷的懶route 階段要加倍還回來。很多新手覺得 place 就是跑個命令等結果實際上從 floorplan 交接過來的那一刻起每一步的決策都在影響最終能不能簽核。這篇文章我會圍繞 place 的完整流程把 std cell 擺放、congestion 控制、setup 時序優(yōu)化這幾個關鍵點拆開講清楚同時把常見的坑和排查思路一并整理出來。不管你是剛入行的后端新人還是想系統(tǒng)梳理流程的老手應該都能從中找到可以直接用的東西。place 在整個后端 flow 里的位置很明確floorplan 之后、CTS 之前。它接收的是 floorplan 確定的 die 面積、core 區(qū)域、macro 擺放位置、IO pin 分配、power plan 等約束輸出的是一個已經(jīng)擺好 std cell 的 DEF。這個 DEF 會交給 CTS 做時鐘樹綜合再往后是 route。所以 place 的質量直接決定了 CTS 和 route 的難度。從工具角度來說目前主流的兩大平臺就是 Cadence 的 Innovus 和 Synopsys 的 ICC2。兩者的 place 引擎思路大同小異都是先做全局布局global placement再做詳細布局detailed placement中間穿插各種優(yōu)化。我下面以 Innovus 為主來講因為它的日志和報告更直觀初學者更容易上手但核心原理是通用的。2. Place 之前的準備工作與約束檢查2.1 輸入文件清單與檢查要點在跑 place 之前你得確保手頭的輸入文件是齊全且正確的。缺一個文件或者版本對不上后面出來的結果全是白費功夫。我一般會按下面的清單逐項確認文件類型具體內(nèi)容檢查要點網(wǎng)表綜合后的 .v 文件單元庫版本匹配、無黑盒時序庫.lib / .db與網(wǎng)表單元一致、PVT corner 正確物理庫.leftech cell層定義完整、cell 尺寸正確約束.sdc時鐘定義、IO 延遲、例外寄生參數(shù).qrc / .tluplus與工藝節(jié)點匹配版圖DEFfloorplan 輸出die/core 區(qū)域、macro 位置、pin 分配這里面最容易出問題的是 LEF 和網(wǎng)表的匹配。我踩過一次坑綜合用的庫和物理庫不是同一個版本結果 place 跑完發(fā)現(xiàn)有些 cell 在 LEF 里根本找不到工具直接報錯退出。所以跑之前一定要用工具自帶的 check 命令過一遍Innovus 里可以用checkDesign來做完整性檢查。2.2 約束文件的確認SDC 約束是 place 階段做時序優(yōu)化的依據(jù)。如果 SDC 有問題place 出來的結果時序肯定不對。我通常重點看這幾個地方時鐘定義create_clock 的周期、波形是否正確有沒有漏掉 generated clock。IO 約束set_input_delay / set_output_delay 是否合理有沒有覆蓋所有 IO。例外false path、multicycle path 是否設置到位避免工具在不需要優(yōu)化的路徑上浪費精力。clock uncertainty這個值直接影響 setup 的余量place 階段一般會留得比 CTS 后大一些。有個經(jīng)驗place 階段我會把 clock uncertainty 設得稍微悲觀一點比如比最終目標多留 50-100ps。這樣 place 出來的結果到了 CTS 之后不會因為時鐘樹延遲而突然惡化太多。2.3 Floorplan 交接的確認Floorplan 階段確定的 macro 位置、power ring、IO pin 分配在 place 之前要再確認一遍。特別是 macro 周圍的 halokeepout margin如果留得不夠std cell 擠進去之后會導致 macro 引腳附近嚴重 congestion。我一般會在 macro 四周留至少 5-10um 的 halo具體看工藝和 macro 引腳密度。IO pin 的分配也特別關鍵。熱搜詞里提到的 “poor placement for routing between an io pin and bufg” 就是典型的 IO pin 和時鐘 buffer 之間繞線困難的問題。如果 IO pin 被分配到了離時鐘網(wǎng)絡很遠的位置place 階段工具會嘗試把相關的 buffer 往那邊擺但可能因為 congestion 擺不過去導致繞線繞遠、時序變差。所以 floorplan 階段分配 pin 的時候就要考慮時鐘網(wǎng)絡的大致走向。3. Place 核心流程與關鍵參數(shù)解析3.1 全局布局與詳細布局的分工Place 分兩大步global placement 和 detailed placement。Global placement 決定每個 cell 大致在哪個區(qū)域允許 cell 重疊detailed placement 則把 cell 對齊到合法的 row 和 site 上消除重疊。Innovus 里一條place_opt_design命令就把這兩步都跑了但理解它們各自在做什么對調優(yōu)很有幫助。Global placement 的核心目標是最小化線長wirelength同時控制 congestion。工具會用各種算法解析法、模擬退火等來求解。這個階段你可以通過設置 density 來控制布局的松緊程度。Density 設得太高cell 擠在一起congestion 必然爆炸設得太低面積浪費芯片成本上去了。一般我會把 target density 設在 0.7-0.85 之間具體看設計特點。Detailed placement 階段工具會做大量的局部優(yōu)化包括 cell swapping、cell sizing、buffer insertion 等。這個階段對 setup 時序的優(yōu)化最明顯。Innovus 會在 detailed placement 過程中反復調用時序引擎對關鍵路徑上的 cell 進行 upsizing 或者換用更低閾值的 cell。3.2 Congestion 控制的關鍵手段Congestion 是 place 階段最頭疼的問題之一。它的本質是某個區(qū)域的繞線需求超過了可用的繞線資源。造成 congestion 的原因很多macro 太密集、pin density 太高、cell density 太高、時鐘網(wǎng)絡太集中等。我在實際項目中總結了幾種有效的 congestion 控制手段第一合理設置 congestion effort。Innovus 里可以通過setPlaceMode -congEffort high來讓工具在 place 階段花更多精力優(yōu)化 congestion。但注意設太高會顯著增加運行時間而且可能犧牲時序。我一般先用 medium 跑一版看結果如果 congestion 確實嚴重再調高。第二使用 partial placement blockage。在 congestion 嚴重的區(qū)域放 blockage強制工具把 cell 擺到別處。這個手段很直接但用多了會導致面積利用率下降。我的經(jīng)驗是只在 macro 之間的窄通道或者 pin 密集區(qū)域用blockage 的密度設在 30%-50% 左右。第三調整 cell padding。對高引腳數(shù)的 cell 加 padding讓它們之間留出更多繞線空間。Innovus 里可以用setPlaceMode -placeIoPinPad或者對特定 cell 設 padding。第四控制 clock cell 的擺放。時鐘網(wǎng)絡上的 buffer 和 inverter 如果擺得太集中會在局部造成 congestion?？梢杂胹etPlaceMode -clockGateAware之類的選項讓工具考慮時鐘網(wǎng)絡的分布。3.3 Setup 時序優(yōu)化的實現(xiàn)機制Place 階段的 setup 優(yōu)化主要靠 cell sizing 和 buffer insertion。工具會分析時序路徑找出 slack 為負的路徑然后嘗試把路徑上的 cell 換成驅動能力更強的版本或者插入 buffer 來改善信號完整性。這里有個關鍵參數(shù)setOptMode -effort。設成 high 會讓工具做更激進的優(yōu)化但運行時間會明顯增加。我一般會在最終 signoff 前的 place 跑 high effort中間迭代用 medium 就夠了。另外setOptMode -usefulSkew這個選項值得關注。它允許工具在 place 階段就做一些有用的時鐘偏斜調整提前改善 setup。不過這個選項要和 CTS 階段的 skew 策略配合好不然可能白做。還有一個容易被忽略的點place 階段的時序優(yōu)化是在理想時鐘下做的沒有真實的時鐘樹延遲。所以工具優(yōu)化出來的結果到了 CTS 之后可能會有變化。我的做法是在 place 階段把 setup 的目標 slack 設得比最終要求緊一些比如要求 0ns 的話place 階段爭取做到 100ps 以上。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 環(huán)境搭建與設計導入假設你已經(jīng)有了所有輸入文件下面是我常用的 Innovus place 流程。先啟動工具并導入設計# 啟動 Innovus innovus # 設置多線程加速 setMultiCpuUsage -localCpu 8 # 導入網(wǎng)表、LEF、庫 set init_verilog ./netlist/top.v set init_lef_file ./lef/tech.lef ./lef/cells.lef set init_mmmc_file ./mmmc/view_definition.tcl set init_design_netlisttype Verilog set init_design_settop 1 set init_top_cell top # 執(zhí)行初始化 init_design導入之后第一件事是檢查設計完整性checkDesign -all這個命令會檢查網(wǎng)表、庫、約束之間的一致性。如果有 missing cell 或者 pin 不匹配會在這里報出來。千萬別跳過這一步我見過太多因為庫版本不對導致后面全盤重來的案例。4.2 約束加載與檢查接下來加載 SDC 并檢查# 加載時序約束 read_sdc ./sdc/top.sdc # 檢查時鐘定義 report_clocks # 檢查時序路徑 report_timing -max_paths 10 -early report_timing -max_paths 10 -late這里要特別確認時鐘有沒有正確傳播。如果 report_clocks 顯示時鐘沒有定義或者周期不對后面所有時序優(yōu)化都是錯的。熱搜詞里提到的 “檢查:setup constraints physical” 其實就是在提醒我們place 之前要把物理約束和時序約束都檢查到位。物理約束包括 floorplan 的 DEF、placement blockage、region constraint 等。時序約束就是 SDC。兩者缺一不可。4.3 Floorplan 加載與確認# 加載 floorplan DEF defIn ./def/floorplan.def # 檢查 die/core 區(qū)域 report_die_area report_core_area # 檢查 macro 位置 report_macros加載完 floorplan 后我習慣用 GUI 看一眼 macro 的擺放和 IO pin 的分配。特別是時鐘相關的 IO要確認它們的位置是否合理。如果發(fā)現(xiàn)某個時鐘 buffer 需要放在離 IO 很遠的地方就要提前考慮是不是要調整 floorplan。4.4 Place 主流程執(zhí)行一切確認無誤后開始跑 place# 設置 place 模式 setPlaceMode -congEffort high \ -timingDriven true \ -placeIoPinPad 2 \ -modulePlan false # 設置優(yōu)化模式 setOptMode -effort high \ -usefulSkew true \ -setupTargetSlack 0.1 \ -holdTargetSlack 0.05 # 執(zhí)行 place place_opt_designplace_opt_design這一條命令背后做了很多事情global placement、detailed placement、預布線、時序優(yōu)化、DRC 修復等。跑完之后工具會輸出一份 summary包括 congestion 情況、時序 slack 分布、面積利用率等。4.5 結果檢查與報告分析Place 跑完后必須做詳細的檢查。我一般按下面的順序來第一步看 congestion。Innovus 里可以用reportCongestion來查看 congestion map。重點關注 overflow 的區(qū)域如果某個區(qū)域 overflow 超過 5%基本可以確定 route 階段會出問題。reportCongestion -overflow第二步看時序。用report_timing檢查 setup 和 hold 的 slack 分布。Place 階段主要關注 setuphold 一般留到 CTS 之后修。report_timing -max_paths 50 -late -nworst 10第三步看面積利用率。report_area可以看 std cell 占用的面積和 core 面積的比例。利用率太高超過 85%會導致 congestion 風險太低則浪費面積。第四步看 DRC。Place 階段可能會有一些 cell 重疊或者 well 相關的 DRC用verifyGeometry檢查。verifyGeometry4.6 迭代優(yōu)化策略很少有設計能一次 place 就完美。通常需要幾輪迭代。我的迭代策略是這樣的第一輪用 medium effort 快速跑一版看整體 congestion 和時序的大致情況。這一輪的目的是摸清設計的主要矛盾在哪里。第二輪針對第一輪暴露的問題調整參數(shù)。如果是 congestion 問題加 blockage 或者調 density如果是時序問題調 opt effort 或者加 useful skew。第三輪用 high effort 跑最終版確保結果盡可能好。每一輪之間我會把結果和上一輪對比看改動是否有效。如果某一輪改動后結果反而變差就要回退重新想策略。5. 常見問題與排查技巧實錄5.1 Congestion 爆炸的排查思路Congestion 是 place 階段最常見也最棘手的問題。我遇到過的 congestion 原因大致分幾類Macro 通道太窄。兩個 macro 之間如果只留了幾微米的通道std cell 擺進去之后繞線資源根本不夠。解決辦法是在 floorplan 階段就留夠通道寬度一般建議至少 20-30um具體看工藝。Pin density 太高。某些模塊的 std cell 引腳特別密集比如 datapath 或者 memory 接口。這種情況下可以在局部降低 density或者用 partial blockage 把一部分 cell 趕到別處。時鐘網(wǎng)絡集中。時鐘 buffer 如果都堆在一個區(qū)域會在那里造成 congestion?？梢杂胹etPlaceMode -clockGateAware true讓工具分散擺放時鐘 cell。IO pin 分配不合理。熱搜詞里提到的 “poor placement for routing between an io pin and bufg” 就是這個問題。IO pin 和時鐘 buffer 之間如果距離太遠繞線會經(jīng)過很多區(qū)域造成沿途 congestion。解決辦法是在 floorplan 階段就把時鐘相關的 IO 分配到靠近時鐘網(wǎng)絡的位置。下面是我整理的 congestion 排查速查表現(xiàn)象可能原因排查方法解決手段局部 overflow 高cell density 太高reportCongestion -overflow加 partial blockagemacro 周圍擁塞halo 不夠查看 macro 間距增大 halo時鐘區(qū)域擁塞clock cell 集中查看 clock cell 分布設 clockGateAware全局擁塞density 設太高report_area降低 target densityIO 附近擁塞pin 分配不合理查看 pin 位置調整 floorplan5.2 Setup 違例修不動的處理Place 階段 setup 違例修不動通常有幾個原因約束太緊。如果 SDC 里的時鐘周期本身就不合理工具再怎么優(yōu)化也達不到。這時候要和前端確認約束是否實際可行。路徑太長。如果關鍵路徑跨越了整個芯片place 階段很難通過 cell sizing 來修復。這種情況需要考慮在 floorplan 階段調整模塊位置或者在前端做邏輯優(yōu)化。Cell 驅動能力不足。如果庫里的 cell 最大驅動能力都不夠工具也無能為力。這時候要考慮用更低閾值的 cell或者調整綜合策略。Congestion 限制了優(yōu)化。如果關鍵路徑經(jīng)過 congestion 嚴重的區(qū)域工具可能無法在那里插入 buffer 或者換 cell。這時候要先解決 congestion 問題再修時序。我的經(jīng)驗是place 階段如果 setup 違例超過總路徑數(shù)的 5%就要停下來想想是不是約束或者 floorplan 有問題而不是一味地調 opt effort。5.3 Place 后結果與 CTS 不一致的處理Place 階段是在理想時鐘下優(yōu)化的CTS 之后有時鐘樹延遲結果會有變化。如果變化太大說明 place 階段的優(yōu)化方向可能有問題。我一般會在 place 之后做一個預判看看關鍵路徑上的時鐘延遲大概是多少如果超過時鐘周期的 10%就要在 place 階段留更多余量。另外place 階段用的 clock uncertainty 要合理不能設得太樂觀。5.4 工具版本與腳本兼容性問題熱搜詞里出現(xiàn)了 “inno setup” 相關的內(nèi)容雖然那是安裝程序制作工具但側面說明工具版本和腳本兼容性是個常見痛點。Innovus 不同版本之間命令和選項可能有變化比如某些選項在新版本里被 deprecated 了。我的做法是固定項目使用的工具版本不要隨意升級。腳本里對關鍵命令加版本判斷。保留一份已知可用的腳本作為 baseline改動時對比。5.5 實操心得與避坑清單最后分享幾條我在實際項目中總結的心得提示Place 之前一定要用 checkDesign 和 checkTiming 過一遍這兩個命令能幫你省下大量 debug 時間。注意不要為了追求零 congestion 而把 density 設得過低面積浪費的代價可能比 congestion 更大。提示Place 階段的日志要仔細看工具會在日志里提示哪些路徑修不動、哪些區(qū)域有風險這些信息比最終報告更有價值。每次改參數(shù)只改一個改完對比結果這樣才能知道哪個參數(shù)起了作用。保留每一輪的 DEF 和報告方便回退和對比。和前端保持溝通place 階段發(fā)現(xiàn)的約束問題要及時反饋。不要迷信工具的自動優(yōu)化該手動加 blockage 或者調整 floorplan 的時候要果斷。Place 這個環(huán)節(jié)說到底是在面積、時序、congestion 三者之間找平衡。沒有完美的結果只有最合適的取舍。我做了這么多項目每次 place 都還是會遇到新問題但只要有系統(tǒng)的排查思路和足夠的經(jīng)驗積累大部分問題都能在幾輪迭代內(nèi)解決。希望這些內(nèi)容對正在做數(shù)字后端的朋友有所幫助少走一些我當年走過的彎路。