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