Part 1 — 把流程建起來：Phase / Stage / Step，主線 + 類比 + 混合訊號（ATLAS 方法論）

先講「怎麼建」：ATLAS 這套方法

在攤開流程之前，先講我是用什麼方法把它建起來的，不然後面那張很完整的流程表會顯得像憑空冒出來。這套方法叫 ATLAS，骨子裡是兩件事——AI-Native（讓 agent 當前門、主導整條路）跟 Program-First（凡是能寫成程式的，就固化成確定性的程式，而不是靠 AI 臨場判斷）。ATLAS 是領域無關的方法，Vibe-IC 是我把它套在 IC 設計上得到的產品。

ATLAS 是五個階段，剛好拼成 atlas（地圖冊）這個字。注意它有兩個 A——第一個是 AI-Native、第四個是 Automate:

它的精神是：先讓 AI 主導地把整條路跑起來，再一格一格把能確定的東西鎖死。 第四步 Automate 我叫它「棘輪（The Ratchet）」——只進不退，每把一段「靠 AI 判斷」的東西成功寫成確定性程式，它就永久留在程式層，下次不必再賭模型今天心情好不好。而那些真的沒法完全寫死的角落，我不假裝它不存在，而是留一個 AI Skill 兜底（Skill-back)，讓整條路仍然 100% 走得完。這篇要建的流程，就是 ATLAS 走一遍的產物。

流程長什麼樣子：3 個 Phase、5 個 Stage、63 個 step

Vibe-IC 的骨架是三個大相（Phase)，官方的講法是 3 個 Phase · 5 個 Stage · 63 個 step。63 這個數字是這樣湊出來的：數位主線 44 步（step 1–44）、加上跨階段的 D1–D5 與 P0、再加上類比 A1–A9 與混合訊號 M1–M4——5 + 1 + 44 + 9 + 4 = 63。大多數步驟只在該用到的時候才醒過來：純數位設計就自動跳過類比與混合訊號兩條軌。

整條流程的入口只有一個，就是 Phase 1——這也是 AI-Native 的具體樣子：前門不是一張表單，而是一個 agent。 你用自然語言描述設計意圖，agent 從那一刻就當主導者，把它接進來。不管你手上是一疊 datasheet(Path A)，還是只有一句話、甚至只是跟它對話（Path B)，最後都收斂到同一個交接物，才准往下走。沒有「跳過 Phase 1 直接寫 code」這種入口。

Phase 1：把「一句話」變成 L1–L27 分層設計文件

