跳轉到

2.4 ORFS：把整條流程裝進一個 Makefile#

有了統一的 OpenROAD 引擎，接下來的問題是：誰來編排？RTL 要先經過 Yosys 綜合，產出的網表交給 OpenROAD 做 floorplanning、placement、CTS、routing，再經過寄生參數萃取與時序簽核，最後用 KLayout 匯出 GDS。這條鏈上每個工具都有自己的輸入輸出、環境變數與選項，如果每次都手寫 Tcl 腳本串接，使用者很快就會淹沒在膠水程式碼裡。

OpenROAD 團隊的答案不是發明新的流程語言，而是選擇了最古老、最普及的建置工具：GNU Make。這就是 ORFS（OpenROAD-Flow-Scripts），一個以 Makefile 為核心的完整 RTL-to-GDSII 流程框架。

Makefile 哲學#

選 Make 是深思熟慮的。Make 天生就是為「依賴追蹤與增量建置」而生：目標檔案比來源新就跳過重做。把晶片流程對映到這個模型非常自然——objects/sky130hd/gcd/base/3_3_place.odb 依賴 2_4_cts.odb，後者依賴 2_2_floorplan.odb，一路回溯到 RTL 原始碼與 SDC 約束。你改了 RTL，Make 知道要從綜合重跑；你只改了 routing 選項，Make 知道 CTS 之前都不用重跑。對一個動輒數小時的物理設計流程，增量能力是生產力的關鍵。

這個選擇也有文化意涵。Make 是 1977 年 Stuart Feldman 在 Bell Labs 寫下的工具，四十多年來是工程師的共同語言。用 Make 寫晶片流程，等於宣稱「晶片設計流程就該像編譯軟體一樣例行化」——這正是 OpenROAD「24 小時、無人工介入」願景的延伸：流程不該是手工藝，而該是自動化生產線。

目錄結構與平台概念#

ORFS 的倉庫結構一目瞭然：

OpenROAD-flow-scripts/
├── flow/
│   ├── Makefile
│   ├── designs/          # 每個設計一個目錄，含 config.mk 與 RTL
│   │   ├── gcd/
│   │   └── ibex/
│   └── platforms/        # 每個製程平台一個目錄
│       ├── sky130hd/
│       ├── nangate45/
│       └── asap7/
└── tools/                # OpenROAD、Yosys 等子模組

兩個關鍵目錄值得細看。designs/ 裡每個設計有一個 config.mk，宣告設計層的資訊：

export DESIGN_NAME      = gcd
export PLATFORM         = sky130hd
export VERILOG_FILES    = ./designs/src/gcd/gcd.v
export SDC_FILE         = ./designs/sky130hd/gcd/constraint.sdc
export CORE_UTILIZATION = 45

platforms/ 則封裝製程層的一切：tech LEF、cell LEF、Liberty 時序庫（不同 corner 各一份）、層電阻電容模型、以及各階段工具的預設選項。SkyWater 130nm（sky130hd）與 ASAP7 是 ORFS 內建最具代表性的兩個平台——前者是真實可流片的開源 PDK，後者是亞利桑那州立大學發表的 7nm 學術 PDK，用來前瞻先進節點的設計行為。Nangate45 則是長年用於學術論文的合成庫。這個 platform 抽象讓「同一個設計、不同製程」成為換一行設定的事。

跑一個設計#

ORFS 的標準用法只有一行：

cd flow
make DESIGN_CONFIG=./designs/sky130hd/gcd/config.mk

這條命令會依序執行綜合（Yosys）、floorplanning、placement、CTS、routing、簽核與 GDS 產生，過程中每個階段的結果都落在 objects/ 下，日誌與報告則在 logs/ 與 reports/。GCD（greatest common divisor）是 ORFS 的 "hello world"——小到幾分鐘能跑完，卻涵蓋所有階段。想看某個階段的細節，可以單獨呼叫對應的 target：

make DESIGN_CONFIG=./designs/sky130hd/gcd/config.mk place
make DESIGN_CONFIG=./designs/sky130hd/gcd/config.mk route
make DESIGN_CONFIG=./designs/sky130hd/gcd/config.mk show    # 啟動 GUI 檢視

流程各階段的編號（1_1 綜合、2_2 floorplan、2_3 place……）讓 logs/ 下的日誌排序即流程順序，這種「可預期性」對除錯極為重要：當 placement 之後時序崩壞，你可以直接翻出對應日誌檢查，而不是在一個巨大的輸出裡搜尋。

從 ORFS 回看工具鏈生態#

ORFS 的存在，也改變了我們看待其他開源工具鏈的角度。它與 veryl2chip 這類小型工具鏈處於光譜的兩端：ORFS 追求「工業級流程的完整與可調」，暴露每個階段的每一個旋鈕；veryl2chip 追求「最小可用路徑」，把複雜性藏在一個 v2c asic 命令之後。但兩者共用同一套格式與思想——Verilog 進、DEF 與 GDS 出、Liberty 描述時序、LEF 描述單元。學會 ORFS 的模型，再回頭看 veryl2chip 的輸出，你會發現那正是同一張地圖的縮略版。

更重要的是，ORFS 證明了「全自動流程」不只是願景，而是每天在數百所大學與研究機構中執行的現實。教師用它在課堂上讓全班跑同一個設計；研究者用它做基準測試，比較不同 placement 演算法在同一平台上的表現；甚至有新創公司以 ORFS 為骨幹做產品開發。當流程本身成為開放的、可被版本控制的程式碼，晶片設計的知識就完成了最後一塊拼圖：從演算法、資料庫、腳本介面到整條流程，全部公開、全部可學、全部可改。