可驗證的 IC 設計狀態：AI 如何跨越抽象層並保留證據

Scott Yo-Ru Chen · AI-assisted 發布於 2026 年 9 月 23 日 06:05

AI 參與 IC 設計的可靠性，取決於每個修改能否對應到清楚的設計狀態與驗收證據。一次 WNS 改善，只有在 RTL、SDC、library、corner 與分析條件可比較時才有意義；一次工具呼叫成功，也不代表產出的成果可以被下一階段信任。

完整晶片流程會把同一份意圖逐步轉成架構、RTL、netlist 與實體資料庫，每個表示保留不同資訊，也開放不同的修改空間。人類工程師原本負責跨層判讀：哪些 constraints 不可改、哪份 checkpoint 對應目前版本、哪些 report 已失效。當 agent 開始跨階段探索，這些判讀需要轉成平台可驗證的資料關係。

UCLA 的 AHRR 研究提供抽象層如何影響探索的證據；bazel-orfs 的成果狀態討論則提供版本與品質如何進入相依關係的線索。兩者不能合併成某個既有公司的完整平台，但能支持一個值得驗證的設計方向：讓 agent 在適當表示上探索，並由獨立證據決定成果能否晉級。

沿圖由上而下看，同一份設計意圖逐步變成 RTL、netlist 與實體成果，每一層都帶著不同的約束。這是作者提出的參考分層：要觀察的是改動跨層後，哪些相依證據需要重建，而非把每個方塊當成必須採購的產品。

AI-native IC design platform multi-level state stack

圖 1：作者提出的狀態分層設計；機制參考：UCLA AHRR、Synopsys autonomous engineering。

從 command sequence 到 state transition：IC design 的操作模型

今天大多數 EDA automation 看起來仍像這樣：

run_genus.tcl
→ run_innovus.tcl
→ run_pt.tcl
→ parse_report.py
→ engineer decides what to change
→ rerun

這種方式對人類工程師有效，因為 state model 藏在工程師腦中。工程師知道哪一版 RTL 對應哪一組 SDC，知道某次 WNS 改善是否是因為 path group 被改壞，知道 floorplan 變動後哪些 downstream result 已經失效，也知道一份 report 雖然 job exit code 是 0，但其實結果不能用。

Agent 不具備這種隱含背景。如果平台只把 shell、Tcl、log、report 丟給模型，它就必須同時推理三件本來應由平台負責的事：目前的 design state 究竟是什麼、下一步允許修改什麼、什麼證據足以宣告成功。

所以「增加 tool API」不等於「得到自主 IC design」。API 只解決 action surface；它沒有解決 state semantics。

完整的 design state 至少有五層。

第一層是 intent：功能目標、PPA、power budget、可靠度、schedule、允許變更的邊界與 acceptance criteria。

第二層是 architecture / behavioral representation：hierarchy、protocol、dataflow、algorithmic structure，以及 HLS、DSL 或 domain-specific compiler 能表達的設計知識。

第三層是 RTL 與 constraints：Verilog/SystemVerilog、SDC、UPF、DFT intent、formal assumptions。這裡已經不是單純「code」，因為 constraints 本身會改變 EDA 對設計的語意理解。

第四層是 implementation state：netlist、floorplan、placement、CTS、route、RC、timing graph、physical database。

第五層則是 evidence：STA、SI、IR/EM、DRC、LVS、LEC、coverage，以及每一個 waiver 的 provenance。

一個 AI system 若只看其中一層，就很容易做出局部正確、系統錯誤的決策。

為什麼 abstraction layer 會直接改變 Agent 能力

Zijian Ding 的 AHRR 結果裡，比 2.62× 這個數字更有參考價值的是 case study：HLS abstraction 把大量 hardware design knowledge 壓縮進 compiler semantics。論文中的 ROB1 case，agent 在 HLS 只需要用少量 pragma 表達 256-way parallelism，Vitis HLS 再把 intent 展開成大規模 RTL；同一 agent 直接寫 RTL 時只做出較窄的平行結構。abstraction 除了拿掉低階自由度，也把大量已知工程模式變成模型可以利用的「結構化先驗」。來源

但這不代表平台應該全部升到 HLS。論文也顯示小型 kernel 上 direct RTL 可以勝過 HLS；而 Post-HLS RTL Refinement 又能在部分案例繼續回收低階最佳化空間。比較合理的結構是建立 multi-level design state，而非選定唯一 abstraction：

Intent
  ↓
Architecture / Behavioral IR
  ↓
HLS / DSL / generated RTL
  ↓
RTL + Constraints
  ↓
Netlist / Physical DB
  ↓
