RISC-V處理器驗證：瑞士奶酪模型驗證應用

1引言

電子行業對處理性能的要求不斷提高，無論是對移動電話等消費設備、智能卡等安全設備，還是汽車等安全關鍵系統。幾十年來，半導體的縮放使新一代系統級芯片（SoCs）能夠利用更為密集的通用處理器，直至登納德縮放定律（Dennard Scaling）結束前，提高處理器速度。

而今，除了少數應用外，最先進的處理節點對所有應用而言都太過昂貴。在大多數情況下，架構創新是提供更高性能的唯一途徑。對于計算要求較高的應用而言，理想情況下，處理器架構應與計算工作負載相匹配。

在SoC上實現的特殊計算單元或加速器可分為兩大類。一類是通過向現有處理器內核的流水線上添加附加指令來實現的。在有一組明確定義的算法需要處理，并且對通用處理器提供的廣泛服務的需求有限時，此類加速器運行良好。

另一類是處理器模塊或協處理器，通過寄存器或內存映射接口與主機通用處理器通信，并對內存有自己的訪問權限。

一段時間以來，專用指令集處理器（ASIPs）已經為專門的應用開發。這需要具備足夠專業知識的多學科團隊來開發指令集、微架構和軟件工具鏈。而很少有公司兼具開發專用指令集處理器的全部技能，所以開發此類處理器的公司相對較少。

隨著RISC-V處理器的出現，游戲規則發生了變化，開發專用處理器的門檻大幅降低?，F在，設計專用計算單元變得更容易，同時也需要更多的工程師參與進來。雖然RISC-V給處理器設計者帶來了好處，但對驗證者而言它卻提供不了幫助。驗證并發現RISC-V處理器上的諸多漏洞幾乎等同于使用另一個指令集架構（ISA）來驗證處理器。事實上，隨著RISC-V推出的新規范和執行邏輯，工程師可能會在無意中創建難以檢測的規范和被測器件（DUT）漏洞。隨著更多的社區參與開發或修改RISC-V處理器，人們需要對如何有效地驗證處理器有更多的認識。

然而，處理器驗證從來都不是小事，而是需要結合多種驗證技術的優勢。這篇技術白皮書講述了如何通過利用起源于航空電子學界的被稱為“瑞士奶酪模型”的多層方法，來有效地驗證RISC-V處理器。

2作為架構推動者的RISC-V！

直至最近，SoC設計者仍可以選擇使用專有的指令集架構授權一個現成的處理器，或是創建一個專用指令集處理器。大多數公司都缺乏創建專用指令集處理器的資源和技能，因此他們通常別無選擇，只能使用現成的處理器。因此，在某些領域，如微控制器，由于基于相同的處理器IP內核，競爭產品之間的差異有限。

專用指令集處理器也有一些明顯的缺點。首先，有一個問題是，設計的所有方面，包括指令集，都需要從頭開始開發。其次，專用處理器將缺乏軟件生態系統。

RISC-V促使生態系統變革，它具有開放、模塊化、可定制的優點，并且它的標準僅涵蓋指令集架構。這種開放性意味著設計師團隊不局限于單一供應商，整個軟件生態系統都可以使用該標準。這使得RISC-V生態系統得以迅速發展。

模塊化意味著人們可以根據需求選擇自己想要的標準擴展，使處理器能夠根據應用調整不同的配置。通過創建自定義指令來優化目標工作負載的執行，可以實現更細粒度的調優。這種將RISC-V指令集架構與預期應用相匹配的自由提供了極大的創新機遇。

由于RISC-V開放標準只涵蓋了指令集架構，因此對使用它的微架構沒有任何限制。因此，在執行單元、流水線長度、緩存等方面可能存在差異。

在許多情況下，最快速開發專用RISC-V處理器的方法是從一個相當接近于滿足需求的現有處理器設計開始，然后進行定制設計，例如，創建自定義擴展。

一種可能是從開源RTL實現開始，然而，修改RTL，更新指令集模擬器（ISS）和軟件工具鏈都依靠手動操作，這也就意味著需要更多的勞動力，且更容易出錯。

Codasip使用 CodAL架構描述語言開發其處理器。通過高水平的描述這一設計并使用Codasip Studio設計自動化，可以自動生成RTL、軟件工具鏈和驗證環境。授權Codasip的 RISC-V 處理器的CodAL架構來源是定制化的有效起點（圖1）。

