作為一個驗證工程師我經常被問到這樣的問題："處理器的驗證什么時候完成？"或者換句話說，"我該如何衡量測試平臺的效率，我如何對驗證的質量建立信心？"。當然這一問題沒有簡單的答案。業界有幾個常用的指標可以參考，如覆蓋率和錯誤曲線。雖然這些指標是絕對必要的，但它們并不足以達到盡可能高的處理器品質。事實上，這些指標并不能真正揭示驗證方法找到最后一個bug的能力。隨著經驗的積累，我了解到檢測處理器漏洞的復雜性是一個很好的指標，并可以在項目的整個開發過程中使用。

是什么定義了處理器漏洞的復雜性以及如何檢測它？

經驗告訴我，我們可以通過計算擊中漏洞所需的獨立事件或條件的數量來定義一個漏洞的復雜性。

那么“事件”又如何定義呢？

讓我們舉一個簡單的例子。當缺少所需的警告時，一個典型的bug會在緩存中發現一個典型的漏洞。此時數據損壞可能發生在以下情況：

A cache line at address @A is Valid and Dirty in the cache.

A load at address @B causes an eviction of line @A.

Another load at address @A starts.

The external write bus is slower than the read, so the load @A completes before the end of the eviction.

External memory returns the previous data because the most recent data from the eviction got lost, causing data corruption.

在這個例子中，我們需要4個事件或條件來擊中這個漏洞。這4個事件給這個bug打了4分，也就是說漏洞的復雜性為4。

對處理器漏洞進行分類？

為了衡量一個漏洞的復雜性，我們可以對漏洞進行分類，供整個處理器驗證團隊來使用。在之前的一篇博文中，我們討論了4種類型的bug，并解釋了我們如何使用這些分類來提高測試平臺和驗證的質量。此時我們可以再進一步，即將這種方法與漏洞的復雜性結合起來處理問題。

一個簡單的漏洞可能需要觸發1到3個事件。那么第一個簡單的測試就會失敗，而一個極端案例可能會需要4個或更多的事件。

回到我們上面的例子，我們有一個復雜性為4的bug，如果四個條件中的任何一個不存在，那么這個bug就不會被擊中。

一個受限的隨機測試平臺需要幾個功能，以便能夠擊中上文例子中的漏洞。地址序列應該足夠聰明，可以重用之前請求的地址，外部總線上的延遲也應該足夠非典型，以便有足夠快/慢的讀寫。

而一個隱藏比較深的案例可能需要更多的事件來觸發。假定一個更微妙的bug與我們的例子有相同的條件，但是它只發生在緩存上發現ECC錯誤的時候，與中斷發生的時間完全一致，并且只發生在內核完成FPU操作導致除以0錯誤出現的時候。在典型的隨機測試平臺上，所有這些條件同時出現的概率是非常低的，這使得它成為一個 "隱藏 "的終極漏洞。

為了使得這些隱藏的bug在測試平臺上更容易被發現，提高驗證的質量是重點。它包括使隱藏的個例成為極端的個例此種情況。

如圖所示，4只紅色昆蟲分別代表4種類型的CPU漏洞

這種分類沒有任何限制。經驗告訴我們，一個能夠找到8分或9分漏洞的測試平臺本身就是一個強大的模擬測試平臺，是提供高質量RTL的關鍵。根據我們的觀察，今天最先進的仿真測試平臺可以找到復雜度高達10的漏洞。幸運的是，形式化驗證的使用使我們更容易找到復雜度更高的bug，為更好的設計鋪平道路，并為仿真中需要改進的地方提供線索。

使用漏洞的復雜性分類來提高驗證測試平臺的質量

這種分類和方法只有在驗證開始時和整個項目開發過程中使用才有效，原因有二：

漏洞必須在被發現時即時修復。留下一個2級或3級的bug而不即時修復，則意味著在啟動大型浸泡測試（soak test）時會出現大量的失誤。據統計，一個需要更多事件的類似bug（來自同一漏洞集群）可能會被忽略。

漏洞的復雜性被用來改善和衡量測試平臺的質量。復雜性水平與觸發漏洞所需的事件數量越匹配，復雜性得分越高，測試平臺的壓力越大。追蹤和分析觸發漏洞的事件對于了解如何調整隨機約束或創建新的功能覆蓋點來說非常有用。

最后，通過將這種方法與Codasip的驗證方法結合起來，包括獵殺以集群為單位的bug，確保了高水平的驗證質量，幫助我們確信并超越驗證驗收標準。

審核編輯 ：李倩