Signoff Evidence

Agent 應該在「最高但仍足以控制結果」的 abstraction 上修改；只有當 verifier 顯示問題出在低階 realization，才往下 refinement。

這與 compiler 的最佳化原理很接近：高階 IR 保留 semantic information，低階 IR 暴露 target-specific optimization。IC design agent 若永遠直接從 Tcl、Verilog 或 tool console 開始，相當於把所有工程問題都降成 machine-level patch，再要求模型自己重建上層意圖。

Memory 之外：可持久化的 engineering state

Agent system 很容易把「memory」當成核心能力：把過去 trajectory 存起來、把 senior engineer 的操作做 RAG、把之前的 error/fix pair 放進 knowledge base。這些都重要，但它們不是 authoritative state。

一個 flow 能被依賴的 state，必須具備四個性質：

Typed：平台知道它是 RTL、SDC、ODB、timing result、coverage result，還是 waiver，而不是只看到一個檔名。
Versioned：每個 artifact 能回溯到 parent state、tool version、參數與輸入。
Validated：平台知道這份結果通過哪些 checker，也知道哪些 checker 尚未通過。
Replayable：換一個 worker 或乾淨環境，仍能重新建立並驗證同一個狀態。

bazel-orfs 今天那個 degraded marker 的討論正好落在這個問題上。假設 place stage 在某個低成本探索模式下仍留下 unrouted nets，但為了讓 downstream route/signoff 繼續暴露其他問題，平台選擇讓 stage 產出 artifact 而不是立即 fail。如果 degraded 只寫在 log，下一層就可能把它當成正常 checkpoint；如果 degraded 狀態本身進 artifact metadata 與 hash，那麼 cache identity、lineage 與 downstream action key 都會跟著分流。

Typed artifact state and cache semantics

圖 2：將 quality state 放入 artifact identity，可讓 clean / degraded result 在 cache 與 downstream dependency 上天然分離。概念整理自 bazel-orfs 2026-09-22 design discussion。

這個概念如果擴大到商用 IC design platform，我會希望每一個重要 artifact 至少帶有：

Artifact {
  type
  payload
  parent_artifacts[]
  tool + version
  parameters
  environment
  quality_state
  validators[]
  metrics
  owner / policy domain
  timestamp / provenance
}

這樣 Agent 才能問出工程上有意義的問題：

「這份 post-CTS checkpoint 是不是由目前這版 SDC 產生？」

「這個 WNS improvement 是從哪一個 parent state 分支出來？」

「這份 route result 是否帶著 upstream floorplan degraded marker？」

「這個 result 通過的是 quick checker，還是 production signoff checker？」

這些問題比「某個 log 裡有沒有 ERROR」重要得多。

Autonomy 的可靠性邊界：Agent 可以決策，但不能自行定義成功

Siemens EDA 在今年 DAC 後公開的 long-running agent 架構把 physics-based deterministic EDA engines 放在 ground-truth layer，agent 的決策持續被工具結果驗證，而不是只在 workflow 結尾做一次檢查。Siemens 同時把 orchestration、self-verification、governance/security、reasoning model 與 accelerated compute 分成不同層。來源：Siemens EDA

這個方向與 Synopsys 的 goal-directed autonomous engineering 相容：Agent 負責把 workflow 往 objective 推進，但「是否真的達到 objective」應由外部 evidence 決定，而不是由 agent 的自然語言結論決定。

Verifier-backed closed loop

圖 3：可信任的 autonomous design loop。整理自 Synopsys autonomous engineering、Siemens self-verifying EDA agents，以及現有 EDA signoff practice。

如果把這個邊界畫清楚，整個系統可以容許模型犯錯。Agent 可以提出錯誤 hypothesis、試錯誤 parameter、甚至產生無效 patch，只要錯誤被隔離在 candidate branch，而且 candidate 不能在沒有 evidence 的情況下升級成 trusted state。

因此設計目標是讓錯誤嘗試便宜、隔離、可回復，且不污染正式 design state；每一次 reasoning 都正確並非前提。

Failure mode：平台無法判斷哪裡開始不可信

AI-native IC platform 我最擔心的 failure mode 有四種。

第一，state ambiguity。同一個檔名或 workspace 裡混入不同版本 artifact，agent 以為自己在分析 current state，實際上拿到 stale report。

第二，constraint drift。RTL 沒變，但 SDC、UPF、library、RC corner 或 tool setting 變了；平台若只追 code diff，會把不可比較的 QoR 當成可比較。

