Codasip 驗證總監 Philippe Luc 分享了他對驗證工程師應注意哪些錯誤的看法。

您是否知道在設計復雜的處理器內核時可能會出現 1,000 到 2,000 個錯誤？真的，一千個蟲子？嗯，這就是經驗告訴我們的。并非所有的錯誤都是生來平等的：它們的重要性和后果可能會有很大差異。讓我們來看看 4 類CPU 錯誤，如何找到它們，如果我們沒有找到它們會給用戶帶來什么后果。

類型 1：驗證工程師容易發現的處理器 BUG

“哦，我忘記了分號”。是的，這是一個錯誤。很容易檢測到，通常是您在編譯時直接發現的錯誤。除了睜大眼睛，沒有其他辦法可以避免這些.

“哦，原來規范的一部分沒有實現”。這是另一個容易找到的 CPU 錯誤，您可以通過任何體面的測試平臺找到 - 前提是存在顯式測試。在這種情況下，執行該功能的第一個簡單測試將失敗。您的處理器驗證團隊需要做什么？確保你有詳盡的測試。另一方面，設計團隊需要努力仔細閱讀規范，并在開發過程中遵循規范中的任何更改。

換句話說，簡單的錯誤是通過運行一個測試該功能的測試來發現的。它的（壞）行為是系統性的，而不是時間條件。詳盡的驗證是找到此類 CPU 錯誤的關鍵。代碼覆蓋率會幫助你，但絕對不夠。如果 RTL 中沒有對某個特性進行編碼，那么覆蓋率如何報告它缺失？代碼審查- 手頭有規范 - 絕對有幫助。

類型 2：驗證團隊喜歡找到的極端案例

極端情況下的CPU 錯誤更難找到，需要強大的測試平臺。運行該功能的簡單測試用例正確通過，即使有隨機延遲。很多時候，當異步事件加入聚會時，您會發現這些錯誤。例如，一個中斷恰好在 2 條指令之間以精確的時間到達。或者緩存中的一行在存儲緩沖區想要合并時被驅逐。要解決這些錯誤，您需要一個能夠兼顧指令、參數和延遲的測試平臺，以便執行所有可能的指令和事件交錯。顯然，一個好的檢查者應該發現任何與預期的偏差。

在這種情況下，代碼覆蓋率有幫助嗎？不幸的是沒有。僅僅因為錯誤的情況是已經單獨涵蓋的幾個事件的組合。在這里，條件覆蓋或分支覆蓋可能會有所幫助。但分析起來很痛苦，而且最終很少有好處。

1. 測試臺發現了簡單的錯誤和一些極端情況。2.我們從這些極端案例中學習，以改進測試平臺并擴大驗證范圍。這樣做，我們會發現隱藏的案例變成了極端案例（或簡單的錯誤）。3. 由于Bug“成群結隊”，我們可以根據最后發現的Bug進一步擴大我們的驗證范圍。當我們遇到一個愚蠢的錯誤時，我們知道我們的測試已經足夠遠了。

類型 3：意外發現的隱藏 CPU 錯誤 - 或由客戶發現

隱藏的錯誤是由客戶發現的（這是不好的），或者是偶然發現的（在內部，在發布之前）。在這兩種情況下，這意味著驗證方法無法找到它們。

如果您使用不同的測試臺或環境，您可能會因為刺激不同而找到其他案例。很公平。那么，我們所說的“偶然發現”是什么意思？這是隨機測試平臺方法的限制。

對于隨機刺激，測試平臺通常會生成“相同”的東西。如果你擲骰子得到一個隨機數，那么連續 10 次得到數字 6 的機會很少。準確地說，6000 萬分之一的機會。對于具有 100 條不同指令的RISC-V CPU，（等概率的）隨機指令生成器每 102? 次只有 1 次機會連續生成 10 次相同的指令。只是魔方不同位置數量的兩倍……在 10 級流水線處理器上，使用所有流水線級上存在的相同指令對其進行測試并非不合理。如果你不調整你的隨機約束，祝你好運......

類型 4：現實生活中不會發生的愚蠢錯誤

您可能會過度尋找極端案例和隱藏案例，最終創建的測試太愚蠢了。

在連接調試器的同時在每個周期來回更改字節順序可能永遠不會在消費產品上發生，如果 CPU 錯誤的后果對客戶來說永遠不可見，那么它就不是真正的錯誤。如果您在復制文件時故意拔下 U 盤，而文件已損壞，我認為這不是錯誤。如果某些操作導致 USB 控制器掛起，那么是的，這是一個錯誤。

謹防擴大驗證范圍。當發現愚蠢的案例時，您可能將工程工作投入到錯誤的地方。

您可以應用不同的驗證技術在客戶之前有效地發現 CPU 錯誤。在 Codasip，我們使用多個組件測試平臺、各種隨機測試生成器、隨機刺激器和其他幾種技術來驗證我們的產品。隨著項目的發展，我們開發了這些技術以擁有強大的驗證方法。在我們的博客文章中了解更多信息，其中我們解釋了我們如何不斷改進我們的驗證方法。

審核編輯：符乾江