前兩篇談了我們的理念與平台架構。這篇最具體：平台目前在哪些環節幫得上忙。
我們選擇這四個環節，是因為它們有兩個共同點。第一，大量工作是讀文件、寫制式程式碼、跑工具與看報告，這正是 AI 最能分擔的部分。第二，它們都發生在 tape-out 之前，越早改善，省下的重工越多。
架構探索
痛點： 架構決策的影響最大，卻常常只靠試算表與經驗判斷。建立一個效能模型要花數週，所以團隊通常只比較兩三個方案就得定案。
平台做什麼： 從規格快速產生 SystemC / TLM 效能模型，在代表性的 workload 上量化運算、記憶體與頻寬的取捨。建模成本降低之後，團隊就能在同樣的時間裡比較更多方案，用數據而不是直覺做決定。
SoC 整合
痛點： 一顆 SoC 要整合數十個內部與第三方 IP。暫存器映射、位址空間、中斷、時脈與重置、匯流排連接，每一項都要和各家 IP 文件逐一對齊。這些細節很容易出錯，而且錯誤常常要到驗證後期才浮現。
平台做什麼： 解析各個 IP 的文件，擷取暫存器與介面資訊，產生 top-level 連接與位址表，並自動比對規格與實作之間的不一致。工程師拿到的是一份待確認的差異清單，而不是從零開始對照文件。
設計驗證（DV）
痛點： 驗證通常佔掉晶片專案一半以上的工時。建立 UVM 環境很花時間，每天的 regression 又會產生大量失敗結果，資深工程師的時間大多耗在分類與追查根因。
平台做什麼： 從規格產生 UVM 環境的骨架，包含 agent、scoreboard 與 coverage。Regression 跑完之後，平台會把失敗自動分群，把同一個 bug 造成的失敗歸在一起，整理對應的 log 與波形線索，並提出可能的根因，再由工程師確認。
Middle-end
Middle-end 指的是 RTL 完成之後、實體設計之前的階段，包含合成、lint、CDC 檢查、時序約束與等價性驗證。
痛點： 這個階段的工具報告又多又長，constraint 的錯誤不容易查。設計每改一次，整套流程就要重跑、重看一次。
平台做什麼： 檢查 constraint 的合理性，整理合成與 CDC 報告的重點，把違規項目分類，並標出需要人工判斷的部分。PPA 結果也會回饋到架構探索，接上前一篇提到的決策迴圈。
四個環節，同一套工作方式
這四個環節的做法是一樣的：AI 負責產生與整理，自動檢查負責把關，工程師負責審查與決定。平台不取代既有的 EDA 工具，而是把工具之間原本靠人工銜接的工作自動化。
導入時，我們通常從其中一個環節開始，在客戶的真實專案上做概念驗證（PoC），確認成效之後，再擴展到其他環節。
這三篇只是簡單的開始。接下來，我們會針對每個環節寫更深入的技術文章。如果你的團隊正在其中某個環節遇到瓶頸，歡迎與我們聊聊。
Arvinsa 技術文章系列
- 我們為什麼創立 Arvinsa
- Arvinsa Chip AI Platform 的架構
- 從架構探索到 Middle-end：AI 加速晶片開發的四個環節（本篇）