圖1: 可以定制RISC-V處理器的CodAL描述，以滿足應用的需求

但是，通過定制現有處理器，需要進行額外的驗證，因為定制的處理器與原始處理器不同。盡管預先驗證的現有處理器是一個非常好的起點，但在驗證中切忌自滿。

3處理器和軟件復雜性

許多SoC工程師都熟悉RTL模塊的驗證。他們熟悉使用約束隨機驗證或形式化驗證等技術來運行個人識別碼的程序塊。

那么，處理器驗證也是同樣的挑戰嗎？執行軟件將處理器與硬連接邏輯區分開來。軟件變體意味著許多不同的指令排列組合將被應用于處理器。它們必須被準確地執行。

軟件的復雜性也差別很大。例如，一些處理器深深嵌入芯片中，這意味著芯片的用戶無法更改處理器上運行的軟件。在其他情況下，SoC中的嵌入式處理器可以由終端用戶進行編程。在第一種情況下，處理器需要與來自SoC開發商提供的少量軟件一起工作，而第二種情況則必須與來自第三方開發商提供的多種軟件以及多個實時操作系統（RTOS）一起可靠地工作。

在高端應用方面，處理器必須能夠運行富操作系統，諸如Linux或安卓。此外，大量的應用將在處理器上運行，特別是在安卓系統中，谷歌應用商店有數以百萬計的不同應用。

與硬連接邏輯的另一個區別是，處理器的執行可以被外部異步事件中斷。處理器必須在許多指令和外部事件的排列組合下正確運行。

此外，處理器故障的后果千差萬別。如果消費類無線芯片的設計錯誤導致一些數據包的丟失，那么通信協議可能會妥善地糾正該問題。但是，如果處理器的設計錯誤導致安全元件受到破壞，那就可能導致密碼或金額被盜。如果是嵌入汽車或醫療系統的處理器，那么設計錯誤可能會導致人員傷亡。

簡而言之，與大多數硬連接邏輯塊相比，處理器有巨大的狀態空間來進行驗證。驗證是處理器設計周期中最重要的組成部分。

4處理器漏洞

處理器漏洞——特別是那些導致產品召回的漏洞——有時會出現在公眾的意識中。早在1994年，英特爾就因為FDIV浮點運算缺陷而召回了奔騰處理器。2017年，一些與安全缺陷相關的漏洞，如“熔斷”和“幽靈”，影響了大量使用推測執行機制的處理器設計。

大多數處理器漏洞從未受到公眾關注，而大多數處理器用戶會驚訝地發現，設計一個典型的中端處理器需要在RTL代碼中修復1000個漏洞。使用諸如無序執行之類的高級特性，漏洞的數量可能會更多。雖然這個數字聽起來很龐大，但重要的是要記住，漏洞在復雜性上有很大的差異。

4.1漏洞分類法

正如生物學家將動物和植物分為類和種一樣，將漏洞分門別類（四類）也很有用。

4.1.1簡單漏洞

漏洞源于人為錯誤，其中一些很容易被設計師和驗證工程師發現。舉一個典型的例子，在編譯階段就能發現的語法錯誤，比如缺少一個分號。

為了避免這類錯誤，設計團隊必須仔細閱讀規范，并在開發過程中關注規范的任何更改。另一方面，驗證團隊需要進行全面檢查規范的測試。

另一個例子是規范的一部分沒有實現。如果為規范的這一部分編寫了特定的測試，那么任何像樣的測試平臺都應該能夠找到它。

當使用獲得商業許可的現成處理器時，設計者假設RTL與指令集架構完美匹配。對于RISC-V，情況也是如此，因為指令集架構是模塊化的，支持自定義指令。

如果設計了一種新的RISC-V處理器，那么就有開源的指令集模擬器（ISSs）可用，如Spike。如果使用了RISC-V指令集架構的合理標準配置，如RV32IMC，那么指令集模擬器可以作為確保RTL符合指令集架構的標準參考。然而，在添加自定義指令時，情況會變得更為復雜。

如上所述，如果一個定制的處理器或/加速器是通過修改現有的RISC-V RTL實現的，那么同時更新指令集模擬器和RTL就有可能導致錯誤。

因為Codasip Studio根據其高級描述生成RTL，并且該合成引擎已經在許多項目中測試，因此生成的RTL不太可能包含由低級編碼錯誤導致的漏洞。

