淺談RISC-V微架構驗證方式

對于RISC-V處理器因其靈活性和可擴展性而受到廣泛關注，但如果沒有高效驗證策略，錯誤的設計實現可能會影響RISC-V的繼續推廣。

在RISC-V出現之前，對于大多數半導體公司來說，處理器驗證幾乎成為一門屠龍之技。專業知識被濃縮到少數幾家提供處理器或處理器 IP 的商業公司中，并且經常開發自己的內部流程和工具。但是，開源 RISC-V ISA 的出現以及開源實現的激增引起了人們的極大興趣，并且需要適當的工具和專業知識。

在過去的一年里，RISC-V International宣布了幾項新的擴展。此外，鼓勵用戶進行自己的擴展和修改。雖然開發這些擴展可能是一個相對快速和簡單的過程，但驗證它們并不容易。

很少有標準或開源工具可以幫助處理器驗證。RISC-V 是一個開放的 ISA，任何人都可以接受它并實現處理器。但RISC-V市場的領導者知道，僅僅因為他們不需要支付許可使用費，并不意味著RISC-V是便宜的選擇。

如果你想在RISC-V上取得成功，驗證是沒有捷徑的。

很多人天真地認為驗證處理器就是測試指令是否有效。他們去構建一個測試生成器，做這個，做那個，或者引入一個驗證套件，但真正的問題與微架構、pipeline有關。對于微架構驗證的復雜性，沒有標準的方法，甚至沒有公開討論。

對于給定的 RISC-V?CPU，驗證容易被低估。RISC-V帶來了大量的控制和數據路徑復雜性。包括預測執行、亂序執行等等為更具挑戰性的工作負載提供更高性能的常用技術，這些技術是RISV-V成為服務器級設備中被采用CPU的必備技術。但這些技術也會導致可以利用的安全漏洞，例如 Spectre 和 Meltdown。

RISC-V的開發人員很多來自傳統的CPU架構背景，他們正在重用所學到的任何東西。但這仍然不容易，RISC-V和傳統的CPU有一些生態上的區別。

RISC-V微架構的驗證正處于一個十字路口，既要平衡開放性和靈活性的優勢，又要應對多樣性和復雜性的挑戰。隨著生態系統的成熟，應對這些挑戰對于將RISC-V確立為其他微架構（ARM、X86）的可靠和安全替代方案至關重要。

通過社區驅動的方法、持續的創新和對標準化的關注，RISC-V的驗證環境無疑將不斷發展并迎接挑戰。

不止隨機

處理器驗證不同于常規的ASIC驗證，處理器驗證空間更大。ASIC 中的 AS 代表特定應用。完全驗證芯片的預期應用是有限且有界的。處理器驗證不是。處理器指令集架構 （ISA） 中的每個操作都必須經過驗證，以便在每種可能性（每種指令組合）中提供指定的行為，而在驗證處理器 IP 時無法預測這一點。

SystemVerilog 和 UVM 是 ASIC 驗證的主力軍。UVM 是進行隨機指令生成的好方法，但它有局限性。例如，覆蓋率。如果你說你對“add指令”有 100% 的覆蓋率，你一定有與我不同的覆蓋率含義，因為我不相信你涵蓋了所有可能的組合。此外，向處理器提供激勵的典型方法是生成一堆隨機指令。你也許能夠根據要測試的特定區域來調整這些指令，但這是嘗試驗證處理器的一種非常低效的方法。它會發現一些簡單的錯誤，但你必須繼續提高驗證效率。

很多客戶都在做受約束的隨機，事實上確實存在幾個指令生成器，可以定向隨機地為你生成數十萬條指令。但這夠了嗎？

根據傳統CPU供應商的經驗，以及在RISC-V內核中看到的情況，基于仿真的驗證是不夠的。這就是為什么你必須考慮其他方法，比如Formal驗證。

處理器以自下而上的方式進行驗證，類似于當今系統的驗證方式。處理器子單元包括分支預測、pipeline的一部分或內存系統，如cache緩存。這也往往是Formal方法的亮點。有些人在受約束的隨機性下這樣驗證prefetch buffer/ALUs/register models/multipliers/load store unit，他們得到了很好的覆蓋。但是，如果你不使用Formal驗證，你就有可能在那里留下一些極端的情況，這就是驗證的最后一公里，有遺留bug的風險。

使用Formal驗證處理器子模塊

驗證子單元后，可以集成它們?？梢韵胂笤趩?Linux 時發現 ALU 錯誤是一種什么樣的體驗。

