1引言

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

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

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

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

一段時間以來，專用指令集處理器（ASIPs）已經(jīng)為專門的應用開發(fā)。這需要具備足夠?qū)I(yè)知識的多學科團隊來開發(fā)指令集、微架構(gòu)和軟件工具鏈。而很少有公司兼具開發(fā)專用指令集處理器的全部技能，所以開發(fā)此類處理器的公司相對較少。

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

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

2作為架構(gòu)推動者的RISC-V！

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

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

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

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

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

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

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

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

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

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

3處理器和軟件復雜性

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

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

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

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

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

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

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

4處理器漏洞

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

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

4.1漏洞分類法

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

4.1.1簡單漏洞

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

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

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

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

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

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

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

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

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

同樣需要多加注意的是，覆蓋率報告不會發(fā)現(xiàn)RTL中未實現(xiàn)的特性。

然而，以規(guī)范為參考的代碼審查肯定有助于發(fā)現(xiàn)規(guī)范中未實現(xiàn)的部分。

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

4.1.2邊角案例漏洞

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

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

其他類型的邊角案例包括功能錯誤，如數(shù)學上溢/下溢或?qū)Ξ惓５刂返膬?nèi)存訪問。對推測性執(zhí)行的驗證尤其具有挑戰(zhàn)性。

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

4.1.3隱藏漏洞

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

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

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

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

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

4.1.4發(fā)現(xiàn)越來越多的漏洞

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

圖3：越來越先進的驗證方法發(fā)現(xiàn)了越來越多的漏洞

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

4.2評估漏洞復雜性

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

4.2.1定義漏洞復雜性

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

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

舉一個簡單的例子。當數(shù)據(jù)依賴關(guān)系在設(shè)計中沒有正確實現(xiàn)時，在緩存中會發(fā)現(xiàn)一個典型的漏洞。此時數(shù)據(jù)損壞可能發(fā)生在以下情況：

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

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

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

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

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

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

4.2.2漏洞的分類和復雜性

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

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

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

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

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

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

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

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

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

5.1用于驗證的思維模式

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

5.2起源于航空領(lǐng)域的瑞士奶酪模型

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

圖4：在瑞士奶酪模型方法學中，較小的孔代表良好的檢測方法。較大的孔洞代表一種相對不很嚴謹?shù)姆椒ā?/p>

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

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

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

圖5：瑞士奶酪驗證方法在設(shè)計周期中結(jié)合了多種驗證方法

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

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

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

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

3.最大限度發(fā)揮每種驗證技術(shù)的潛力。

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

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

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

5.4準備開始

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

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

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

5.5改進瑞士奶酪模型

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

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

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

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

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

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

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

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

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

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

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

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

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

通過發(fā)現(xiàn)這個罕見的新漏洞，很明顯會有一個更嚴格的測試平臺，用來測試一個新的設(shè)計領(lǐng)域。

然而，在測試平臺被改進之前，這個設(shè)計領(lǐng)域并沒有被強調(diào)。如果我們認識到漏洞成群結(jié)隊出現(xiàn)，那么這個區(qū)域就需要進一步的探索來找到更多的漏洞。

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

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

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

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

5.7隨機測試后檢查覆蓋率

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

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

代碼覆蓋的類型包括：

●語句覆蓋

●條件/表達式覆蓋

●分支/判定覆蓋

●翻轉(zhuǎn)覆蓋

●狀態(tài)機（FSM）覆蓋

如果在代碼覆蓋中發(fā)現(xiàn)漏洞，則需要設(shè)計進一步的測試來運行代碼的這些部分。

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

-架構(gòu)覆蓋（確保執(zhí)行了各種類型的指令，并結(jié)合各種中斷的情況）

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

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

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

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

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

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

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

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

●能夠轉(zhuǎn)化功能要求，以自動檢測規(guī)范的遺漏和錯誤，以及驗證計劃中的漏洞和未經(jīng)驗證的RTL功能。

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

●將特定實現(xiàn)的支持驗證代碼與可重用的規(guī)范級代碼清晰地分開。

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

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

圖8：RISC-V FSQRT指令格式

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

圖9：一致性檢查發(fā)現(xiàn)由硬連接信號引起的死碼。

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

5.9通過使用現(xiàn)場可編程邏輯門陣列（FPGA）操作系統(tǒng)啟動來給設(shè)計施加壓力

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

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

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

6結(jié)語

RISC-V作為一個開放的、模塊化、可定制的指令集架構(gòu)，為架構(gòu)創(chuàng)新提供了新的機會。

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

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

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

審核編輯 ：李倩