通過使用通用驗證方法學（UVM）對指令集模擬器的標準參考進行驗證，可以檢查修改后的設計RTL是否符合擴展的RISC-V指令集架構（圖2）。不僅是應用軟件，隨機生成的匯編程序也可以用來刺激UVM環境。而由于處理器的狀態空間很大，執行大量的排列和指令組合是很重要的。

圖2：檢查合成的RTL與標準IA參考的一致性是處理器驗證中的一個關鍵檢查

同樣需要多加注意的是，覆蓋率報告不會發現RTL中未實現的特性。

然而，以規范為參考的代碼審查肯定有助于發現規范中未實現的部分。

綜上所述，應通過運行一個檢測來測試處理器特性，從而發現簡單漏洞。任何不良行為都是系統性的，而非一個計時條件。

4.1.2邊角案例漏洞

如上所述，用相當簡單的測試用例就可以檢測到很容易發現的漏洞。即使簡單的同步測試用例在隨機延遲的情況下執行，它們也可能通過測試，而錯失真正的漏洞。

邊角案例漏洞的查找則更復雜，需要一個強大的測試平臺。發現這樣的漏洞通常意味著異步事件。例如，執行一個中斷指令，且該指令恰好在另外兩個特定計時的指令之間到達。處理器內部還存在其他事件，比如數據結構中的先入先出隊列（FIFO）異常，就可能會對處理器的另一個程序塊施加壓力。為了找到這樣的漏洞，有必要使用一個測試平臺，在指令、參數和延遲上做文章，以便實現所有可能的指令和事件的交錯。一個優秀的檢驗員應該能發現偏離預期的情況。

其他類型的邊角案例包括功能錯誤，如數學上溢/下溢或對異常地址的內存訪問。對推測性執行的驗證尤其具有挑戰性。

同樣，代碼覆蓋率的價值也是有限的。這是因為一個漏洞的條件是幾個已經單獨涵蓋的事件的組合。條件或分支覆蓋可能會有所幫助，但很難分析。

4.1.3隱藏漏洞

一些漏洞無法通過所使用的初始處理器驗證方法檢測出來。在糟糕的情況下，它們會被客戶當場發現，而在最壞的情況下，需要召回芯片。應用額外的驗證層可以降低這些漏洞逃過檢測的概率。

通過使用多個測試平臺或驗證環境，可以發現更多的漏洞，因為刺激不同。然而，使用隨機測試平臺方法所能達到的效果是有限的。

在隨機刺激下，測試平臺傾向于生成類似的東西。

這就好比擲骰子，連續10次擲出6的概率非常低——精確到6000萬分之一的概率。如果一個RISC-V處理器支持100條不同的指令，并且有10級流水線，那么在所有流水線都出現相同指令的情況下對其進行測試也不是沒有道理的。那么，對于一個等概率隨機指令生成器來說，這種可能性有多大？產生這個序列的概率只有1020分之一！

必須調整隨機約束，以覆蓋所有更深層次的情況為目標。

4.1.4發現越來越多的漏洞

總而言之，尋找漏洞通常是一個漸進的過程，來處理愈發難以找到的漏洞（圖3）。在設計過程中，驗證方法的復雜性通常會增加。較簡單的方法會成功地發現簡單漏洞，而更強大的測試平臺則需要找到邊角案例。正如第5節中所述，需要結合多種方法來找到最困難的隱藏漏洞。

圖3：越來越先進的驗證方法發現了越來越多的漏洞

及時發現漏洞，尤其是隱藏漏洞，對于一個成功的處理器開發項目至關重要。如果太晚發現項目中的漏洞，那么上市時間將受到不利影響。

4.2評估漏洞復雜性

在設計或定制處理器時，一個顯而易見的問題是詢問處理器的驗證何時完成。換句話說，如何衡量測試平臺的效率？驗證結果的可信度如何？業界通常使用的指標包括覆蓋率和漏洞曲線。雖然這些措施是必要的，但它們不足以達到盡可能高的處理器品質。它們未能揭示驗證方法找到最后一個漏洞的能力。

4.2.1定義漏洞復雜性

漏洞復雜性已被證明是整個處理器開發周期中驗證有效性的一個較好指標。

我們所說的漏洞復雜性是指擊中漏洞所需的獨立事件或條件的數量。

舉一個簡單的例子。當數據依賴關系在設計中沒有正確實現時，在緩存中會發現一個典型的漏洞。此時數據損壞可能發生在以下情況：