現在，需要一種更加混合的驗證策略。Formal驗證是有用的，因為從根本上說，Formal驗證會執行所有可能的輸入組合來驗證ISA指定的行為，這些行為通常被描述為SystemVerilog斷言。主要的處理器供應商還擁有廣泛的驗證套件，包括UVM測試平臺和測試軟件。仿真對于全面驗證大型處理器的所有模塊更是必要的，并確保將正確的行為集成到 SoC 中，同時還允許在被測處理器上執行測試軟件。

令人驚訝的是，一個處理器核心中可以有很多錯誤，并且仍然能夠啟動 Linux。通過真實的linux系統啟動，你會發現各種在其他EDA驗證和Formal驗證中找不到的東西，比如很多異步時序。

大多數人通過將實現的功能與參考模型進行比較來驗證處理器。規格并非在各個方面都精確，它可能沒有說明當六個相同優先級的中斷同時發生時會發生什么。微架構選擇采用哪一個，在pipeline的哪個階段處理，這些選擇因處理器內核而異。這個時候參考模型可能會起到意想不到的作用，當參考模型和RTL設計比對不通過時，你就會分析設計是否合理！

RISC-V的一大吸引力在于，你可以自由地修改處理器，使其更適合特定應用。挑戰在于，你投入的每一件事情都會使驗證加倍，復雜性加倍。添加東西非常容易，但是很難讓它們以高質量出口。很多人沒有意識到自定義指令增加的復雜性。他們必須自己進行所有這些驗證。對于你添加的所有內容，必須完全重新驗證所有內容，以及這個添加不會影響更多內容。你必須考慮它如何影響設計的其余部分，特別是如果它改變了pipeline中的內容、ALU 中的沖突、cache系統的問題或load store的東西。

你什么時候完成？
驗證永遠不會完成。普遍接受的想法是，當驗證做得足夠時，風險是可控的。

驗證的過程就是告訴你已經做了哪些事情，驗證給了你一定程度的信心，但它并不能保證不會有問題。如果你使用仿真，你可以生成大量的覆蓋率報告，這些報告會讓你有信心說你已經激發了你的設計的大部分，并且覆蓋率證明了這一點，并且你已經發現了某些類別的錯誤。

由于處理器驗證的復雜性，這種覆蓋范圍是不夠的。

處理器覆蓋率不僅僅是所有指令以及指令的耦合，此時你只是關注處理器中的解碼器。你并沒有真正測試其他任何東西，包括指令序列以及pipeline中發生的情況。

隨著 RISC-V 中引入新的自定義指令，了解微架構以及如何影響整個 SoC 及其上運行的工作負載非常重要。硬件輔助驗證，如虛擬原型功能、仿真和硬件原型設計，是整個驗證流程中的關鍵組成部分。這些技術有助于確保RISC-V微架構決策不會對功耗和性能tradeoff產生負面影響。

當涉及到安全時，需要更加嚴格。根據最終產品所需的認證級別，他們必須達到一定程度的故障覆蓋率。需要注入定義明確的故障，這些故障由 ISO 26262 為功能安全而定義。進行故障分析，然后生成診斷覆蓋率。如果在設計中為關鍵功能插入這些故障，你是否內置了安全機制來處理這些故障？

當無法完成驗證時，啟發式方法往往變得很重要。原則性建議是，在驗證是不要認為自己是一個驗證工程師，需要站在用戶的角度使用這款芯片，即必須繼續運行真正的軟件。在你運行一段時間后，一切似乎都正常。這是一個非常有價值的事情，即使無法量化，但是仍舊有很大的意義。

RISC-V的開源特性也使其面臨潛在的安全風險。雖然透明度允許社區驅動的審查，但這也意味著對手可以訪問相同的信息。這需要強大的安全驗證，確保微架構能夠抵御各種攻擊。與封閉式架構相比，RISC-V的安全挑戰更加嚴峻，專有設計可以對其安全功能保密。

RISC-V需要更多專用的驗證工具。當處理器由五家不同的公司設計時，對這些處理器的測試生成器或Formal工具的需求并不大，因為它們都是在各個公司內部構建的。但現在有了RISC-V，圍繞RISC-V ISA的架構分析、驗證、Formal肯定有一個市場。

隨著時間的推移，我們會看到人們為RISC-V的性能分析工具和Formal工具，但現在還為時過早。

下圖列出了驗證處理器微架構時可以考慮的方法。

處理器的驗證方法。

審核編輯：黃飛

?