把「寫出設計」與「拿到晶片」分開：從 Verilog 模擬到實體運作要跨過四層驗證
你打開一個叫 tiny-gpu 的專案，裡面有 Verilog 設計、矩陣運算範例與模擬軌跡。README 將它定位為學習 GPU 底層原理的最小實作。看到這裡，很容易想到一個問題：看懂這份設計、甚至動手改一改，離拿到一顆能運作的晶片還有多遠？
要回答這個問題，得把「寫出一份設計」和「拿到一顆會動的晶片」分開看。這篇逐層區分設計與模擬、實體佈局與檢查、提交製造，以及製造後的實測，避免把前一步的成果直接當成下一步的完成。
Adam Majmudar 的 tiny-gpu 提供了一個學習起點：從可閱讀的設計與模擬範例切入，理解 GPU 的底層原理。
這篇文章用三組公開資源，拆解個人可以參與哪些環節，以及每一層成果需要怎樣的驗證。
最小設計讓 GPU 原理可跑模擬驗證，但受限於面積與接腳、實際送交流片的是較小 ALU
tiny-gpu 的 README 用矩陣運算範例示範這份設計能做什麼，也附上模擬說明與訊號軌跡。閱讀時，可以把設計與模擬結果放在一起對照，檢查自己的理解。
這一步的價值在於能動手驗證。讀程式碼、跑模擬、看訊號軌跡是否符合預期；看不懂的地方，試著修改設計再重跑模擬。把推論放進可檢查的結果裡，比停在「好像懂了」更適合作為學習目標。
README 在模擬段落放了一段執行軌跡範例，作者用它說明：跑完 kernel 模擬後，每個時脈週期裡每個核心、每條執行緒的狀態都看得到。
tiny-gpu 的 README 將 Tiny Tapeout 轉接列在後續工作（Next Steps）；另一個專案 adam-maj/tt06 的說明則記錄，GPU 在面積與接腳整合上有困難，因此作者另做了較小的 ALU（算術邏輯單元）提交。這兩份成果必須分開看：一份是 GPU 的公開設計與模擬，另一份是 ALU 的製造提交。從送交製造再往拿回晶片與實測前進，每一步都要有各自的證據。
一份能讀懂、能修改、能跑模擬驗證的設計，已經值得作為學習起點。若目標是拿到能運作的晶片，還要往後看工具、製程資料與製造安排。
開源工具鏈推進實體佈局與共乘流片：OpenLane 轉入維護、SKY130 仍屬實驗性預覽
寫出一份能模擬的設計之後，下一層工作是把它變成能製造的實體佈局，再送出去生產。這兩步各自需要不同的資源：一套能把設計自動轉成實體佈局的工具，和一份描述特定製程規則的資料。開源社群在這兩層都留下了可以參考的案例，但各自解決的只是其中一部分。
OpenLane 提供自動化實體設計流程。截至 2026-10-20，官方 README 已將專案標為維護模式，只收關鍵修正，不建議用在新設計上，並指向 LibreLane。閱讀這類流程有助於理解設計如何往實體佈局前進；選擇新設計要用的工具時，則應一併考慮維護狀態。
SKY130 提供另一層資源：SkyWater 開放的製程設計套件（PDK），讓設計者取得特定製程的規則資料。官方文件將開源版本定位為實驗性預覽版；評估這份資料的適用性時，應把開源版本的限制與商用製程本身的成熟度分開看。
往製造前進，Tiny Tapeout 提供共乘流片的參與方式。提交設計須符合設計空間、介面與送件條件，價格與限制依方案而定。評估要不要參與時，應逐項確認這些要求，以及設計還有哪些檢查要完成。
- 可閱讀的 Verilog 設計、矩陣運算範例與模擬軌跡
- 模擬涵蓋哪些測試情境；完整 GPU 轉接 Tiny Tapeout 列在後續工作
- 自動化實體設計流程；SkyWater 開放的製程設計套件（PDK）
- 截至 2026-10-20，OpenLane 為維護模式、新設計官方指向 LibreLane；SKY130 開源版本為實驗性預覽版
- 共乘流片的參與方式
- 設計空間、介面與送件條件；價格與限制依方案而定；拿回晶片後另行實測
三組開源資源分別降低了不同階段的門檻，但 OpenLane 進入維護、SKY130 屬實驗預覽，流片成果仍須在下一層獨立確認（Sunny DataScience 整理）。
把這三組資源放在一起看，我的判斷是：開源工具與開放資料確實擴大了個人能接觸的設計環節，但它們各自處理不同層的工作，每一層都需要獨立確認結果。
設計走到哪一步就用哪一步的證據說話：功能模擬通過不能頂替實體晶片驗收
三組資源合起來，支持的是一個比較收斂的判斷：開源專案與工具鏈擴大了個人理解、修改和驗證晶片設計的參與範圍；但每往製造與實體運作前進一步，都要另外有證據，不能由前一步的成果直接代替。
閱讀模擬結果時，先問它涵蓋哪些測試情境、檢查了哪些行為；看到實體佈局或提交紀錄時，也要另外確認對應的檢查與實測。把成果稱為「做出了 GPU」之前，先說清楚指的是哪一層。
驗證必須分層設定通過條件，避免用其中一層的結果頂替另一層。對有軟體背景的讀者，這也可以作為閱讀〈AI Coding 驗證閉環〉的延伸問題：測試通過時，究竟驗證了什麼？
設計能走到哪一步，就用那一步的證據說話。tiny-gpu 適合作為可閱讀、可模擬的學習教材；若要往完整 GPU 的製造與實測前進，應把它們各自設為需要驗收的獨立目標。
結論：想理解硬體底層值得從最小設計跑模擬，但商用交付必須檢驗實體製造與實測
我對這組資源的判斷止於教育與探索：從可讀、可模擬的設計開始，確實值得作為理解硬體的第一步。如果要評估商用 GPU 的競爭力，還應另外比較效能、成本與軟體生態。學習本身的價值，無須靠「產業顛覆」來證明。
對 GPU 與晶片原理有興趣的軟體工程師，可以先讀一份像 tiny-gpu 這樣的最小設計，跑一次模擬，看看訊號軌跡和預期是否一致。如果目標是理解硬體怎麼運作，這一步值得投入。如果目標是做出可交付的加速器或商用替代品，投入判準就應包含設計、製造與實測各層的驗收。
這篇想留給你的，是下一次看到類似標題時，可以自己問自己的一個問題：這份成果，現在站在設計、驗證、還是製造那一層？答案會決定它值不值得你投入，也會決定你該期待看到哪一種證據。
延伸閱讀
參考資料
- Adam Majmudar. tiny-gpu（GitHub README，2026-10-20 檢視）.
- Adam Majmudar. adam-maj/tt06 — docs/info.md（2026-10-20 檢視）.
- OpenLane 官方 README（2026-10-20 檢視；已標示維護模式，不建議新設計使用，並指向 LibreLane）.
- SkyWater Technology. SKY130 PDK Documentation（官方文件，2026-10-20 檢視）.
- Tiny Tapeout. 官方網站、FAQ（2026-10-20 檢視）.
留言0
登入後就能留言。
登入