1.地址@A中的高速緩存行在高速緩存中狀態為“valid”及“dirty”。

2.地址@B的加載會導致A行的驅逐。

3.在地址@A開始進行另一個加載。

4.外部寫總線比讀總線的速度慢，因此@A的加載在驅逐結束前完成。

外部存儲器返回以前的數據，因為來自驅逐的最新數據丟失了，導致數據損壞。通常，設計應檢測到這種情況，并確保正確的數據處理。

在這個例子中，需要四個事件或條件來擊中該漏洞。這四個事件給漏洞打了4分，或者換句話說，漏洞的復雜性為4。

4.2.2漏洞的分類和復雜性

在第4.1節，我們考慮了如何根據漏洞的特征對它們進行分類。

一個簡單漏洞需要通過一個簡單的測試來觸發一到三個事件。然而，一個邊角案例將需要觸發四個或更多的事件。參考第4.2.1節中的例子，如果這四個條件中的任何一個不存在，就不會檢測到該漏洞。要使用一個約束隨機測試平臺來檢測漏洞，則該平臺需要具備以下特性：

a)地址序列必須足夠智能，可以重新使用之前請求的地址，

b)外部總線上的延遲應包含足夠快速的讀寫，

c)外部總線上的延遲應包含足夠慢的讀寫。

隱藏案例則需要更多事件來觸發。例如，我們借用第4.2.1節中的例子，再額外增加了復雜性，即它只發生在緩存中發現錯誤檢查和糾正（ECC）錯誤（5），與中斷恰好同時發生（6），并且只有當處理器完成浮點處理單元（FPU）操作導致除零錯誤（7）的時候。在典型的隨機測試平臺中，所有七種條件同時出現的概率非常低，這使得它成為一個“隱藏的”漏洞。

這種漏洞的分類和復雜性沒有任何限制。經驗表明，一個能夠找到8分或9分漏洞的測試平臺確實是一個非常強大的測試平臺，并且是提供高質量RTL的關鍵。最先進的模擬測試平臺能夠找到復雜性級別高達10的漏洞。好消息是，形式化驗證使找到復雜性更高的漏洞變得更容易，這為更好的設計質量鋪平了道路，并為如何改進驗證提供了線索。

5用于處理器驗證的瑞士奶酪模型

處理器都有高品質的要求，其品質是處理器驗證團隊主要關注點。在優化資源使用的同時，驗證需要有一個足夠全面的范圍。在進入大規模生產之前，找到關鍵的處理器漏洞是至關重要的，因此驗證必須足夠徹底。另一方面，這個過程必須是高效的，以滿足上市時間的要求。

5.1用于驗證的思維模式

開發高質量處理器IP的出發點是擁有正確的驗證思維模式。為了達到一流的品質，驗證團隊的思維模式可以在一個強大的驗證計劃和一組測試之間產生差異，這將捕捉到漏洞，并生成一份漂亮的覆蓋率報告，但卻無法發現更深層次的邊角案例漏洞。為了達到較高的RISC-V設計質量，有必要采取這樣的思維模式，即任何一種驗證方法本身都不足以支撐整個驗證。與之相反，必須應用不同的驗證方法來不斷改進漏洞檢測，包括代碼審查、智能隨機驗證、操作系統（OS）引導等。

5.2起源于航空領域的瑞士奶酪模型

Codasip認為，為了實現這些目標，有必要結合所有行業標準的驗證技術——并通過瑞士奶酪模型聯系起來。瑞士奶酪模型出現在有嚴格安全要求的航空領域。這一模型是基于與埃曼塔奶酪切片的類比。眾所周知，埃曼塔奶酪以具有大小孔的組合而聞名（圖4）。假設有一組可能導致飛機事故的危險，而每一片奶酪代表一種危險檢測方法。

圖4：在瑞士奶酪模型方法學中，較小的孔代表良好的檢測方法。較大的孔洞代表一種相對不很嚴謹的方法。

為了避免飛機墜毀的風險，航空業對程序、飛行檢查單和冗余系統要求非常嚴格。如果有一條直接穿過所有切片的路徑，飛機就有墜毀的風險。用任何一種方法都會有一些危險未被發現，但如果有足夠大的奶酪切片組合，那么所有重要的危險都可以被發現。

5.3應用于處理器驗證的瑞士奶酪模型原理

