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