VLSI Korea向ChatGPT詢問會答錯的EDA實務問題：VCS -mfcu、Vivado hold診斷、工具版本混用應對的確認順序
有些EDA實務問題向ChatGPT詢問會答錯。彙整以公開文件為基準確認VCS -mfcu、Vivado繞線中hold診斷、工具版本混用應對的順序。
🆓 免費文章 · 任何人都可以免費閱讀
核心結論 生成式AI在EDA工具問題上，不是錯在語法，而是錯在邊界條件。它會誤述的不是選項的存在，而是該選項改變的compilation unit範圍、工具內部階段的公開與否、版本組合的重現條件。Vivado的route_design內部phase沒有可在中間停止的公開Tcl API，hold問題不是停止繞線來看，而是以無hold fix的方式繞線來比較診斷。無法斷定的錯誤，答案不是背誦，而是固定確認順序。本文三個案例都整理為「不直接執行AI回答，而是要以什麼順序確認什麼」。
為何AI在EDA問題上特別常出錯
一般程式設計問題與EDA問題的錯誤性格不同。在程式設計中，公開文件與範例多，錯誤的答案執行後也多會立刻以錯誤顯現。在EDA中情況相反。工具文件有相當部分在安裝後提供的手冊與release note中，同一命令依版本、授權、裝置家族而動作不同。而且錯誤的腳本也可能無錯誤地運行，只有timing結果悄悄不同，這種情況也不少。
AI製造的典型錯誤有三種：將不存在的選項組合得像存在一樣、顛倒存在選項的預設值與適用範圍、將只在特定版本成立的繞行方法說成適用所有版本的正規方法。以下三個案例是在實務中反覆遇到的代表性模式。每個案例都一併寫下AI常做的回答、錯在哪裡，以及現場使用的確認順序。
案例1 — VCS -mfcu：「將多個檔案合為一個的選項」這個回答的陷阱
向AI詢問VCS的-mfcu，多會得到「一次編譯多個檔案的選項」程度的回答。這句話不算錯，但錯過了實務所需的核心。-mfcu是multi-file compilation unit，即宣告將命令列上列出的多個檔案視為一個compilation unit。相反概念是將每個檔案視為個別compilation unit的方式。
Compilation unit重要的原因是SystemVerilog的可見性規則。IEEE 1800將compilation unit定義為「一起編譯的原始檔案集合」，精確的區分方式交由工具決定。在一個unit內，順序具有意義。前面檔案中定義的define巨集會影響後面檔案，在compilation-unit scope中宣告的項目會在unit內後面的檔案中可見。反之，若unit依檔案分離，巨集不會跨越檔案，每個檔案必須明確import需要的套件，或include需要的檔案。
實務事故就在這裡發生。某些legacy環境依賴檔案順序運作。以共通巨集檔案在清單最前面為前提，後面檔案直接使用define。若將這個環境改為unit分離方式，過去隱藏的依賴性會一次以錯誤爆發。反之，在以-mfcu綁定的環境中，一個檔案的巨集污染會擴散到整體。即使同名的define在每個檔案以不同值重新定義，也會依順序悄悄被覆蓋。typedef也是如此。依賴Compilation-unit scope宣告的程式碼，在unit邊界改變的瞬間就會損壞，移至套件的程式碼即使邊界改變也能存活。
| 區分 | -mfcu（一個unit） | 依檔案的unit |
|---|---|---|
define傳播 |
依清單順序傳播到後面檔案 | 不跨越檔案，需要include |
| Unit scope宣告 | 在unit內後面檔案可見 | 只在檔案內有效 |
| 檔案順序依賴性 | 強，順序改變動作 | 弱，以明確import為中心 |
| 常見事故 | 巨集重新定義、污染傳播 | 隱藏依賴性暴露、大量錯誤 |
| 建議方向 | 只在維持legacy時謹慎使用 | 新程式碼以package明確化 |
確認順序如下。第一，先確認目前build以哪種模式運行，從旗標與檔案清單開始。第二，區分出錯的識別符是define、typedef，還是套件項目。第三，找到該宣告在哪個檔案的哪個scope中。第四，修正時，在翻轉全域旗標之前，先檢討讓問題檔案以明確的include與import宣告自身依賴性的方向。依工具與版本，相關選項的精確名稱與預設值可能不同，因此最終確認以使用中版本的User Guide中compilation unit項目為準。不直接相信AI所說的預設值，是這個案例的結論。
案例2 — Vivado：「在route中間停下來看hold path」的回答為何不可能
第二個常出錯的問題是這個。「在Routing途中修正hold的階段停下來，確認該時點的hold path，該怎麼做？」AI常捏造看似合理的Tcl命令組合或內部階段名稱。然而route_design是以一個命令執行的實現階段，理解為沒有提供指定其內部phase來停止的公開Tcl API，較為安全。在階段前後掛Tcl hook與停止階段內部是不同的事。前者可能，後者不是公開介面。
知道這個限制，診斷法才能正確確立。AMD文件UG906提出的正規方法不是停止的方法，而是比較的方法。Router有先於setup修正hold的傾向。因為hold違規即使降低頻率也無法解決，但setup違規可以。問題在於過度的hold修正製造routing detour，破壞setup的情況。此時的診斷流程如下。
第一，先在post-place狀態看hold違規的大小。超過數百ps的異常大違規，大多是設計或約束的問題，代表性的是在set_multicycle_path中漏掉-hold的情況，或是懷疑過度clock skew的訊號。第二，以另外的實驗停用hold檢查並繞線。UG906的Method 1所引導的方式，是以set_false_path -hold形式的約束關閉hold check後執行route_design，再將report_timing_summary的WNS與原始結果比較。這個約束僅供診斷，絕對不能原樣留在量產設計中。第三，若差異大，判斷hold fix正在損害setup，並在個別路徑上以report_design_analysis的hold fix detour資訊或針對worst setup path的hold報告縮小原因。
📩 在持續關注這個主題嗎？
財報·報告·HBM供需的後續分析，每天10:30（KST）寄到您的信箱。 免費訂閱 →
Pblock濫用也要在這一點一併指出。為了快速壓下Hold或congestion問題而將區域抓得過窄，或將無關模組也綁在一個區域，會降低router的自由度，detour與congestion反而增加，其他路徑的timing連鎖崩潰。Pblock是傳達佈局意圖的工具，不是timing修正的萬能鑰匙。決定大小與包含範圍時，必須有floorplan觀點的依據，適用後必須一併看目標路徑之外的整體WNS、WHS與congestion指標。
| AI常做的回答 | 實際狀態 | 正確的診斷行動 |
|---|---|---|
| 提出在內部phase停止的Tcl | 無公開API | 以階段單位hook與事後報告替代 |
| 要看Hold就中斷繞線 | 本身無中斷點 | 無hold fix繞線並比較WNS |
| 將Pblock抓窄強制佈局 | 可能惡化Detour、congestion | 建立範圍依據並確認整體指標 |
| Multicycle只指定setup | 漏掉-hold引發大型hold違規 | 以約束對重新檢查 |
案例3 — 工具版本混用：想背誦錯誤代碼必定出錯
第三個案例是在synthesis、simulation、STA工具版本互不相同的環境中發生的timing錯誤。將錯誤訊息貼給AI，常得到斷定特定原因的回答。但在版本混用環境中，同一訊息可能來自cell library的timing model差異、SDC語法解讀差異、工具預設值變更、檔案格式的向下相容問題等不同原因。這裡需要的不是斷定，而是確認順序。
將順序固定下來即可。1）製作組合表：將每個階段的工具名稱、精確版本、patch水準、library版本寫成一張表。重要的是寫成檔案，而不是記憶。2）最小化重現：不是整體設計，而是以包含問題路徑與cell的最小單位，確認是否重現相同錯誤。3）單一版本對照：若可能，只將一個階段調整為基準版本重新執行，比較錯誤是否消失。若消失，原因不在邏輯，而在組合。4）輸入等價性確認：以hash與生成時間確認進入兩個環境的netlist、SDC、library是否真的是相同檔案。出乎意料，許多「版本問題」的實體是舊版本產出物的重用。5）Release note對照：以已確認的版本對為基準，尋找已知的timing相關變更與deprecated項目。6）向vendor支援請求時，一併提交上述組合表與最小重現案例。若沒有這個順序只丟訊息，支援方也會重複相同猜測。
預防原則也很明確。用於Signoff的工具組合以專案為單位固定，中間產出物在檔名或標頭留下生成工具與版本，版本升級在整體流程一次驗證後才反映。「只悄悄提升一個階段」是版本混用事故最常見的開始。
將AI回答用於實務前要經過的驗證習慣
三個案例的共同教訓相同。AI的回答作為假設有用，但作為依據不足。若出現選項名稱，就在使用中版本的手冊中直接打開該選項項目，確認預設值與適用範圍。若出現Tcl命令，就在工具的說明中確認該命令與子選項是否真實存在。若出現程序，先在小型設計或副本中執行。而影響signoff的變更，務必將變更前後的報告並排比較。經過這四個步驟，AI就會從危險的自動化變成快速的假設生成器。
依據的限制：工具選項與程序可能依版本而異。本文不斷定特定版本的動作，以公開文件可確認的診斷原則為中心敘述，實際適用時需要對照使用中版本的官方文件。
FAQ
Q1. 開啟-mfcu，編譯會變快嗎？ 本質不是速度，而是compilation unit的邊界設定。即使有附帶的體感差異，選擇基準也應是巨集與宣告的可見性規則。
Q2. Vivado中可以使用階段前後hook，不是嗎？ 在階段前後執行Tcl的hook，與在route_design內部phase停止是不同的。前者是公開的使用法，後者沒有公開API，是本文的要旨。
Q3. 關閉Hold檢查繞線的結果可以直接使用嗎？ 不行。UG906也明示該約束僅供診斷。以比較確認原因後，必須移除約束並以原始流程重新關閉。
Q4. Pblock不用比較好嗎？ 不是。傳達有依據的floorplan意圖時有效。問題在於為了壓下timing問題而無依據地窄化濫用，適用後必須一併確認整體指標。
Q5. 版本混用錯誤，將整個log給AI就會準確嗎？ Log有幫助，但若無組合資訊，斷定仍然危險。當一併呈現版本組合表與最小重現、單一版本對照結果時，診斷才成為診斷。
行動檢查清單
- ☐ 執行工具選項前，在使用版本手冊中確認預設值與適用範圍
- ☐ 將VCS build的compilation unit模式與檔案順序留下文件
- ☐ 制定將共通宣告移至package而非compilation-unit scope的計畫
- ☐ Vivado hold診斷不以中斷，而以無hold fix的比較繞線執行
- ☐ 以檢查清單管理為診斷放入的false path約束是否移除
- ☐ 製作專案的工具、版本、library組合表並固定signoff組合
- ☐ AI提出的命令與程序先在副本與最小案例中驗證
延伸閱讀
📩 今天錯過的分析，明天早上寄到您的信箱
每天10:30（KST）Daily Silicon與財報·機構報告核心解讀搶先送達。訂閱後可選擇韓語/英語/日語新聞通訊，中文深度分析每日在網站更新。
免費訂閱 →
免費 · 無垃圾郵件 · 隨時退訂