同樣的分層方法也適用于處理器驗證，其起點是將用于綜合設計的RTL代碼?？梢詰枚鄠€驗證層，以確保在發布處理器IP之前檢測到漏洞（圖5）。如果改進一個給定的驗證方法，那么“孔”的大小就會減小。切片的不同部分可以視為設計的不同部分。

圖5：瑞士奶酪驗證方法在設計周期中結合了多種驗證方法

結合多種驗證技術涉及一些冗余，但通過使用互補的方法，可以最大限度地減少漏洞逃脫的風險。

通過使用不同的奶酪切片或驗證方法，我們有以下好處：

1.冗余確保了在某一層失敗時的連續性。

2.當在開發過程中發現漏洞時，就表明漏洞出現在了其中幾片奶酪上。改進驗證方法可以減少每片奶酪上的漏洞大小。我們提高了檢測漏洞的幾率，無論是簡單的漏洞，還是復雜的邊角案例漏洞。

3.最大限度發揮每種驗證技術的潛力。

奶酪片上的一個孔洞就類似于驗證方法中的一個洞。洞的數量越多，體積越大，則逃脫檢測的漏洞就越多。如果設計的相同區域（奶酪片）沒有被任何驗證技術所覆蓋（切片之間的重疊孔），那么這個漏洞就會通過驗證，并可能在最終出現在交付產品中。一種好的驗證方法應呈現盡可能少且小的孔。堅實的戰略、豐富的經驗和高效的團隊溝通是交付高質量產品的重要因素。

瑞士奶酪模型在受到持續改進時最為有效。當發現漏洞時，我們可以從用于查找漏洞的場景和檢查中吸取經驗教訓。雖然改進用于查找漏洞的那一層上的場景和檢查程序很重要，但同樣重要的是看看是否可以將經驗教訓應用于其他驗證層。這就類似于減少多個奶酪片上的孔的大小。

圖6：瑞士奶酪模型的迭代改進可提高驗證質量。這是一個良性循環。

5.4準備開始

驗證的一個良好起點是對被測器件RTL和初始測試平臺進行代碼審查。代碼審查可以很容易地發現一些簡單漏洞，例如規范中錯誤實現的部分。由于規范在設計周期中可能會發生變化，因此務必確保任何更改都已反映在代碼中。

另一個早期的檢查是驗證處理器內核是否符合所需的指令集。完整性檢查是實現這一目標的有效方法，例如，通過將設計與行業標準模型進行比較；Codasip使用的切片之一。與此類模型相比，作為標準參考，提高了Codasip RISC-V處理器的質量，并且這些模型中的漏洞已經被報告，以提高RISC-V的整體質量。如果通過添加自定義指令修改了處理器，則標準參考必須包含這些額外的指令。

處理器的RTL是分層的，因此除了在頂層運行定向測試之外，在設計層次中的較低層次創建塊級測試平臺以檢查正確的操作是有意義的。

5.5改進瑞士奶酪模型

雖然瑞士奶酪模型——由于是多層次的——本身就能很好地發現處理器漏洞，但在項目過程中改進這些層是很重要的。當發現一個錯誤——在切片驗證中的一個孔時——應該修復它，并檢查其他切片是否有類似的孔。給定切片發現的漏洞也應幫助在其他驗證切片中找到漏洞，這些漏洞應該在進一步進展之前得到解決。

單一的驗證技術不能依靠其本身找到每個漏洞，而是所有驗證技術的綜合提高了驗證的整體質量，從而提高了整體處理器的質量。

同樣重要的是要記住，設計不是靜態的（除了漏洞修復之外），在產品的開發過程中可能會有意外的變化或外部因素影響驗證。例如，設計團隊沒有向驗證團隊傳達設計變更。同樣地，一個沉悶的周五下午的工作也可能會導致人為錯誤，從而降低驗證質量。

這樣的人為錯誤會增加切片上的孔的大小，并降低驗證的有效性。

重要的是不要僅僅依賴一個驗證層，而要保持工程規范的更新，讓設計和驗證團隊良好溝通。

只有將應用漏洞復雜性和以下改進方法貫穿項目開端和整個設計開發過程中才有用。這有兩個原因：

1.必須在發現漏洞時進行修復。如果2級或3級的漏洞未被修復，就意味著在啟動大規模浸泡測試時將會發生很多故障。據統計，來自同一集群的類似漏洞，除非有更多的事件觸發，才可能會被注意到。

