晶片設計的版本控制：為什麼一顆晶片有上百個 revision
在進入細節之前，先建立一份「晶片圈黑話對照表」，後面會一直用到：
術語
英文全稱
白話解釋
Revision / Rev
Revision
泛稱「設計版本」，可以指整個專案、某個 IP，也可以指某個檔案。本文的主角。
Tapeout（TO）
Tape-out
把最終 GDS 交付給晶圓廠開始做光罩的動作，俗稱「流片」。
Spin / Respin
Silicon respin
晶片做出來後發現問題，修改設計再投一次片。每一次 respin 都是一筆可觀的費用。
ECO
Engineering Change Order
工程變更單。在不重做全部光罩的前提下，只改幾層光罩來修 bug，是省錢的救命工具。
MPW / Shuttle
Multi-Project Wafer
多專案晶圓。把很多團隊的小晶片拼在同一片晶圓上分攤光罩費，學界與新創常用。
Baseline
Baseline
基線。某個時間點上「全套設計檔案的一致性快照」，是所有版本管理的核心概念。
PDK
Process Design Kit
晶圓廠提供的製程設計套件，內含元件模型、DRC 規則、金屬堆疊資訊。它本身也有版本。
IP
Intellectual Property
可重複使用的電路模組，例如 CPU 核、USB PHY、PLL。外購 IP 會自帶版本號。
看懂這張表，你就會發現一件事：「版本」在晶片業不是單一概念，而是至少三種東西的混合體——檔案的版本（這行 RTL 改了什麼）、設計狀態的版本（這個時間點整顆晶片長什麼樣）、以及實體晶片的版本（這批矽晶圓是哪一版設計做出來的）。這三者必須嚴格對應，否則就會出現「工程師以為自己在測 A 版、實際上實驗室裡是 B 版」的經典慘案。
1.3 為什麼晶片不能「一次做對」：修改成本的階梯
軟體工程有一個很有名的比喻：改 bug 的成本隨時間指數上升。晶片業的版本更極端，因為它的「修改成本階梯」有幾個斷崖式的跳躍：
改 RTL 一行：成本大約是一杯咖啡加上重新跑一次回歸測試的時間。
改到合成後的網表或腳本：成本變成幾天到幾週的重新收斂。
所以，上百個 revision 的存在，本質上是一種「把修改集中在便宜的地方」的策略。工程師情願在 RTL 階段改五十次、在驗證階段改三十次、在實體階段用 ECO 改五次，也不願意在光罩做完之後才發現問題。版本多，不是混亂，而是「改了非常多次，而且每一次都留下紀錄」的證明。
二、上百個 revision 從哪裡來？拆解版本膨脹的六大來源
接下來我們把「上百」這個數字拆開來看。假設一個中大型 SoC 專案，開發期十八到二十四個月，團隊規模五十到兩百人，我們可以從六個方向理解版本為什麼會累積到這個量級。
2.1 來源一：規格變更與功能迭代
晶片的規格不是凍結的。客戶會在開發過程中改需求，市場部門會因為競品發表而追加功能，法規或標準（例如 USB、PCIe、Wi-Fi、藍牙）會改版。每一次規格變更，都會沿著架構、RTL、驗證、韌體一路傳遞下去。
以一個 USB 控制器為例，光是規格從 USB 3.2 Gen1 調整到 Gen2，就可能牽動 PHY 的選擇、時脈架構、緩衝區大小、驗證案例的重新設計。這不會只產生一個 revision，而是至少產生「架構 v1.1、RTL r1.3、驗證環境 v2.0、韌體 fw-1.4」這樣一整組新版本。
更麻煩的是「部分功能先做、部分功能後補」的現實。很多專案採用 agile 式的階段交付，每個階段結束就切一個 baseline。十八個月、每六到八週一個 baseline，光主線就累積十幾個節點；再加上每個 baseline 內部的修修补补，同一個模組出現 r0.1 到 r0.9、再到 r1.0，是再正常不過的事。
2.2 來源二：PPA 的來回權衡
PPA 是 Performance（效能）、Power（功耗）、Area（面積）的縮寫，是晶片設計的鐵三角。這三者互相拉扯：想跑更快就要加電壓或加管線，功耗就上升；想省電就要降頻或關電源域，效能就下降；想縮小面積就要簡化電路，時序就更難收斂。
這個權衡過程會產生大量「實驗性版本」。例如：
嘗試把某個 pipeline 從三級改成四級，看時脈能不能從 1.8GHz 推到 2.2GHz。
嘗試把某個 always-on 的 SRAM 換成 retention flop，看漏電能省多少。
嘗試把匯流排頻寬加倍，看面積會不會超出預算。
這些嘗試不一定會進到最終版本，但每一個嘗試都需要被記錄、被比較、被回溯。業界常見的做法是開一條「實驗分支」，跑完 PPA 報告後保留標籤，於是一個模組就可能累積十幾個「試過但不採用」的版本。這些版本不會消失，因為半年後你可能會想：「當初那個四級 pipeline 的方案，犧牲多少面積換來多少效能？」沒有版本紀錄，這個問題就無法回答。
2.3 來源三：Bug、ECO 與驗證回饋
驗證是版本產生器。一個大型 SoC 的驗證團隊可能跑數百萬個測試案例，隨機驗證（random verification）每晚都在產生新 seed、新場景。每一個被找到的 bug，都會對應到一個 RTL 修正版本。
而當設計進入實體階段、甚至已經 tapeout 之後，bug 的修正方式就變成 ECO。ECO 有幾種層級：
一顆量產晶片在生命週期中，出現三到五次 ECO 是常態。每一次 ECO 都會產生一個新的 revision 標籤，而且這些標籤必須精確對應到「哪幾層光罩被改過」，否則晶圓廠會做錯。
2.4 來源四：製程、PDK 與 IP 的版本綁定
這是軟體開發者最難想像的一點：晶片的版本不只取決於你自己的程式碼，還取決於別人給你的東西。
晶圓廠的 PDK 會更新。可能是元件模型修正、DRC 規則調整、金屬堆疊選項變更。你用了 PDK 的哪一版，必須被記錄下來，因為同一份 GDS 在不同版本的 DRC 下，可能一個通過、一個報錯。
外購 IP 也有版本。一顆 CPU 核可能從 r1p2 更新到 r1p3，修了某個 errata；一個 PHY 可能從 v2.0 換到 v2.1，功耗特性不同。你的 SoC 版本必須明確記錄「我用了哪些 IP 的哪些版本」，這在業界叫做物料清單（BOM）或 IP manifest。少了這份清單，你就無法重建三個月前的那顆晶片。
再加上 EDA 工具本身的版本。合成工具從 2024.03 換到 2024.09，同一份 RTL 的合成結果可能就不一樣。嚴謹的團隊會把工具版本也納入 baseline 的一部分。
2.5 來源五：驗證 corner 與簽核條件
晶片要在各種極端條件下都能工作，這些條件叫做 corner。常見的組合包括：
電壓 corner：標稱電壓、低電壓、高電壓。
溫度 corner：-40°C、25°C、85°C、125°C。
模式 corner：正常模式、省電模式、測試模式、boot 模式。
這些組合乘起來，可能出現數十到數百種簽核情境。每一種情境的時序報告、功耗報告、IR drop 報告都需要被保存，而且必須對應到某一個設計版本。這也是為什麼「版本」在晶片業往往不是一個數字，而是一個包含「設計版本 + corner 設定 + 工具版本 + 腳本版本」的複合鍵。
2.6 來源六：分支策略與多人協作
最後一個來源是最貼近軟體工程的：分支。一個大型專案通常會有以下幾條線同時存在：
主幹（main / trunk）：所有新功能合併的目標。
功能分支：每個團隊或每個子系統各開一條。
實驗分支：前面提到的 PPA 嘗試。
客戶分支：如果這顆晶片是為特定客戶做客製，可能會有客戶專屬的分支。
每一條分支上的每一次合併，都會產生一個合併點；每一個合併點在設計管理工具裡都可能被標記成一個版本節點。再加上每個子系統（CPU cluster、GPU、記憶體控制器、各類周邊）各自有自己的版本節奏，最後在專案層級彙整時，「上百個 revision」其實還是保守估計。
三、晶片版本控制的工具鏈：為什麼不能用純 Git？
理解了版本從哪裡來，下一個問題是：這麼多版本要怎麼管？很多人的第一反應是「用 Git 啊，Git 不是萬能嗎？」答案是：Git 很好，但晶片業的規模與檔案特性，讓它不能只靠 Git。以下是實務上的幾個關鍵差異。
3.1 Git 的三個痛點：大檔案、二進位、檔案鎖定
第一，大檔案。一份 GDSII 動輒數 GB 到數十 GB，一個資料庫動輒數百 GB 到 TB 等級。Git 的設計是「每個 clone 都是完整歷史」，這種規模會讓 clone 變成一場災難。雖然 Git LFS、partial clone、sparse checkout 已經改善很多，但在十幾年前的晶片業，這根本不是選項。
第二，二進位檔案無法合併。RTL 是文字檔，可以 diff、可以 merge；但 GDS、netlist、波形檔（VCD/FSDB）、布局資料庫都是二進位。二進位檔案在 Git 裡只能「整份替換」，無法看出改了哪裡，也無法解決衝突。版本控制對二進位檔的價值，只剩下「保存與回溯」，而不是「合併」。
第三，檔案鎖定（file locking）。在軟體開發裡，兩個人同時改同一個檔案，靠 merge 解決就好。但在晶片設計裡，某些檔案（例如布局資料庫、類比電路圖）是「不能同時兩個人改」的，因為合併後的結果在物理上沒有意義。所以設計管理工具必須支援「check out 後鎖定」，這在純 Git 的工作流程裡是比較後期才補上的功能。
3.2 業界常見的工具盤點
因為上述限制，晶片業發展出自己的一套工具生態：
工具
類型
常見使用場景
Perforce Helix Core（P4）
集中式版本控制
大型 SoC 專案的檔案庫，支援大檔案、檔案鎖定、細緻權限。IC 設計業的事實標準之一。
Synopsys DesignSync
設計資料管理
與 EDA 流程深度整合，常見於類比、混合訊號與大型數位專案。
ClioSoft SOS
設計資料管理
與 Cadence Virtuoso 等工具整合良好，類比電路團隊常見。
IC Manage
設計資料管理
提供 IP 管理、baseline、工作區管理等功能。
Subversion（SVN）
集中式版本控制
較小型團隊或學術單位仍在使用，成本低、概念簡單。
Git + Git LFS
分散式版本控制
Methodics / Percipient
IP 生命週期管理
管理大量 IP 的版本、相容性與授權。
要注意的是，這些工具通常不是「選一個」，而是「分層使用」。一個典型的配置可能是：RTL 與腳本用 Perforce 或 Git 管理，布局資料庫用 DesignSync 或 SOS 管理，IP 用專門的 IP 管理平台，而專案層級的 baseline 則靠一套自製或商用的 manifest 系統串起來。
3.3 Baseline、Tag 與可追溯性：從 GDS 反推回哪一行 RTL
版本控制真正的價值，不是「保存舊檔案」，而是可追溯性（traceability）。也就是說，當你手上拿著一片從晶圓廠回來的晶片，或是一份客戶抱怨的報告，你能不能回答這個問題：
這顆晶片是用哪一版 RTL、哪一版 PDK、哪一版 IP、哪一版工具、哪一組腳本、哪一個 corner 設定做出來的？
聽起來很基本，但要做到非常難。因為這條鏈路上有太多環節。業界的做法是建立「baseline 標籤」：每一次重要的凍結點（例如 RTL freeze、netlist freeze、GDS freeze、tapeout），就對整個專案的所有子專案打一個統一標籤。這個標籤會記錄：
每個子模組的版本號。
使用的 PDK 與 IP 版本清單。
合成、布局、驗證所用的工具版本。
簽核報告的存放位置與通過狀態。
誰在什麼時間核准了這個 baseline。
有了 baseline，三個月後要重建同一份 GDS 才有可能。否則你就會陷入「我們知道大概是三月的版本，但具體是哪一天、哪個分支、哪個 IP 版本，沒人記得」的困境。這種困境在半導體業不是玩笑，而是會導致專案延誤數週的真實風險。
3.4 檔案的「身分證」：Metadata 與 Manifest
在晶片業，檔案的版本控制往往不只是管「檔案內容」，還要管「檔案之間的關係」。這就需要 metadata。例如：
這個 RTL 檔案依賴哪一個套件（package）？
這個布局資料庫是從哪一個 netlist 產生的？
這份時序報告對應的是哪一個 corner、哪一個版本？
這個 IP 被哪些專案使用？升級後會不會影響其他專案？
這些關係圖如果沒有工具支援，很快就會變成財務 Excel 表格與口耳相傳。這也是為什麼大型公司會投入資源建立內部的 IP 管理系統，甚至把「版本依賴關係」當成一等公民來管理。
四、版本號怎麼編？從 Pre-silicon 到 A0、B0 的命名學
理解了工具與概念，我們來看看實務上版本號是怎麼編的。這部分沒有全球統一標準，但業界有一些常見慣例。
4.1 矽前版本：RTL Freeze、Netlist Freeze、GDS Freeze
在晶片還沒做出來之前，版本節點通常圍繞著幾個「凍結」事件：
Spec Freeze：規格不再變動（理論上）。
RTL Freeze：RTL 功能完成，進入大規模驗證與合成。
Netlist Freeze：網表定版，開始實體設計。
GDS Freeze：布局定版，開始最後的簽核。
Tapeout：交付光罩資料。
對應的版本號可能是 v0.5、v0.9、v1.0-rc1、v1.0，或是業界常見的 r0p1、r1p0 這種「revision + patch」格式。有些團隊會在版本號後面加日期，例如 soc_top_r1p0_20250315，方便對照時程。
4.2 矽後版本：A0、A1、B0 與 Stepping
晶片做出來之後，版本號通常會換一套命名方式，以區分「這是第幾次投片的矽」。常見格式是：
B0：比較大的改版，可能動到元件層或架構。
另一個常見用語是 stepping，原意是步進，指的是晶片製程或設計的階段版本。例如 Intel 早期常用「stepping」來標示處理器的修訂版。在文件上你可能會看到「B2 stepping」，意思是 B 系列的第二個修訂。
4.3 版本號與商業命名的對應
有趣的是，工程內部的版本號和消費者看到的產品名稱，通常是兩套系統。例如：
工程版：SoC-X r2p3，tapeout 於 2024 年 11 月，B0 stepping。
商業版：某某處理器 9600X，韌體版本 1.2.3。
行銷部門不會告訴你「這顆是 B0 stepping、有兩個 ECO、其中一個是 metal fix」，但工程部門必須清楚記錄，因為售後服務、韌體更新、甚至未來的 errata 公告，都要靠這套內部版本號來對應。這也是為什麼有時候同一款產品會有「某些序號的機型有 bug、某些沒有」，背後就是不同 stepping 的差異。
五、為什麼工程師要這麼龜毛：版本失控的真實代價
看到這裡，你可能會想：「好吧，版本很多我理解了，但有需要這麼嚴格嗎？」答案是：需要，因為版本失控的代價，在晶片業是以「百萬美元」和「數月延誤」為單位計算的。
5.1 光罩與重投片的錢
一顆晶片從設計到量產，最貴的單一項目之一就是光罩。光罩的價格隨製程節點急速上升：成熟製程可能是數十萬到百萬美元等級，先進製程（5nm、3nm）則可能達到數百萬甚至上千萬美元。這還不含晶圓本身的成本、封裝成本、測試成本。
更痛的是時間。一次 full mask respin 的週期可能是三到六個月，這段時間產品無法上市、客戶無法出貨、競爭對手可能已經搶先。所以業界有一句話：「能用 ECO 解決的，就不要 respin；能在 RTL 解決的，就不要留到 ECO。」而要做到這件事，靠的就是嚴格的版本控制與可追溯性。
5.2 可重現性：三個月後還能重建同一顆晶片嗎？
可重現性（reproducibility）是版本控制最核心的價值。它的定義是：給定一個版本標籤，任何人在任何時間，都能重建出完全相同的設計結果。
這件事在半導體業特別難，因為：
工具版本會更新，同一份 RTL 合成的結果可能不同。
PDK 會更新，DRC 規則可能變嚴或變鬆。
IP 會更新，某個模組的介面可能微調。
腳本會更新，某個約束條件的寫法可能改變。
所以嚴謹的團隊會把「工具版本、PDK 版本、IP 版本、腳本版本」全部納入 baseline。聽起來很囉嗦，但當你需要在半年後回過頭調查一個客戶問題，或是在量產階段發現某一批晶圓良率異常時，這份紀錄就是唯一的救命繩。
5.3 常見的版本災難場景
以下是業界流傳（或親身經歷）的幾種典型災難：
這些場景聽起來很低級，但在數百人、數千個檔案、數十個子系統同時運作的專案裡，發生的機率比你想像的高。版本控制的所有紀律——強制 check-in、baseline 標籤、code review、簽核流程——都是為了防止這些「低級但致命」的錯誤。
六、給讀者與新手的實務建議
如果你正在學習晶片設計，或是有機會進入 IC 設計公司，以下是幾個可以馬上派上用場的觀念與習慣。
6.1 五個可以馬上用的習慣
6.2 延伸學習路線
如果你想更深入理解晶片設計的版本控制與流程，可以從以下方向著手：
七、結語：版本號不是負擔，而是晶片工程的記憶體
回到最初的問題：為什麼一顆晶片有上百個 revision？因為晶片是一個「修改成本極高、協作規模極大、抽象層次極多」的產品。上百個 revision 不是混亂的象徵，而是工程團隊在層層限制下，盡可能把每一次修改記錄下來、把每一個決策保存下來的結果。
對軟體開發者來說，這套流程可能顯得笨重；但對晶片工程師來說，每一個版本標籤都代表一次「我們知道自己在做什麼」的確認。當一顆晶片在十八個月後從晶圓廠回來、在實驗室裡第一次點亮，所有那些看似繁瑣的 baseline、tag、manifest，都會在這一刻證明它們的價值。
下次你看到一顆處理器或一顆 SoC，不妨想想它背後那上百個 revision：那些數字不只是版本號，而是一整個團隊在時間軸上留下的足跡。理解了這一點，你也就理解了晶片設計這門工程，為什麼既浪漫又務實。