VLSI KoreaAI 修好的 HLS，「PASS」到底保證了什麼
可執行的測試是自動修復的起點。必須區分測試輸入、結果判定與合成後驗證，才不會把原始碼的成功，誤讀成硬體的成功。
🆓 免費文章 · 任何人都可以免費閱讀
HLS 程式碼修復工具顯示了綠色的 PASS。可以相信這個結果，把加速器設計送往下一個階段嗎？答案取決於產生這個標示的檢查是什麼。它可能只是編譯器接受了程式碼，也可能是在準備好的輸入下，輸出與基準值相同。要說它驗證了合成後的電路，則需要另外的依據。工程師應該收到的成果，是成功標示，以及說明該標示涵蓋範圍的紀錄。
最近登上公開清單的 University of New Hampshire 研究團隊的 HLS 自動修復研究，讓這個問題再次被提出。研究團隊以可執行的判定器，評估了 125 個錯誤案例。評估對象是 C 層級的功能修復，合成後的正確性不在範圍內。以這個區分為出發點，來看看實務團隊還需要補上哪些證據。以下的計算與驗證範例，並非重現論文數值，而是 VLSI Korea 製作的說明用案例。研究原文
| Study scope | Beyond the reported experiment |
|---|---|
| Executable C-level repair checks | Generated-RTL correctness and physical implementation |
原始檔案的正解與晶片的動作之間
高階合成，也就是 High-Level Synthesis，是把以 C 或 C++ 程式碼表現的演算法，轉換為硬體結構的設計方式。由於必須決定把同一個計算配置到哪個運算器、以及何時執行，因此要同時處理軟體執行結果與電路實現的條件。這裡必須先確定，修復工具修的是演算法、合成指示，還是介面。如果對不同對象套用相同的成功標準，即使正解相同，也可能接受了失去所需效能的修復。
本文的實體照片是 Altera 早期的 FPGA——Cyclone EP1C3 的晶粒。中央的邏輯陣列與周邊電路，具體顯示了程式碼最終必須使用物理資源這個事實。這是 2013 年公開的歷史參考照片，並不表示它是這次研究的測試晶片，或目前工具的支援對象。FPGA 以位元流設定可配置的邏輯、配線、記憶體與輸入輸出資源。因此，僅憑在 C 檔案中計算正確的證據，無法說明配置到這些資源上的設計的介面與時序。照片原圖、Altera 的 FPGA 說明
| Evidence | Question answered | Still open |
|---|---|---|
| Compilation | Is this source accepted? | Functional correctness |
| C test | Do observed outputs match? | Untested inputs, RTL behavior |
| RTL co-simulation | Does generated RTL pass these tests? | Physical timing, system behavior |
| Implementation and board test | Does this configured system meet its checks? | Untested operating conditions |
先用文字固定功能需求，檢查範圍就會變得清晰。例如「把輸入陣列的有效元素相加」這句話裡，並沒有包含有效長度是否可以為空、符號與表現範圍是什麼、輸出溢位時如何處理。從實現程式碼反推這些空白，很容易把錯誤的實現當成規格接受。應該把修復前後必須相同的動作，與可以改變的實現選擇分開，並讓判定器獨立確認那些需求。
讀 PASS 時，首先要確認的不是成功率，而是輸入了什麼、又與什麼比較。（VLSI Korea 編輯詮釋）
測試也必須先懂得失敗
自動修復的判定器，也就是 oracle，是把執行結果與正解比較的裝置。複製原始碼的執行結果，與驗證需求並不相同。如果原始碼本身就有錯誤，被複製的基準也可能是錯的。反過來說，如果故意把正確的程式碼弄壞，檢查結果卻一直成功，那麼這項檢查至少無法發現該缺陷。團隊在比較修復模型之前，可以先確認判定器是否能區分正常實現與故意弄壞的實現。
CHStone 是從多種應用中選出的、以 C 為基礎的高階合成基準。其論文摘要說明了它用於定量評估設計工具與想法的目的。若要用這類公開計算核心來做修復評估，必須另外檢視其原始評估目的，與現在需要的錯誤偵測範圍是否一致。對比較設計效能有用的輸入，並不保證能揭露所有功能缺陷。CHStone 論文摘要
來想一個小型累加器。輸入是整數陣列，輸出是有效元素的總和。為了簡化說明，假定長度為空的輸入總和為 0，且以下輸入沒有算術溢位。正常實現會把所有有效元素相加，缺陷實現則漏掉最後一個元素。當輸入為 [1, 2, 3] 時，正常輸出是 6，缺陷輸出是 3。這項檢查能區分該漏加錯誤。但僅憑這一點，不能判定任意修復是否正確。
| Checker sanity test | Expected result | Interpretation |
|---|---|---|
| Trusted sum on [1, 2, 3] | 6, pass | Positive control works |
| Omit last element | 3, fail | This defect is observable |
| Always return 6 | 6, pass | A false repair can still pass |
最後一列是關鍵。永遠回傳 6 的修復能通過單一輸入，卻沒有實現陣列求和。「錯誤能被看見」這個條件，與「錯誤的修復不能通過」這個條件，強度不同。因此，即使注入缺陷的檢查曾經失敗過一次，也不能把這項測試當成完整規格。必須留下在哪個輸入、用什麼差異揭露出來，下一個階段才能找到遺漏的動作。
增加輸入時，要放入能區分正解的差異
比起測試的數量，能區分候選實現的輸入更重要。給累加器加上 [2, 2, 2]，總和又是 6，無法篩掉前面錯誤的常數回傳實現。改放 [1, 2, 4]，期望值是 7，就能立刻區分。空輸入與只有一個元素的輸入，則能揭露迴圈的開始與結束條件。比起隨機改變輸入中的數字，應該要能說明長度、邊界與數值分布，會揭露哪一種失敗。
驗證用輸入最好也與修復器參考的輸入區分開來。如果一邊反覆給它看相同的測試一邊修復，工具可能會朝滿足眼前檢查的方向移動，而不是實現它應該實現的動作。審查者可以另外執行保留的輸入，加入失敗案例時，記錄該輸入驗證的是哪條規則。保留的輸入也是有限的，無法證明完整性，但能擴大發現只針對眼前範例調整的修復的機會。
| Input class | Example here | Intended distinction |
|---|---|---|
| Seed | [1, 2, 3] → 6 | Known missing-element bug |
| Same total | [2, 2, 2] → 6 | Does not reject constant output |
| Changed total | [1, 2, 4] → 7 | Rejects constant output |
| Boundary | [] → 0; [9] → 9 | Empty and single-element handling |
MachSuite 的官方儲存庫 README 中有警告，指出驗證方法的可攜性問題，以及最終輸出檢查未被執行。這個警告不能擴大解釋為所有後續研究的檢查都失敗，因為研究者可能另外建構了判定器。實務上得到的教訓是：不要只憑儲存庫名稱就假設其驗證能力。必須確認使用的版本與 harness、失敗回傳值、實際比較路徑。即使結束代碼是成功，如果比較函數從未被呼叫，就沒有依據把功能檢查記為成功。MachSuite 官方儲存庫
📩 在持續關注這個主題嗎？
財報·報告·HBM供需的後續分析，每天10:30（KST）寄到您的信箱。 免費訂閱 →
即使反覆給出相同答案，正確性仍是另一回事
如果修復結果每次都不同，就值得調查原因。可能是說明不足、無法縮小失敗位置，或是生成過程本身具有多樣性。但是，文字有多種形態這個事實，與功能有多種形態這個事實並不相同。把前面的求和分別用 for 迴圈與 while 迴圈實現，即使程式字串不同，在定義的輸入下也能做相同的計算。反過來說，每次都穩定回傳常數 6 的模型，就是穩定地交出同一個錯誤答案。
因此，修復的多樣性適合用作選擇下一個檢查的線索。找出不同的候選在哪個輸入下分歧，就能強化判定器。如果所有候選都在同一個邊界案例失敗，就先檢查規格或輸入範圍。如果只有一個候選編譯失敗，就先把語法與資料型別問題分開。這類診斷不會斷定模型的整體能力，而是提供在目前設計中減少失敗所需的資訊。
| Repeated outcome | Next question |
|---|---|
| Same patch, tests fail | Is the model repeating one wrong assumption? |
| Different patches, same tested outputs | Which new input distinguishes their behavior? |
| Different patches, different failures | Is the defect localized and the contract explicit? |
| Tests pass consistently | What remains outside these tests? |
修復工具的比較表也要以同樣的原則來讀。嘗試次數與檢查輸入改變時，成功率的意義也會改變。一次命中的比例，與多個候選中至少有一個命中的比例，並不表示選擇成本相同。在生成更多候選的期間，檢查可能變慢，或合成等待可能變長。模型選擇除了要有正確候選存在之外，還需要識別該候選所需的時間，以及它在後續階段被淘汰的原因。
把在 C 通過的修復，移到 RTL 與時間軸上
AMD 的 Vitis HLS 文件說明了在 C/RTL co-simulation 中，以 C 測試平台產生輸入、模擬生成的 RTL，再以測試平台檢查該輸出的流程。測試平台必須自行判定結果。這個程序把檢查範圍擴展到合成後的電路，但如果檢查的輸入與比較條件不完善，那些限制也會一起跟著過去。AMD UG1399
在實務上，必須把功能比較與時間條件一起寫下來。例如，即使結果相同，如果接受新輸入的間隔變長，就可能無法滿足串流處理的吞吐需求。Latency 是一個工作從開始到完成所需的時間，Initiation Interval 則是可以開始連續工作的間隔。以下是一個 latency 為 12 cycles、interval 為 3 cycles 的理想範例。4 個工作的開始時間是 0、3、6、9，完成時間是 12、15、18、21。到最後一個完成為止是 21 cycles。
即使 latency 相同，如果工作不重疊執行，就需要總共 48 cycles。這不是實際產品的速度量測，而是固定條件的時間表計算。如果修復器在保留運算結果的同時，改變了資源共享或記憶體存取方式，這類重疊條件也可能改變。因此，除了輸出值檢查之外，還必須確認在允許的輸入速度下是否真的能接收工作，以及結果是否在需要的時間點到達。
| Acceptance layer | Record with the patch |
|---|---|
| Source behavior | Input domain, reference result, compiler configuration |
| Generated RTL | Tool version, interfaces, testbench, observed outputs |
| Timing and resources | Clock target, latency, initiation interval, resource limits |
| System operation | Reset behavior, stalls, backpressure, allowed operating conditions |
當外部介面給出停頓訊號時、當重置在運作中進入時、當長度變化的輸入連續進入時，也都需要契約。這並不是說要給所有設計都加上相同的檢查，而是以該產品合法的運作條件為基準，挑出遺漏的案例。合成報告的目標頻率與實際實現的時序結果也必須區分。把功能與時間條件分開記錄，就能清楚說明修好功能的修補，破壞了吞吐量需求的情況。
要把原始碼的正解轉移到硬體的正解，不只要移轉輸出值，也要一起移轉產生該輸出的條件。（VLSI Korea 編輯詮釋）
韓國設計團隊應該留下的，是成功率的分母
如果韓國的無晶圓廠或 FPGA 加速器團隊要導入自動修復工具，可以在公開核心分數與自家 IP 的適用條件之間，設置一個小型內部評估。這並不是說要把機密設計資料送到外部服務。從核准的環境，以及公開或已取得使用許可的範例開始，確認缺陷種類與輸入條件在多大程度上代表實際工作。把結果分成編譯失敗、功能失敗、合成後失敗、效能條件未滿足，就更容易找到要改善的地方。
例如，10 個候選中，有 2 個在編譯時被淘汰、3 個在 C 檢查、2 個在 RTL 檢查、1 個在時序與資源條件下被淘汰，最終候選就是 2 個。如果只把到達 C 檢查的候選放進分母，就很難知道整體工作的良率。反過來說，如果把所有失敗都歸成一個「AI 答錯」，就無法區分工具設定問題與功能錯誤。必須追蹤相同的起始集合，並記錄每個階段的原因，導入前後的比較才有可能。
| Decision record | Why it matters |
|---|---|
| All attempted candidates | Preserves the denominator |
| Failure stage and reason | Separates configuration from functional defects |
| Human review and tool time | Exposes the cost of finding an acceptable patch |
| Rejected and held-out cases | Prevents easy cases from silently defining the score |
未來 6~12 個月要看的變化，比起更高的單一分數，更重要的是驗證範圍的連結。公開評估是否提供所用的輸入與判定器版本、是否連接到生成的 RTL 檢查、是否記錄到吞吐量與資源條件，這些都很重要。這個提案是否真的有用，可以在內部試驗中反證。如果強化後的檢查幾乎找不到額外缺陷，只大幅增加了審查時間，就必須重新設計輸入的挑選與檢查順序。在隱藏所有階段成本的情況下只增加檢查數量，並不是目標。
自動修復的價值，應該在於它能更快產生人類可以審查的候選，這一點必須被確認。而把該候選接受為產品設計的依據，則是把需求、輸入、判定器、合成電路與實現條件連結起來的紀錄。當 PASS 旁邊有這份紀錄時，團隊就能判斷已經確認了什麼、還要在下一個階段確認什麼。能讓這種判斷成為可能的自動化，才會留在實際設計工作中。
Sources and evidence scope
- HLS repair study, arXiv v1：2026-10-02 提交，於 2026-10-06 的公開清單中確認。正文明示已被 ICCD 2026 接受。接受是作者的標示，並未另外確認會議發表或正式刊登。已閱讀全文，實驗並未重現。由於摘要與表格的數值與分布表述不一致，因此未使用各模型的成功率比較。
- CHStone：確認 2009 年論文摘要與詮釋資料。MachSuite：確認官方 README。兩者是不同的研究資產，與本文執行的累加器範例無關。
- AMD UG1399：2026.1 文件中的 C/RTL 驗證程序。Altera：關於 FPGA 配置方式的企業說明。
- ZeptoBars photo、rights：實際 Cyclone EP1C3 晶粒照片。原圖未經修改。本文中的圖表與判斷基準，以及累加器與時間表範例，均由 VLSI Korea 製作，並非量測到的產品效能。
本稿使用了 AI 的調查與寫作支援。說明用計算與範例已另外確認，並未以重現模型效能或實際硬體實驗的文章形式呈現。
Disclosure
本文僅供資訊參考，不構成任何證券買賣之建議。本文事實係根據所引用的公開論文、技術文件與基準資料，說明用範例與計算由 VLSI Korea 撰寫。來源資料或撰寫過程中可能發生錯誤。作者可能持有本文提及企業之股票。所有投資決策及其結果，均由讀者自行負責。
📩 今天錯過的分析，明天早上寄到您的信箱
每天10:30（KST）Daily Silicon與財報·機構報告核心解讀搶先送達。訂閱後可選擇韓語/英語/日語新聞通訊，中文深度分析每日在網站更新。
免費訂閱 →
免費 · 無垃圾郵件 · 隨時退訂