2.漏洞復雜性被用來改進和衡量測試平臺的質量。由于復雜性級別與觸發漏洞所需的事件數量相匹配，因此復雜性得分越高，測試平臺就越嚴格。追蹤和分析觸發漏洞的事件對于了解如何調整隨機約束或創建一個新的功能覆蓋點非常有用。

5.6使用智能隨機測試擊中漏洞集群

處理器漏洞的一大特點是，它們很少單獨出現。事實上，就像昆蟲一樣，蟲子通常是成群結隊的。換句話說，當通過定向測試在設計的給定區域發現一個漏洞時，在設計的同一區域很有可能有更多具有類似條件的漏洞。

如果發現了一個新的處理器漏洞，那么它不應該是驗證之旅的結束，而是一個找到更多漏洞的機會。

這個漏洞應該被用作一根指針，幫助查找同一區域的更多漏洞。它應當是找到整個漏洞集群的提示。

試想一下，一個頂級隨機測試在經過數千小時的測試后發現了一個漏洞。這個漏洞很可能是由以前從未遇到過的事件組合發現的。這很可能由外部修改引起，例如，測試中參數的更改、RTL修改或模擬器修改。

通過發現這個罕見的新漏洞，很明顯會有一個更嚴格的測試平臺，用來測試一個新的設計領域。

然而，在測試平臺被改進之前，這個設計領域并沒有被強調。如果我們認識到漏洞成群結隊出現，那么這個區域就需要進一步的探索來找到更多的漏洞。

為了擊中這些漏洞檢查器，我們可以添加斷言和測試。來看這個測試，如果這個漏洞通過定向測試再現，那么只有完全相同的漏洞才會被擊中。與之相反，在同一區域很可能有其他具有類似條件的漏洞。為了擴大打擊漏洞集群中其他漏洞的范圍，可以使用智能隨機測試。請注意，正常的無目標隨機測試在這種情況下無效，因為給定的漏洞集群模式有一個明確的目標。

如果這個漏洞是在一個特定的RISC-V指令上發現的，那么一個合理的問題是，是否可以通過增加該指令的測試概率來改善測試呢？乍一看可能是這樣，從統計學角度分析，失敗越多，暴露的漏洞也會越多，但大多數漏洞都是通過一系列罕見事件的組合發現的。此類事件的例子包括停滯的流水線、完整的數據結構中的先入先出隊列（FIFO），或者其他一些微架構的細節。

標準的測試平臺可以通過簡單地改變一個測試參數來調整指令的概率。然而，充滿FIFO通常是不可能的。當測試平臺僅通過改變一個參數來針對性地充滿FIFO，以觸發其他獨立參數（如延遲）的組合時，測試策略可以得到明顯改善。

對于一個設計中新發現漏洞的區域，智能隨機測試通過將搜索范圍擴大到設計的鄰近區域，來有效地發現更多的漏洞。它包括通過調整多個參數來調整測試，以激活更多觸發漏洞的事件。雖然這看起來很耗時，但這種方法在提高測試質量和處理器的質量方面很有效。

5.7隨機測試后檢查覆蓋率

覆蓋率是著名的“覆蓋率驅動驗證方法”的反饋回路。它在隨機刺激的情況下特別有用。由于是隨機的，驗證工程師只控制應用于被測設備的不同模式的權重。在不同種子的幫助下，隨機生成模式將被組合起來，并在模擬過程中被應用到設備上。但是，需要多少不同的種子才能確保處理器的測試呢？測量覆蓋率作為一個度量標準，可以讓人相信隨機生成器已經生成了所有需要的情況。

特別是，它應該對之前進行的隨機驗證步驟的質量給出反饋，無論是在頂層還是區塊級別。

代碼覆蓋的類型包括：

●語句覆蓋

●條件/表達式覆蓋

●分支/判定覆蓋

●翻轉覆蓋

●狀態機（FSM）覆蓋

如果在代碼覆蓋中發現漏洞，則需要設計進一步的測試來運行代碼的這些部分。

功能覆蓋是確保模式執行特定功能的另一個重要部分，傳統的代碼覆蓋不一定能測量。它在以下兩個領域尤其有效：

-架構覆蓋（確保執行了各種類型的指令，并結合各種中斷的情況）

-微架構覆蓋，以確保對罕見的功能進行深度測試。

5.8使用形式化驗證來搜索隱藏漏洞

