：從RTL到GDSII的個人流片全流程)
1. 為什么我要把開源EDA和Sky130 PDK串起來講第一次聽說“開源流片”這四個字的時候我正蹲在實驗室角落里啃一份商業(yè)PDK的NDA文檔滿屏的“Confidential”水印看得人頭皮發(fā)麻。那時候想跑一次完整流程要么進大廠拿內(nèi)部賬號要么花幾十萬買License個人開發(fā)者基本沒戲。后來OpenMPW項目把Sky130 PDK和OpenROAD這套開源工具鏈推到臺前我才意識到——原來從RTL到GDSII這條路真的可以完全用開源工具走通而且真能送去流片。這篇內(nèi)容就是把我從零搭環(huán)境、跑通全流程、踩坑填坑的整個過程攤開來講。核心關鍵詞就幾個開源EDA、Sky130 PDK、流片、OpenMPW、OpenROAD。適合誰看如果你是數(shù)字IC設計方向的學生、想驗證自己小設計的獨立開發(fā)者、或者單純對芯片后端流程好奇的軟件工程師這篇都能給你一條能走通的路。我不講虛的只講我實際跑過的命令、遇到的報錯、以及最后怎么把GDS交出去的。需要提前說明的是開源EDA工具鏈和商業(yè)工具在成熟度上仍有差距Sky130作為130nm工藝雖然“老”但恰恰因為老它的設計規(guī)則相對寬松適合練手。OpenMPW這類多項目晶圓計劃則把流片成本攤薄到個人可承受的范圍。這幾個東西湊在一起才讓“個人流片”從笑話變成了現(xiàn)實。2. 開源EDA工具鏈的整體設計與選型邏輯2.1 為什么是OpenROAD而不是其他開源方案開源EDA工具不少但真正能撐起完整RTL-to-GDSII流程的OpenROAD是目前最成體系的一個。我最初試過用Qflow它確實輕量但綜合、布局布線、時序分析各環(huán)節(jié)割裂感很強腳本膠水層寫起來很痛苦。OpenROAD把邏輯綜合通過Yosys、布局RePlAce、時鐘樹綜合TritonCTS、布線FastRoute/TritonRoute、時序分析OpenSTA整合到一個統(tǒng)一的Tcl驅(qū)動環(huán)境里流程連貫性好了很多。選OpenROAD的另一個理由是它對Sky130 PDK的支持最完整。OpenROAD的GitHub倉庫里直接帶了Sky130的示例配置包括LEF、DEF、Liberty文件的位置和參數(shù)模板。你不需要自己去拼湊PDK文件路徑省了大量試錯時間。相比之下OpenLANE現(xiàn)在叫OpenLane雖然也是基于OpenROAD的封裝但它更偏向“一鍵流片”的自動化流程對想理解每一步在干什么的人反而不夠透明。我的建議是先用OpenLane跑通一個例子建立信心然后切到OpenROAD手動控制每一步這樣既能看到結果又能學到東西。2.2 Sky130 PDK到底給了我們什么Sky130是SkyWater Foundry的130nm CMOS工藝PDK全稱Process Design Kit。它包含的東西比你想象的多器件模型SPICE模型、設計規(guī)則DRC規(guī)則文件、版圖圖層定義GDS層號、標準單元庫Sky130_fd_sc_hd等、IO庫、SRAM編譯器生成的宏單元等。開源的部分主要是數(shù)字標準單元庫和基礎器件模擬器件模型也有但精度需要自己評估。我實際用到的PDK組件主要是這幾類Liberty文件.lib給綜合和時序分析用描述每個標準單元的時序、功耗、面積LEF文件給布局布線用描述單元的物理輪廓和引腳位置GDS文件是標準單元的版圖最終和你的設計合并技術LEF定義金屬層、通孔、設計規(guī)則。這些文件在Sky130 PDK的GitHub倉庫里按目錄分得很清楚但版本很多選錯版本會導致后面各種奇怪報錯。注意Sky130 PDK有多個版本分支比如sky130_fd_sc_hd和sky130_fd_sc_hs前者是高密度庫后者是高速度庫。新手建議從hd開始因為它的文檔和示例最多踩坑時容易找到參考。2.3 OpenMPW流片計劃的實際運作方式OpenMPWOpen Multi-Project Wafer是Google和SkyWater合作的項目定期把多個開源設計拼到一個晶圓上流片然后免費或低成本提供給參與者。它的運作模式是你提交GDSII文件他們負責拼版、流片、封裝、測試最后寄給你芯片。聽起來很美好但有幾個硬性約束你必須提前知道。第一面積限制。每個設計被分配一個固定大小的區(qū)域通常是幾平方毫米你的設計不能超過這個框。第二引腳限制?？捎玫腎O焊盤數(shù)量和位置是固定的你的頂層端口必須映射到指定的焊盤上。第三DRC必須干凈。任何DRC違規(guī)都會被直接拒絕沒有商量余地。第四提交窗口是周期性的錯過一次要等下一輪。我建議在動手之前先去OpenMPW的文檔頁把最新的提交指南讀三遍把面積、引腳、層號這些約束抄在紙上貼在顯示器旁邊。3. 環(huán)境搭建與核心工具配置的實操細節(jié)3.1 系統(tǒng)環(huán)境與依賴安裝的坑我用的系統(tǒng)是Ubuntu 20.04 LTS這是OpenROAD官方推薦的環(huán)境。22.04也能跑但有些依賴包的版本會沖突需要手動降級。內(nèi)存建議至少16GB因為布局布線階段對內(nèi)存消耗很大8GB跑小設計勉強夠但很容易被OOM Killer干掉。磁盤空間留50GB以上PDK文件、工具二進制、中間結果加起來很占地方。安裝方式我推薦用OpenROAD提供的預編譯二進制包而不是從源碼編譯。源碼編譯一次要一個多小時而且經(jīng)?？ㄔ谀硞€依賴上。預編譯包解壓就能用省心很多。具體步驟是去OpenROAD的GitHub Releases頁面下載對應系統(tǒng)的壓縮包解壓到/opt/openroad然后把/opt/openroad/bin加到PATH里。# 下載并解壓OpenROAD預編譯包 wget https://github.com/The-OpenROAD-Project/OpenROAD/releases/download/v2.0/openroad-2.0-ubuntu20.04.tar.gz tar -xzf openroad-2.0-ubuntu20.04.tar.gz -C /opt/ echo export PATH/opt/openroad/bin:$PATH ~/.bashrc source ~/.bashrcSky130 PDK的獲取方式有兩種一種是用volare工具自動管理版本另一種是手動clone倉庫。我建議用volare因為它能幫你處理版本切換和文件路徑問題。安裝volare用pip就行pip install volare volare enable --pdk sky130 --version 0.0.0-20230901這個命令會把PDK下載到~/.volare目錄下并設置好環(huán)境變量。之后在OpenROAD腳本里引用PDK路徑時直接用$PDK_ROOT和$PDK變量即可。3.2 標準單元庫的選擇與配置Sky130的標準單元庫有好幾個變體我前面提到新手從sky130_fd_sc_hd開始。這個庫的單元高度是2.72微米軌道數(shù)是9驅(qū)動能力從1到8倍不等。選庫的時候要注意Liberty文件和LEF文件的版本必須匹配否則會出現(xiàn)單元引腳對不上的問題。配置OpenROAD時你需要準備一個Tcl腳本里面定義好各個文件的路徑。我通常把路徑定義放在腳本開頭方便修改set PDK_ROOT $env(PDK_ROOT) set PDK $env(PDK) set LIB_DIR $PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd set TECH_LEF $PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd/techlef/sky130_fd_sc_hd__nom.tlef set CELL_LEF $LIB_DIR/lef/sky130_fd_sc_hd.lef set LIB_FILE $LIB_DIR/lib/sky130_fd_sc_hd__tt_025C_1v80.lib這里tt_025C_1v80表示典型工藝角、25攝氏度、1.8V電壓。做時序分析時你可能還需要其他工藝角比如ss慢速和ff快速但初期跑通流程用tt就夠了。3.3 Yosys綜合腳本的編寫要點Yosys負責把Verilog RTL轉成門級網(wǎng)表。OpenROAD流程里通常用yosys配合abc做邏輯優(yōu)化和映射。我寫綜合腳本時踩過的坑主要是兩點一是忘記設置read_verilog的-sv選項導致SystemVerilog語法報錯二是沒有正確指定目標庫導致映射出來的單元不可用。一個能跑通的綜合腳本大概長這樣# 讀取設計 read_verilog -sv ./src/top.v # 讀取標準單元庫 read_liberty $LIB_FILE # 設置頂層模塊 hierarchy -top top # 綜合 synth -top top # 映射到標準單元 abc -liberty $LIB_FILE # 輸出網(wǎng)表 write_verilog ./out/top_synth.v綜合完成后一定要檢查一下網(wǎng)表里有沒有$_AND_之類的通用單元殘留如果有說明映射沒做干凈后面布局會報錯。另外綜合報告里的面積和時序估算只能參考實際以布局布線后的結果為準。實操心得Yosys的綜合腳本里abc那一步可以加-script參數(shù)指定優(yōu)化腳本比如strash;scorr;ifraig;retime;dch;map能改善面積和時序。但新手先用默認參數(shù)跑通再說優(yōu)化是后面的事。4. 從RTL到GDSII的完整流程拆解4.1 布局規(guī)劃與電源網(wǎng)絡設計布局規(guī)劃Floorplan是后端流程的第一步?jīng)Q定了芯片的物理輪廓和電源分布。OpenROAD里用initialize_floorplan命令設置芯片面積和核心區(qū)域。面積怎么定我的經(jīng)驗是先用綜合后的單元總面積乘以1.5到2.0的系數(shù)作為初始值跑完布局后再根據(jù)擁塞情況調(diào)整。initialize_floorplan -die_area {0 0 1000 1000} \ -core_area {10 10 990 990} \ -site unithd這里unithd是Sky130標準單元的站點名稱必須和LEF文件里定義的一致。電源網(wǎng)絡PDN用pdngen命令生成需要提前寫好PDN配置文件定義電源環(huán)、電源條帶的寬度和間距。Sky130的金屬層從met1到met5我通常用met4和met5做電源網(wǎng)格因為高層金屬電阻小、電流承載能力強。PDN配置里有個參數(shù)叫pitch控制電源條帶的間距。設太小會浪費布線資源設太大又會導致IR Drop超標。我的經(jīng)驗值是每50到100微米一條電源條帶具體看設計的功耗密度。IR Drop分析可以用OpenROAD自帶的analyze_power_grid命令跑但需要額外的電源pad信息初期可以先跳過。4.2 布局與時鐘樹綜合的關鍵參數(shù)布局階段用global_placement和detailed_placement兩個命令。全局布局決定單元的大致位置詳細布局做合法化確保單元不重疊且對齊到站點網(wǎng)格。全局布局有個參數(shù)叫-density默認0.7意思是標準單元占核心區(qū)域面積的70%。如果設計擁塞嚴重可以降到0.6或0.5給布線留更多空間。global_placement -density 0.65 detailed_placement時鐘樹綜合CTS用clock_tree_synthesis命令核心參數(shù)是-buf_list指定用來構建時鐘樹的緩沖器單元。Sky130的hd庫里有sky130_fd_sc_hd__clkbuf_4、clkbuf_8等我一般選clkbuf_4作為主力驅(qū)動不夠時自動升級到clkbuf_8。CTS之后要做時序分析檢查時鐘偏斜skew和插入延遲latency。Sky130這種老工藝的時鐘樹相對好做skew控制在100ps以內(nèi)不難。注意CTS之前一定要確保時鐘定義正確。在SDC文件里用create_clock定義時鐘周期和端口否則CTS不知道要優(yōu)化什么。SDC文件里還要設置輸入輸出延遲、驅(qū)動能力、負載電容等約束這些直接影響時序結果。4.3 布線流程與DRC清理布線分全局布線和詳細布線兩步。全局布線用global_route它規(guī)劃每條網(wǎng)絡的走線路徑但不指定具體金屬層和通孔。詳細布線用detailed_route它實際分配金屬層、放置通孔、滿足DRC規(guī)則。Sky130的DRC規(guī)則相對寬松但金屬間距、通孔 enclosure、天線效應這些還是要小心。global_route -congestion_iterations 30 detailed_route -output_drc ./out/drc.rpt \ -verbose 1詳細布線跑完后會生成DRC報告。如果報告里違規(guī)數(shù)量是0恭喜你可以進入下一步。如果有違規(guī)先看違規(guī)類型如果是間距違規(guī)可能是布線密度太高回去調(diào)布局密度如果是通孔違規(guī)可能是PDN和信號線沖突需要調(diào)整PDN配置。我遇到過最頭疼的是天線效應違規(guī)解決方法是插入天線二極管或者調(diào)整布線層。DRC清理是個迭代過程可能要來回改布局和布線參數(shù)好幾次。我的建議是每次只改一個參數(shù)改完重新跑記錄結果這樣才能知道哪個參數(shù)起了作用。4.4 GDS輸出與流片提交檢查清單所有步驟跑完后用write_gds命令輸出GDSII文件。但輸出之前必須做幾件事第一跑一次完整的DRC檢查確保沒有違規(guī)第二跑LVS版圖與原理圖一致性檢查確保版圖網(wǎng)表和綜合網(wǎng)表一致第三檢查頂層端口是否映射到了OpenMPW指定的焊盤位置。write_gds ./out/top.gdsLVS我用的工具是Netgen它需要網(wǎng)表文件和GDS文件作為輸入。Sky130 PDK里帶了Netgen的配置模板照著改路徑就行。LVS通過后把GDS文件按OpenMPW的要求打包提交。提交前再對照檢查清單過一遍面積是否超標、引腳是否匹配、層號是否正確、DRC是否干凈、LVS是否通過。這五項有任何一項不過提交都會被拒。5. 常見問題與排查技巧實錄5.1 綜合階段報錯與解決綜合階段最常見的報錯是“找不到模塊”或“無法映射單元”。前者通常是Verilog文件路徑不對或者模塊名拼寫錯誤后者一般是Liberty文件沒讀進來或者目標庫名稱寫錯。我遇到過一次abc報“no liberty cell found”查了半天發(fā)現(xiàn)是Liberty文件里的單元命名和LEF文件不一致?lián)Q了一個版本的PDK就好了。另一個坑是SystemVerilog語法支持不全。Yosys對SystemVerilog的支持在逐步完善但有些高級語法比如interface、structpacked數(shù)組還是有問題。我的做法是盡量用Verilog-2001風格的語法寫RTL實在要用SystemVerilog就先單獨跑read_verilog -sv測試一下。5.2 布局布線階段的典型故障布局階段最怕的是擁塞congestion。OpenROAD的全局布線器會報告擁塞熱圖如果某片區(qū)域紅得發(fā)紫說明那里布線資源不夠。解決辦法有三個降低布局密度、調(diào)整單元位置、增加芯片面積。我一般先降密度到0.55試試不行再擴面積。詳細布線階段的DRC違規(guī)前面提過了這里補充一個特殊情況天線效應違規(guī)。Sky130的金屬層在刻蝕過程中會積累電荷如果某條長金屬線直接連到晶體管柵極電荷可能擊穿柵氧。解決方法是插入天線二極管或者在布線時跳層。OpenROAD的詳細布線器有-antenna選項可以自動修復部分天線違規(guī)但不是萬能的。5.3 時序違例的調(diào)試思路時序違例分建立時間setup和保持時間hold兩種。建立時間違例說明數(shù)據(jù)路徑太慢解決辦法是加緩沖器、換驅(qū)動更強的單元、或者降低時鐘頻率。保持時間違例說明數(shù)據(jù)路徑太快解決辦法是加延遲單元或者調(diào)整時鐘樹。OpenROAD的repair_timing命令可以自動修復部分違例但手動分析更可靠。我習慣用OpenSTA單獨跑時序分析生成時序報告然后逐條路徑看。報告里會列出每條路徑的起點、終點、數(shù)據(jù)路徑延遲、時鐘路徑延遲、slack值。slack為負就是違例負得越多越嚴重。先修最差的路徑修完再跑一遍迭代幾次就能收斂。5.4 流片提交被拒的常見原因根據(jù)OpenMPW社區(qū)里的討論和我自己的經(jīng)歷提交被拒的原因主要有這幾類DRC違規(guī)最常見、LVS不匹配、面積超標、引腳映射錯誤、GDS層號不對。DRC違規(guī)里又分金屬間距、通孔enclosure、天線效應、密度違規(guī)等。LVS不匹配通常是網(wǎng)表里有多余的單元或者少了某個連接。避坑技巧提交前用KLayout打開GDS文件肉眼檢查一遍版圖。KLayout是開源版圖查看器能加載Sky130的層號映射文件顯示效果和商業(yè)工具差不多。我每次提交前都會用KLayout過一遍至少能發(fā)現(xiàn)明顯的版圖錯誤。下面這張表是我整理的高頻問題速查表問題現(xiàn)象可能原因排查方法解決措施綜合報找不到模塊文件路徑錯誤或模塊名拼寫錯誤檢查read_verilog路徑和頂層模塊名修正路徑或模塊名布局擁塞嚴重布局密度過高或面積太小查看全局布線擁塞熱圖降低密度或擴大面積DRC金屬間距違規(guī)布線密度過高查看DRC報告定位坐標調(diào)整布局密度或手動修改天線效應違規(guī)長金屬線直接連柵極查看天線違規(guī)報告插入天線二極管或跳層建立時間違例數(shù)據(jù)路徑延遲過大OpenSTA時序報告加緩沖器或換強驅(qū)動單元LVS不匹配網(wǎng)表與版圖不一致Netgen LVS報告檢查網(wǎng)表連接和單元實例提交被拒DRC/LVS/面積/引腳問題對照提交檢查清單逐項修復后重新提交6. 我踩過的那些坑和最后幾句實在話第一次跑通全流程花了我將近三周時間其中大部分時間不是在學工具而是在跟環(huán)境配置和版本兼容性作斗爭。最崩潰的一次是PDK版本和OpenROAD版本不匹配導致布局階段所有單元都變成了方塊查了兩天才發(fā)現(xiàn)是LEF文件里的層號定義變了。所以我的第一個建議是鎖定版本。PDK用哪個版本、OpenROAD用哪個版本、Yosys用哪個版本全部記下來不要隨便升級。第二個建議是從小設計開始。不要一上來就搞CPU或者大型加速器先寫一個計數(shù)器或者簡單的狀態(tài)機跑通全流程把每個步驟的輸出都看一遍。理解了流程之后再逐步增加設計復雜度。我見過太多人一上來就搞大設計結果卡在某個步驟上幾個月動不了。第三個建議是善用社區(qū)。OpenROAD和Sky130的GitHub Issues里有很多人遇到過和你一樣的問題搜索一下往往能找到答案。OpenMPW的Slack頻道也很活躍提問的時候把報錯信息、工具版本、復現(xiàn)步驟寫清楚一般都能得到回復。最后說一句實在話開源EDA工具鏈的成熟度確實不如商業(yè)工具報錯信息不夠友好文檔也有缺失。但它的價值在于透明和可及。你能看到每一步在做什么能修改腳本控制流程能真正理解芯片后端設計的每個環(huán)節(jié)。這種理解是商業(yè)工具的黑盒流程給不了的。Sky130雖然工藝老但作為學習平臺足夠了。流片一次的成本被OpenMPW攤薄到幾乎為零這種機會在幾年前是不可想象的。如果你也在跑這條流程遇到卡住的地方不妨回到最基本的步驟檢查文件路徑、檢查版本匹配、檢查約束定義。大部分問題都出在這三件事上。 開源EDA+Sky130 PDK實戰(zhàn)：從RTL到GDSII的個人流片全流程
1. 為什么我要把開源EDA和Sky130 PDK串起來講第一次聽說“開源流片”這四個字的時候我正蹲在實驗室角落里啃一份商業(yè)PDK的NDA文檔滿屏的“Confidential”水印看得人頭皮發(fā)麻。那時候想跑一次完整流程要么進大廠拿內(nèi)部賬號要么花幾十萬買License個人開發(fā)者基本沒戲。后來OpenMPW項目把Sky130 PDK和OpenROAD這套開源工具鏈推到臺前我才意識到——原來從RTL到GDSII這條路真的可以完全用開源工具走通而且真能送去流片。這篇內(nèi)容就是把我從零搭環(huán)境、跑通全流程、踩坑填坑的整個過程攤開來講。核心關鍵詞就幾個開源EDA、Sky130 PDK、流片、OpenMPW、OpenROAD。適合誰看如果你是數(shù)字IC設計方向的學生、想驗證自己小設計的獨立開發(fā)者、或者單純對芯片后端流程好奇的軟件工程師這篇都能給你一條能走通的路。我不講虛的只講我實際跑過的命令、遇到的報錯、以及最后怎么把GDS交出去的。需要提前說明的是開源EDA工具鏈和商業(yè)工具在成熟度上仍有差距Sky130作為130nm工藝雖然“老”但恰恰因為老它的設計規(guī)則相對寬松適合練手。OpenMPW這類多項目晶圓計劃則把流片成本攤薄到個人可承受的范圍。這幾個東西湊在一起才讓“個人流片”從笑話變成了現(xiàn)實。2. 開源EDA工具鏈的整體設計與選型邏輯2.1 為什么是OpenROAD而不是其他開源方案開源EDA工具不少但真正能撐起完整RTL-to-GDSII流程的OpenROAD是目前最成體系的一個。我最初試過用Qflow它確實輕量但綜合、布局布線、時序分析各環(huán)節(jié)割裂感很強腳本膠水層寫起來很痛苦。OpenROAD把邏輯綜合通過Yosys、布局RePlAce、時鐘樹綜合TritonCTS、布線FastRoute/TritonRoute、時序分析OpenSTA整合到一個統(tǒng)一的Tcl驅(qū)動環(huán)境里流程連貫性好了很多。選OpenROAD的另一個理由是它對Sky130 PDK的支持最完整。OpenROAD的GitHub倉庫里直接帶了Sky130的示例配置包括LEF、DEF、Liberty文件的位置和參數(shù)模板。你不需要自己去拼湊PDK文件路徑省了大量試錯時間。相比之下OpenLANE現(xiàn)在叫OpenLane雖然也是基于OpenROAD的封裝但它更偏向“一鍵流片”的自動化流程對想理解每一步在干什么的人反而不夠透明。我的建議是先用OpenLane跑通一個例子建立信心然后切到OpenROAD手動控制每一步這樣既能看到結果又能學到東西。2.2 Sky130 PDK到底給了我們什么Sky130是SkyWater Foundry的130nm CMOS工藝PDK全稱Process Design Kit。它包含的東西比你想象的多器件模型SPICE模型、設計規(guī)則DRC規(guī)則文件、版圖圖層定義GDS層號、標準單元庫Sky130_fd_sc_hd等、IO庫、SRAM編譯器生成的宏單元等。開源的部分主要是數(shù)字標準單元庫和基礎器件模擬器件模型也有但精度需要自己評估。我實際用到的PDK組件主要是這幾類Liberty文件.lib給綜合和時序分析用描述每個標準單元的時序、功耗、面積LEF文件給布局布線用描述單元的物理輪廓和引腳位置GDS文件是標準單元的版圖最終和你的設計合并技術LEF定義金屬層、通孔、設計規(guī)則。這些文件在Sky130 PDK的GitHub倉庫里按目錄分得很清楚但版本很多選錯版本會導致后面各種奇怪報錯。注意Sky130 PDK有多個版本分支比如sky130_fd_sc_hd和sky130_fd_sc_hs前者是高密度庫后者是高速度庫。新手建議從hd開始因為它的文檔和示例最多踩坑時容易找到參考。2.3 OpenMPW流片計劃的實際運作方式OpenMPWOpen Multi-Project Wafer是Google和SkyWater合作的項目定期把多個開源設計拼到一個晶圓上流片然后免費或低成本提供給參與者。它的運作模式是你提交GDSII文件他們負責拼版、流片、封裝、測試最后寄給你芯片。聽起來很美好但有幾個硬性約束你必須提前知道。第一面積限制。每個設計被分配一個固定大小的區(qū)域通常是幾平方毫米你的設計不能超過這個框。第二引腳限制?？捎玫腎O焊盤數(shù)量和位置是固定的你的頂層端口必須映射到指定的焊盤上。第三DRC必須干凈。任何DRC違規(guī)都會被直接拒絕沒有商量余地。第四提交窗口是周期性的錯過一次要等下一輪。我建議在動手之前先去OpenMPW的文檔頁把最新的提交指南讀三遍把面積、引腳、層號這些約束抄在紙上貼在顯示器旁邊。3. 環(huán)境搭建與核心工具配置的實操細節(jié)3.1 系統(tǒng)環(huán)境與依賴安裝的坑我用的系統(tǒng)是Ubuntu 20.04 LTS這是OpenROAD官方推薦的環(huán)境。22.04也能跑但有些依賴包的版本會沖突需要手動降級。內(nèi)存建議至少16GB因為布局布線階段對內(nèi)存消耗很大8GB跑小設計勉強夠但很容易被OOM Killer干掉。磁盤空間留50GB以上PDK文件、工具二進制、中間結果加起來很占地方。安裝方式我推薦用OpenROAD提供的預編譯二進制包而不是從源碼編譯。源碼編譯一次要一個多小時而且經(jīng)?？ㄔ谀硞€依賴上。預編譯包解壓就能用省心很多。具體步驟是去OpenROAD的GitHub Releases頁面下載對應系統(tǒng)的壓縮包解壓到/opt/openroad然后把/opt/openroad/bin加到PATH里。# 下載并解壓OpenROAD預編譯包 wget https://github.com/The-OpenROAD-Project/OpenROAD/releases/download/v2.0/openroad-2.0-ubuntu20.04.tar.gz tar -xzf openroad-2.0-ubuntu20.04.tar.gz -C /opt/ echo export PATH/opt/openroad/bin:$PATH ~/.bashrc source ~/.bashrcSky130 PDK的獲取方式有兩種一種是用volare工具自動管理版本另一種是手動clone倉庫。我建議用volare因為它能幫你處理版本切換和文件路徑問題。安裝volare用pip就行pip install volare volare enable --pdk sky130 --version 0.0.0-20230901這個命令會把PDK下載到~/.volare目錄下并設置好環(huán)境變量。之后在OpenROAD腳本里引用PDK路徑時直接用$PDK_ROOT和$PDK變量即可。3.2 標準單元庫的選擇與配置Sky130的標準單元庫有好幾個變體我前面提到新手從sky130_fd_sc_hd開始。這個庫的單元高度是2.72微米軌道數(shù)是9驅(qū)動能力從1到8倍不等。選庫的時候要注意Liberty文件和LEF文件的版本必須匹配否則會出現(xiàn)單元引腳對不上的問題。配置OpenROAD時你需要準備一個Tcl腳本里面定義好各個文件的路徑。我通常把路徑定義放在腳本開頭方便修改set PDK_ROOT $env(PDK_ROOT) set PDK $env(PDK) set LIB_DIR $PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd set TECH_LEF $PDK_ROOT/$PDK/libs.ref/sky130_fd_sc_hd/techlef/sky130_fd_sc_hd__nom.tlef set CELL_LEF $LIB_DIR/lef/sky130_fd_sc_hd.lef set LIB_FILE $LIB_DIR/lib/sky130_fd_sc_hd__tt_025C_1v80.lib這里tt_025C_1v80表示典型工藝角、25攝氏度、1.8V電壓。做時序分析時你可能還需要其他工藝角比如ss慢速和ff快速但初期跑通流程用tt就夠了。3.3 Yosys綜合腳本的編寫要點Yosys負責把Verilog RTL轉成門級網(wǎng)表。OpenROAD流程里通常用yosys配合abc做邏輯優(yōu)化和映射。我寫綜合腳本時踩過的坑主要是兩點一是忘記設置read_verilog的-sv選項導致SystemVerilog語法報錯二是沒有正確指定目標庫導致映射出來的單元不可用。一個能跑通的綜合腳本大概長這樣# 讀取設計 read_verilog -sv ./src/top.v # 讀取標準單元庫 read_liberty $LIB_FILE # 設置頂層模塊 hierarchy -top top # 綜合 synth -top top # 映射到標準單元 abc -liberty $LIB_FILE # 輸出網(wǎng)表 write_verilog ./out/top_synth.v綜合完成后一定要檢查一下網(wǎng)表里有沒有$_AND_之類的通用單元殘留如果有說明映射沒做干凈后面布局會報錯。另外綜合報告里的面積和時序估算只能參考實際以布局布線后的結果為準。實操心得Yosys的綜合腳本里abc那一步可以加-script參數(shù)指定優(yōu)化腳本比如strash;scorr;ifraig;retime;dch;map能改善面積和時序。但新手先用默認參數(shù)跑通再說優(yōu)化是后面的事。4. 從RTL到GDSII的完整流程拆解4.1 布局規(guī)劃與電源網(wǎng)絡設計布局規(guī)劃Floorplan是后端流程的第一步?jīng)Q定了芯片的物理輪廓和電源分布。OpenROAD里用initialize_floorplan命令設置芯片面積和核心區(qū)域。面積怎么定我的經(jīng)驗是先用綜合后的單元總面積乘以1.5到2.0的系數(shù)作為初始值跑完布局后再根據(jù)擁塞情況調(diào)整。initialize_floorplan -die_area {0 0 1000 1000} \ -core_area {10 10 990 990} \ -site unithd這里unithd是Sky130標準單元的站點名稱必須和LEF文件里定義的一致。電源網(wǎng)絡PDN用pdngen命令生成需要提前寫好PDN配置文件定義電源環(huán)、電源條帶的寬度和間距。Sky130的金屬層從met1到met5我通常用met4和met5做電源網(wǎng)格因為高層金屬電阻小、電流承載能力強。PDN配置里有個參數(shù)叫pitch控制電源條帶的間距。設太小會浪費布線資源設太大又會導致IR Drop超標。我的經(jīng)驗值是每50到100微米一條電源條帶具體看設計的功耗密度。IR Drop分析可以用OpenROAD自帶的analyze_power_grid命令跑但需要額外的電源pad信息初期可以先跳過。4.2 布局與時鐘樹綜合的關鍵參數(shù)布局階段用global_placement和detailed_placement兩個命令。全局布局決定單元的大致位置詳細布局做合法化確保單元不重疊且對齊到站點網(wǎng)格。全局布局有個參數(shù)叫-density默認0.7意思是標準單元占核心區(qū)域面積的70%。如果設計擁塞嚴重可以降到0.6或0.5給布線留更多空間。global_placement -density 0.65 detailed_placement時鐘樹綜合CTS用clock_tree_synthesis命令核心參數(shù)是-buf_list指定用來構建時鐘樹的緩沖器單元。Sky130的hd庫里有sky130_fd_sc_hd__clkbuf_4、clkbuf_8等我一般選clkbuf_4作為主力驅(qū)動不夠時自動升級到clkbuf_8。CTS之后要做時序分析檢查時鐘偏斜skew和插入延遲latency。Sky130這種老工藝的時鐘樹相對好做skew控制在100ps以內(nèi)不難。注意CTS之前一定要確保時鐘定義正確。在SDC文件里用create_clock定義時鐘周期和端口否則CTS不知道要優(yōu)化什么。SDC文件里還要設置輸入輸出延遲、驅(qū)動能力、負載電容等約束這些直接影響時序結果。4.3 布線流程與DRC清理布線分全局布線和詳細布線兩步。全局布線用global_route它規(guī)劃每條網(wǎng)絡的走線路徑但不指定具體金屬層和通孔。詳細布線用detailed_route它實際分配金屬層、放置通孔、滿足DRC規(guī)則。Sky130的DRC規(guī)則相對寬松但金屬間距、通孔 enclosure、天線效應這些還是要小心。global_route -congestion_iterations 30 detailed_route -output_drc ./out/drc.rpt \ -verbose 1詳細布線跑完后會生成DRC報告。如果報告里違規(guī)數(shù)量是0恭喜你可以進入下一步。如果有違規(guī)先看違規(guī)類型如果是間距違規(guī)可能是布線密度太高回去調(diào)布局密度如果是通孔違規(guī)可能是PDN和信號線沖突需要調(diào)整PDN配置。我遇到過最頭疼的是天線效應違規(guī)解決方法是插入天線二極管或者調(diào)整布線層。DRC清理是個迭代過程可能要來回改布局和布線參數(shù)好幾次。我的建議是每次只改一個參數(shù)改完重新跑記錄結果這樣才能知道哪個參數(shù)起了作用。4.4 GDS輸出與流片提交檢查清單所有步驟跑完后用write_gds命令輸出GDSII文件。但輸出之前必須做幾件事第一跑一次完整的DRC檢查確保沒有違規(guī)第二跑LVS版圖與原理圖一致性檢查確保版圖網(wǎng)表和綜合網(wǎng)表一致第三檢查頂層端口是否映射到了OpenMPW指定的焊盤位置。write_gds ./out/top.gdsLVS我用的工具是Netgen它需要網(wǎng)表文件和GDS文件作為輸入。Sky130 PDK里帶了Netgen的配置模板照著改路徑就行。LVS通過后把GDS文件按OpenMPW的要求打包提交。提交前再對照檢查清單過一遍面積是否超標、引腳是否匹配、層號是否正確、DRC是否干凈、LVS是否通過。這五項有任何一項不過提交都會被拒。5. 常見問題與排查技巧實錄5.1 綜合階段報錯與解決綜合階段最常見的報錯是“找不到模塊”或“無法映射單元”。前者通常是Verilog文件路徑不對或者模塊名拼寫錯誤后者一般是Liberty文件沒讀進來或者目標庫名稱寫錯。我遇到過一次abc報“no liberty cell found”查了半天發(fā)現(xiàn)是Liberty文件里的單元命名和LEF文件不一致?lián)Q了一個版本的PDK就好了。另一個坑是SystemVerilog語法支持不全。Yosys對SystemVerilog的支持在逐步完善但有些高級語法比如interface、structpacked數(shù)組還是有問題。我的做法是盡量用Verilog-2001風格的語法寫RTL實在要用SystemVerilog就先單獨跑read_verilog -sv測試一下。5.2 布局布線階段的典型故障布局階段最怕的是擁塞congestion。OpenROAD的全局布線器會報告擁塞熱圖如果某片區(qū)域紅得發(fā)紫說明那里布線資源不夠。解決辦法有三個降低布局密度、調(diào)整單元位置、增加芯片面積。我一般先降密度到0.55試試不行再擴面積。詳細布線階段的DRC違規(guī)前面提過了這里補充一個特殊情況天線效應違規(guī)。Sky130的金屬層在刻蝕過程中會積累電荷如果某條長金屬線直接連到晶體管柵極電荷可能擊穿柵氧。解決方法是插入天線二極管或者在布線時跳層。OpenROAD的詳細布線器有-antenna選項可以自動修復部分天線違規(guī)但不是萬能的。5.3 時序違例的調(diào)試思路時序違例分建立時間setup和保持時間hold兩種。建立時間違例說明數(shù)據(jù)路徑太慢解決辦法是加緩沖器、換驅(qū)動更強的單元、或者降低時鐘頻率。保持時間違例說明數(shù)據(jù)路徑太快解決辦法是加延遲單元或者調(diào)整時鐘樹。OpenROAD的repair_timing命令可以自動修復部分違例但手動分析更可靠。我習慣用OpenSTA單獨跑時序分析生成時序報告然后逐條路徑看。報告里會列出每條路徑的起點、終點、數(shù)據(jù)路徑延遲、時鐘路徑延遲、slack值。slack為負就是違例負得越多越嚴重。先修最差的路徑修完再跑一遍迭代幾次就能收斂。5.4 流片提交被拒的常見原因根據(jù)OpenMPW社區(qū)里的討論和我自己的經(jīng)歷提交被拒的原因主要有這幾類DRC違規(guī)最常見、LVS不匹配、面積超標、引腳映射錯誤、GDS層號不對。DRC違規(guī)里又分金屬間距、通孔enclosure、天線效應、密度違規(guī)等。LVS不匹配通常是網(wǎng)表里有多余的單元或者少了某個連接。避坑技巧提交前用KLayout打開GDS文件肉眼檢查一遍版圖。KLayout是開源版圖查看器能加載Sky130的層號映射文件顯示效果和商業(yè)工具差不多。我每次提交前都會用KLayout過一遍至少能發(fā)現(xiàn)明顯的版圖錯誤。下面這張表是我整理的高頻問題速查表問題現(xiàn)象可能原因排查方法解決措施綜合報找不到模塊文件路徑錯誤或模塊名拼寫錯誤檢查read_verilog路徑和頂層模塊名修正路徑或模塊名布局擁塞嚴重布局密度過高或面積太小查看全局布線擁塞熱圖降低密度或擴大面積DRC金屬間距違規(guī)布線密度過高查看DRC報告定位坐標調(diào)整布局密度或手動修改天線效應違規(guī)長金屬線直接連柵極查看天線違規(guī)報告插入天線二極管或跳層建立時間違例數(shù)據(jù)路徑延遲過大OpenSTA時序報告加緩沖器或換強驅(qū)動單元LVS不匹配網(wǎng)表與版圖不一致Netgen LVS報告檢查網(wǎng)表連接和單元實例提交被拒DRC/LVS/面積/引腳問題對照提交檢查清單逐項修復后重新提交6. 我踩過的那些坑和最后幾句實在話第一次跑通全流程花了我將近三周時間其中大部分時間不是在學工具而是在跟環(huán)境配置和版本兼容性作斗爭。最崩潰的一次是PDK版本和OpenROAD版本不匹配導致布局階段所有單元都變成了方塊查了兩天才發(fā)現(xiàn)是LEF文件里的層號定義變了。所以我的第一個建議是鎖定版本。PDK用哪個版本、OpenROAD用哪個版本、Yosys用哪個版本全部記下來不要隨便升級。第二個建議是從小設計開始。不要一上來就搞CPU或者大型加速器先寫一個計數(shù)器或者簡單的狀態(tài)機跑通全流程把每個步驟的輸出都看一遍。理解了流程之后再逐步增加設計復雜度。我見過太多人一上來就搞大設計結果卡在某個步驟上幾個月動不了。第三個建議是善用社區(qū)。OpenROAD和Sky130的GitHub Issues里有很多人遇到過和你一樣的問題搜索一下往往能找到答案。OpenMPW的Slack頻道也很活躍提問的時候把報錯信息、工具版本、復現(xiàn)步驟寫清楚一般都能得到回復。最后說一句實在話開源EDA工具鏈的成熟度確實不如商業(yè)工具報錯信息不夠友好文檔也有缺失。但它的價值在于透明和可及。你能看到每一步在做什么能修改腳本控制流程能真正理解芯片后端設計的每個環(huán)節(jié)。這種理解是商業(yè)工具的黑盒流程給不了的。Sky130雖然工藝老但作為學習平臺足夠了。流片一次的成本被OpenMPW攤薄到幾乎為零這種機會在幾年前是不可想象的。如果你也在跑這條流程遇到卡住的地方不妨回到最基本的步驟檢查文件路徑、檢查版本匹配、檢查約束定義。大部分問題都出在這三件事上。