第三，false completion。command 執行成功、job exit 0、agent 說「fixed」，但 clean replay 的 STA、formal、LEC 或 regression 並沒有通過。近期 SecTB-RTL 甚至展示了 provider schema acceptance 與 production semantic validity 可以嚴重脫節：1,860 次呼叫中有 1,857 次被 provider 接受，卻只有 9 次通過 production semantic validator。這個實驗顯示 schema/tool-call success 不能替代工程語意驗證，與某個模型好或壞無關。來源：Hang Xiao, SecTB-RTL

第四，hidden degradation。為了探索或縮短 turnaround time，平台允許某些 stage 用 approximate / fast / partial mode，但 quality state 沒有進入 lineage，導致後續結果看起來「完成」卻建立在不相容的前提上。

這四種問題屬於 state model、dependency model 與 validation contract，換更大的 LLM 解決不了。

對 IC Design Platform 架構的含義

如果上述判斷成立，我會把 AI-native IC design platform 拆成五個長期穩定層，而不是綁在某一個模型或 agent framework 上。

第一層：Design State / IR Plane

保存 intent、hierarchy、RTL、constraints、physical state、signoff evidence 與 lineage。這是最重要的 system of record。

第二層：Compiler / Lowering Plane

負責 abstraction 之間的 lowering 與 canonicalization，例如 architecture → HLS/RTL、RTL → netlist、logical constraint → tool-specific Tcl。Agent 不應自己重新發明所有 lowering semantics。

第三層：Execution Plane

承載 Genus、Fusion Compiler、Innovus、ICC2、PrimeTime、Calibre、formal/simulation 等實際工作，底下可以是 LSF、Kubernetes、grid scheduler 或 cloud。scheduler 可以替換，但 execution contract 不能漂移。

第四層：Evidence Plane

由 deterministic checker 產生可以機器判讀的 engineering evidence。它決定 state transition，而不是 LLM。

第五層：Agent / Optimization Plane

在前四層之上做 hypothesis、planning、DSE、debug、root-cause analysis、skill reuse 與跨 flow coordination。模型與 harness 都應該是 replaceable component。

這種分層的效果是：未來無論使用 Claude、GPT、Gemini、GLM 或公司內部模型，累積下來的資產會是 design state、artifact lineage、validator、decision trajectory 與 reusable methodology，prompt 反而不是。

Trade-off：狀態越完整，平台成本越高

這套架構不是免費的。

把每個 artifact 都做完整 provenance，會增加 metadata、storage 與 schema governance 成本；checkpoint 太細，cache footprint 會爆炸；validator 太多，agent 每一步的 latency 會上升；abstraction 太高，可能犧牲低階 QoR；abstraction 太低，又會把 agent 拉回 Tcl/RTL micro-management。

因此平台不應追求「所有東西都 typed、所有 substep 都 checkpoint」。比較合理的是把 state boundary 放在三種位置：

會影響大量 downstream work 的 expensive boundary；
需要 human/agent decision 的 semantic boundary；
能提供 deterministic acceptance evidence 的 trust boundary。

例如 synthesis netlist、floorplan、post-place、post-CTS、route、signoff 是自然候選；但某些 tool 內部的幾十個 optimization substep 未必需要全部升格成 platform-level artifact。

未來 6–18 個月，我會優先做的三件事

第一，建立最小可用的 Typed Artifact Contract。先不要企圖建完整 design database，選 synthesis、APR、STA 三個 flow，定義 artifact type、parent、tool/version、parameters、quality state、metrics、validators。

第二，建立 cross-layer invalidation。修改 RTL、SDC、UPF、library、floorplan parameter 時，平台必須知道哪些 downstream result 已經失效，而不是靠 engineer 判斷要重跑哪一段。bazel-orfs 對 stage-level content hash 與 incremental rebuild 的實作值得直接研究。來源：bazel-orfs

第三，讓 Agent 在不同 abstraction 上工作，而不是只做 Tcl automation。可以選一個具體 design task，比較：

A. raw Tcl / report loop
B. semantic tool API
C. typed state + semantic transformation
D. higher-level intent / IR + lowering + verifier

量測除了成功率，還要看工程師介入次數、無效 rerun、token / compute cost、QoR、可重播性與跨 design generalization。

「AI 可以操作 EDA tool」只是 automation surface，還不是值得追求的終局。

更有價值的終局是：工程師定義設計目標與不可違反的邊界，平台把設計表示成可理解、可追溯、可驗證的多層狀態；Agent 在適當的 abstraction 上探索；compiler 與 EDA engines 做 lowering 和 realization；deterministic evidence 決定哪一個結果可以被下一階段信任。

到了那一步，AI 會從掛在 IC design flow 旁邊的 assistant，進入 design platform 本身的 execution semantics。