雖然智能隨機測試可以用來擴大被測試的設計區域，但重要的是要明白隨機測試并不是徹底的。最新的漏洞可能出現在現有測試平臺未覆蓋的區域，或者需要通過一個天文數字周期的模擬才能被找到。這種情況類似于在夜晚尋找一個丟失的物品。

圖7：傳統模擬類似于在一盞路燈下尋找丟失的物品，但形式化驗證類似于在有充分照明的街道上尋找。

傳統模擬可以類似于在一盞路燈下尋找。然而，大部分的街道空間都處在黑暗之中。智能隨機驗證可以擴大照明區域，但不能到處搜索。形式化驗證可以徹底地搜索，此種形式類似于在有充分照明的街道上進行搜索。

模擬需要投入促進因素的開發。相比之下，形式化驗證不需要在促進因素方面下功夫，但需要限定足夠的檢查。

因此，形式化技術是瑞士奶酪模型中的一個關鍵部分。通過在覆蓋下使用詳盡的分析，并以形式化術語反映被測器件的規范，可以發現未預見到的設計路徑，這些路徑中隱藏著其他驗證方法所不能揭示的漏洞。

通過為每個指令使用一組專用的操作斷言模板，可以實現高度的自動化。具體來說，這種方法使用了SystemVerilog斷言（SVA）的擴展，該斷言提供了高層次的、不重疊的斷言，以捕獲端到端的事務和需求。這種簡明、流暢的方法的優勢包括：

●能夠轉化功能要求，以自動檢測規范的遺漏和錯誤，以及驗證計劃中的漏洞和未經驗證的RTL功能。

●以簡明流暢的方式捕獲整個電路事務，類似于時序圖。

●將特定實現的支持驗證代碼與可重用的規范級代碼清晰地分開。

●通過高層次和易于審查的斷言，實現100%的功能覆蓋。

來看看以下在處理器設計中驗證RISC-V FSQRT行為時遇到的真實例子。RISC-V指令集手冊中對指令字段的定義如下：

圖8：RISC-V FSQRT指令格式

該標準要求源寄存器字段rs1為“0”，以使指令有效（圖8）。形式化驗證發現了一個反例，在這個反例中，編碼為rs1不等于“0”的指令被錯誤地解碼為FSQRT，而不是未定義。

圖9：一致性檢查發現由硬連接信號引起的死碼。

另一個關于自動一致性檢查如何識別潛在漏洞的例子如上圖所示（圖9）。第一個代碼片段（左）顯示了一個依賴于流水線控制器代碼片段（中）中的信號的分支。形式化檢查標記了信號s_ex1_clear被綁定為零（右側片段），這意味著該分支是不可執行的。

5.9通過使用現場可編程邏輯門陣列（FPGA）操作系統啟動來給設計施加壓力

許多提及的瑞士奶酪方式方法都涉及到RTL的模擬。這很容易設置，但其缺點是相對較慢。這意味著，即使模擬運行數天，完成的處理器時鐘周期數也相對較少。RTL模擬器的運行速度范圍平均為每秒數百或數千條指令。

處理器設計的FPGA實現將比RTL模擬快得多，盡管比SoC實現慢。對于處理器的設計，使用FPGA可以達到10-50兆赫的速度。為了創建原型，有必要合成處理器子系統，并從FPGA板的內存中運行代碼。其周轉時間高于RTL模擬。

使用處理器的FPGA實現允許以比模擬多幾個數量級的時鐘周期來執行設計。這種奶酪層的一個典型應用是啟動操作系統，并運行各種壓力測試，以便在現實的場景中來運行設計。

6結語

RISC-V作為一個開放的、模塊化、可定制的指令集架構，為架構創新提供了新的機會。

然而，只有具備足夠的驗證策略，這種機會才能通過現代SoC設計所需的質量來實現。隨著越來越多的團隊參與RISC-V開發，越來越多的工程師需要精通處理器驗證方式方法。

Codasip提供了一種涉及多種驗證方法的多層方法，以實現優越的處理器質量水平。這種瑞士奶酪模型的方法類似于在航空電子學中為確保高水平的可靠性和飛行安全而采取的做法。該方法在設計周期中迭代的改進驗證層，以最大限度地提高漏洞檢測的概率。瑞士奶酪驗證層的迭代改進是支持提高處理器質量的良性循環。

對于定制的RISC-V處理器，可以采用相同的方法，但要以經過驗證的處理器為起點。

審核編輯 ：李倩