Phase 1 的產出，是一組分層的 L-docs(JSON）。這是整個設計的「universal handoff」——Phase 2 沒有它就不准開工，gate 會硬性要求 generated_docs/L*.json 存在，才准動第一行 RTL。這組文件從最上層的對外意圖，一路細化到可實作的規格，實際集合是 L1–L27(L1–L13 是核心層、L14–L27 是進階選用）。節錄前 13 層：

為什麼拆這麼細？因為子模組的每一根 port 只該在一個地方定義一次——L9 整合規格必須在任何 RTL 之前定好。 這是我踩過坑後學到的第一課：一開始想用多個 agent 平行寫 RTL，結果它們對子模組的 port 命名各寫各的、對不起來。所以現在的原則是「單一 agent 產 RTL、L9 先於 RTL、不准有 stub 空殼模組」。分層不只是為了學習，它是整個系統的地基。

Phase 2:RTL → lint → sim → formal → FPGA

有了 L-docs,Phase 2 把它變成會動的硬體。主幹是 step 1 到 6:

1. Spec-to-RTL——整條路裡唯一「非得靠 AI 不可」的一步（自然語言到 RTL 沒有確定性檢查器）；但它產出的東西，實質是被下游一路驗過的。
2. Lint——RTL 衛生檢查。這裡有個微妙的分寸：gate 只擋真正的合成危害（未驅動的線這類），風格觀察只記錄、不擋——因為第三方目錄 IP 本來就有合法的寫法，硬擋只會擋死。
3. CDC/RDC——時脈域、重置域的跨越檢查。
4. 模擬——用 cocotb + iverilog 跑 testbench，而且覆蓋率是量出來的，不是 AI 自己講「大概 95%」。能量的就真的去量。
5. Formal——用 SymbiYosys 做形式驗證。all_proved 只是一個宣稱，不是證明；所以有一道 evidence-chain gate 會確認真的有可 elaborate 的 .sby、真的有 PASS 的 transcript，才接受。
6. FPGA 早期原型——合成成 .sof 燒進板子，真的在硬體上跑。

Phase 3:synth → STA → DFT → PnR → DRC/LVS → GDS

Phase 3 是後端，也是最長的一段——主幹從 step 7 一路排到 44，涵蓋合成、時序、可測試性、實體設計到簽核。這一段跑在一套 EDA 工具鏈上，每個步驟都有它對應的工具：

順序上有些細節我一開始沒概念、後來才懂：CTS（時脈樹合成）在繞線之前——step 19 是 CTS、step 21 才是 routing，時脈樹要先鋪好，繞線才知道要繞開哪裡。中間還有一個我覺得聰明的 step 18：在 placement 之後、CTS 之前，主動撒一批備用單元（spare cells）並標上 dont_touch，當作未來只改金屬層就能修 bug 的 ECO 預算，而且後面的優化與 metal fill 都不准把它們吃掉，有專門的 gate 一路盯到 GDS。

兩條支線：類比 A1–A9 與混合訊號 M1–M4

純數位設計走上面那條就好。一旦專案裡有類比區塊（存在 analog_block_list.json)，就多兩條軌交錯進來。

類比 A1–A9：從 Phase 1 抽類比規格 → 選拓樸 → 產 SPICE netlist + sizing → 跑 PVT corner 掃描 → 佈局 → 每個 block 先各自做完 DRC/LVS 再合併 → 佈局後重新模擬（性能掉超過 10% 就回頭）→ 打包成 hardmacro(LEF + Liberty + GDS + Verilog)→ 協同模擬 / 硬體驗證。hardmacro 必須在數位 floorplan 之前完成，因為 LEF 抽象要拿去做混合訊號的擺放。

混合訊號 M1–M4：把類比 hardmacro 的 GDS 合進數位頂層並擺位 → 檢查電源域跨越、該插的 level shifter / isolation cell 有沒有插 → AMS 協同模擬 + 介面訊號完整性 → 頂層 PV 做最終簽核。

把整條流程串起來的一個抽象：轉換 + 檢查閘

拆到這裡步驟很多，但我走過一遍之後，提煉出一個對我幫助最大的抽象，它讓整張地圖忽然變得好懂：

每一個 step，本質上都是「一個轉換 + 一個檢查閘」。 轉換有明確的輸入格式與輸出格式；檢查閘負責回答「這一步到底成不成」，而且答案必須是真的。

有了這個抽象，我遇到任何一個沒見過的步驟，都能立刻問三個問題：它吃什麼格式、吐什麼格式、它的「成功」由誰判定？這也接回 ATLAS 的棘輪與 Skill-back：轉換多半交給工具或 AI，而那個檢查閘，只要能寫成確定性程式，我就把它鎖進程式層（棘輪只進不退）；真的寫不死的，才留一個 AI Skill 兜底。

我要誠實補一句，而且只講一次：這張看起來很完整的流程表，不是某個資深架構師坐下來一次規劃好的。它是一格一格「打」出來的——每次我發現某個步驟可以在「沒真的做完」的情況下悄悄放行，我就補上一道檢查閘；每補一道，這張圖就長硬一分。正因為這樣，它才有資格被寫死成一份 canonical flow（正典流程）：整條 Phase 1/2/3 被固定在一份 YAML 裡當唯一真理來源，由一支 flow_compliance_check.py 對每個專案產出 PASS/FAIL 矩陣——沒跑過這道 compliance check 就宣稱 PASS，本身就是違規。

流程建起來、也把「每個 step 都有一道真檢查閘」鎖進地基之後，下一步就是去驗證它——尤其是最前端、也最靠 AI 的那一步：Spec → RTL。下一篇 Part 2，我會講怎麼用大量 benchmark 把這一步磨到全過，以及 Program-First / AI-Backup 這兩條路怎麼互相比對、收斂。