來源：編譯自semiengineering

本文轉自：半導體行業觀察

驗證涉及多個學科，每個學科都至關重要，而且都變得日益復雜。RISC-V 又增加了一個學科——架構一致性——直到最近，這方面的研究還只是少數幾家公司在私下進行。

采用 RISC-V 的一個關鍵原因是希望提升性能或功耗特性。然而，如何有效地衡量這些優勢尚不明確。如何在不影響軟件可移植性的前提下，權衡架構特性與這些特定應用目標之間的關系？

RISC-V國際組織（RVI）正在評估自身需要參與的程度。在定義RISC-V內核方面，RVI是否對社區負有責任？如何才能確定某個實現符合相關規范？除非開展全面的驗證工作，否則這并非易事。

至少部分困惑源于功能驗證領域從未對驗證完備性做出明確定義。如果將其視為所有可能性的乘積，很快就會導致一個棘手的問題。盡管如此，業界仍然能夠發布有效的產品，這證明了那些能夠判斷哪些因素至關重要，以及如何實現驗證流程的工程師的卓越能力，從而使投入的時間和金錢獲得良好的回報。

一致性驗證是一項大多數工程師已經遺忘的驗證技能，但業界必須迅速迎頭趕上。“架構一致性驗證和實現驗證之間的區別至關重要，盡管它們經常被混為一談，這讓驗證工程師們感到棘手，”西門子EDA解決方案管理總監Vladislav Palfy說道。“架構一致性驗證旨在確認你設計的東西是否真的是一個RISC-V內核。你需要驗證它是否按定義執行指令、正確處理異常、正確實現內存模型等等。它驗證的是你是否按照官方規范使用了正確的RISC-V語言。另一方面，實現驗證則旨在確保你的特定設計在實際應用中能夠正常工作，而實際應用中往往會出現各種各樣的問題。我們指的是所有微架構細節，例如流水線實現、緩存一致性、分支預測，以及那些只有在最不方便的時候才會出現的特殊情況，通常是在咖啡因和截止日期臨近的情況下。”

雖然這兩項任務聽起來相似，但它們需要不同的方法，而且在某些情況下，定義和執行這些任務的責任可能由不同的團隊或組織承擔。“盡管這兩項活動有共同之處，但它們之間存在細微差別，驗證方法也截然不同，”Breker Verification Systems 的首席執行官 Dave Kelf 表示。“RISC-V 內核供應商現在正面臨著與 Arm、Intel 和其他公司相同的問題，他們正努力解決這些問題，并在新的驗證流程開發方面投入巨資。”

RVI 一直在努力完成這項任務的一部分。“RVI 一直在攻克認證難題，”Breker 的創始人兼首席技術官 Adnan Hamid 表示。“認證原本只是架構驗證的一小部分，但由于擴展功能的不斷增加，它仍然是一個日益嚴峻的問題。其范圍非常廣泛，而且并非一成不變。他們一直在添加新的內容。整個行業不得不共同探索一種覆蓋率可追溯性流程，這相當于要逐節審查規范，也就是用熒光筆標記出需要驗證的句子。這是第一步。然后，將這些句子提取出來，進行分類，并確定需要覆蓋的自由度。這是組織工作。接下來，制定測試流程，并決定如何實現該測試流程。你需要從這些規范規則開始，一直追溯到原始規范，實現全程可追溯性。”

軟件兼容性

RISC-V 以及任何其他處理器的成功都與其周圍的生態系統密切相關。“目前，RISC-V 的標準化工作主要集中在架構一致性上，確保實現中所有軟件可見的部分都按照指令集架構 (ISA) 和平臺規范進行運行，” Arteris產品管理和市場總監 Ashley Stevens 表示。“架構一致性測試套件驗證指令、CSR、特權模式、中斷行為、內存模型以及其他 ISA 可見的組件——包括中斷控制器或 IOMMU（當它們包含在軟件契約中時）。這些測試套件在社區、公司和標準組織的貢獻下不斷完善，為功能完整性提供了堅實的基準。這可以通過 ISA 級別的覆蓋率指標或與參考模型的差異測試來衡量。”

并非所有人都關心軟件兼容性。“如果你是一家大型供應商，你可能不會太在意標準的開放性和互操作性，因為一切都由你掌控，” Synopsys戰略項目和系統解決方案執行總監 Frank Schirrmeister 表示。“你只是為了自己而做，無需證明核心架構是否能夠正確解讀指令集架構 (ISA) 和相關規范，從而確保軟件能夠在不同核心的平臺上運行。這與為了開放性而設計軟件的情況截然不同。如果你看看 RVI 組織，他們希望進行類似其他領域的合規性檢查。而合規性檢查的真正目的就是為了實現軟件的互操作性。如果你的軟件通過了合規性檢查，那么它就應該能夠在不同的平臺上運行。”

RISC-V 架構并非易于實現。“RISC-V 的致命弱點恰恰在于其最大的優勢——開放指令集架構的靈活性，”Breker 公司的 Kelf 表示。“這種寶貴的靈活性也可能導致不同來源的設備之間出現不兼容的情況，因為工程師們需要努力理解不斷發展的 ISA 規范。這種不兼容性降低了軟件棧在不同設備間的可移植性，從而導致顯著的工程開銷。”

這就是為什么需要對問題進行限定。“RISC-V 的起源和理念在于開放性和可擴展性，”Synopsys 設計驗證解決方案產品經理 Aimee Sutton 表示。“RISC-V 沒有統一的定義。創建配置文件是為了方便軟件移植，但沒有人會因為偏離了指令集架構 (ISA) 就斷言這不是 RISC-V 內核。我們的 RISC-V 驗證解決方案定義了 ISA 覆蓋范圍，并使其可配置和可擴展，以便客戶能夠充分利用這些代碼。SystemVerilog 代碼超過 10 萬行。客戶可以利用這些代碼，然后專注于編寫更符合自身設計需求的、更有價值的覆蓋范圍。”

標準仍然是兼容性的核心。“架構一致性和實現驗證是獨立進行的，但對于確保整體 IP 驗證的完整性至關重要，”Microchip Technology FPGA 業務部門的技術專家 Pierre Selwan 表示。“架構一致性通常是通過遵守所有相關標準和規范來實現的。黃金參考模型用于確保相關擴展的 ISA 合規性。所有標準總線及其相應的接口以及任何其他標準化模塊都會進行測試。”

歸根結底，一致性意味著一組特定的測試用例已經與黃金模型進行了比對。“RVI 通過哈維穆德學院開發了一套相對簡單的測試用例，”Kelf 說。“他們可以完成大部分非特權測試，但當涉及到特權測試時，自動化就變得困難得多。他們必須手動編寫這些測試用例。對于他們認為自己無法完成，且 RVI 無法從其他開源解決方案中獲取的功能，我們將介入并提供所需的測試用例。這些功能將更加復雜，難以手動編寫，但我們可以通過我們的測試合成工具生成這些測試用例。”

從合規到實施

“建立合規性面臨兩大挑戰。首先，要確保核心系統能夠正常運行；其次，要確保核心系統始終能夠正確運行，” Axiomise首席執行官 Ashish Darbari 表示。 “雖然基于仿真的單元測試和合規性測試套件能夠解決存在性挑戰（即測試通過）的問題，但它們并非解決完全合規性問題的理想方案，也就是說，無論指令何時執行，所有指令的所有交錯組合都能對所有操作數正確運行。形式化技術是進行此類詳盡分析的自然選擇，并且通過使用強大的不變量（這些不變量可以通過形式化模型檢測工具進行驗證）不斷成功地證明了這一點。這種方法的優勢在于，除了發現功能性缺陷外，它還能捕獲死鎖、活鎖、安全性和可靠性問題。一旦缺陷被修復，就會再次運行不變量以獲得詳盡的證明，從而毫無疑問地證明缺陷已被捕獲。場景覆蓋率（六維覆蓋率的一部分）提供了基于證明的對可能場景的洞察，為架構師和驗證工程師提供了深入的見解。”

然而，要完全確信某項功能有效并非易事。“覆蓋率指標就像驗證儀表盤上的不同儀器，每個指標都衡量著一些重要的東西，但沒有哪個指標能夠單獨講述完整的故事，”西門子的帕爾菲說道。“代碼覆蓋率告訴你哪些邏輯被執行過。功能覆蓋率告訴你哪些場景被測試過。斷言覆蓋率確認特定屬性在執行過程中是否成立。每個指標都提供了一部分真相，但關鍵在于——它們講述的都是不同的故事，而且往往是孤立存在的。你的代碼覆蓋率可能非常出色，但卻完全忽略了RISC-V指令流水線中的一個關鍵邊界情況。你可能完美地完成了功能場景的測試，但卻從未真正測試過那些對認證至關重要的架構合規性要點。”

幾十年來，用于獲取覆蓋率信息的設計測試流程基本保持不變。“我們會進行大量的壓力測試，在指定的擴展范圍內隨機發送數千條指令，”Microchip公司的Selwan說道。“我們還會使用大量的測試平臺來驗證實現的完整性。”

測試執行速度越快越好。“我們緩解驗證周期挑戰的方法之一是使用硬件輔助驗證來加快測試執行速度，”Synopsys 的 Sutton 表示。“覆蓋率是其中的一部分，因為它能幫助你了解測試內容。這并非簡單地用大量測試用例進行海量測試，但這無疑是解決我們之前提到的 10 到 18 個測試周期挑戰的一種方法。”

越來越多的引擎正被賦予加速驗證的使命。“我們的目標是能夠部署整個驗證流程，這意味著可以使用所有類型的驗證引擎，”Synopsys 的 Schirrmeister 表示。“這涵蓋了從虛擬平臺架構到硬件輔助驗證和驗證 IP 的整個過程，其中驗證 IP 對接口尤為重要。測試生成工具也融入其中。例如，要考察架構覆蓋率——指令、權限、通過、異常等。為了測試這些覆蓋率，可以使用覆蓋組，這些覆蓋組可以在仿真環境中運行。然后還要考察各種場景。因此，情況變得更加復雜。形式化驗證在某些方面表現出色。”

測試綜合的一項重要功能是它可以針對多種執行引擎。“你需要能夠為仿真、模擬、FPGA 和芯片后測試環境綜合測試內容，”Breker 公司的 Hamid 說道。“這可能包括事務級測試，也可能包括運行在內核上的軟件。在每個層級，測試覆蓋率都會提高大約 102 倍。例如，你可以在仿真環境中測試10? 個用例，在模擬環境中測試 10?個用例，在芯片后測試環境中測試10? 個用例。在芯片后測試10?或 10?個用例也是合理的。”

你不能總是重復驗證同樣的東西。“實現驗證占據了工程工作的大部分精力，”Arteris 公司的 Stevens 說。“這包括微架構的極端情況、時序交互、一致性、順序、安全屬性以及軟件無法看到的硬件間協議接口。要實現完整性，需要仿真、模擬、UVM 環境、覆蓋率驅動的測試以及越來越多地使用形式化驗證。與自然映射到指令級覆蓋率的架構測試不同，實現完整性很難量化。它很大程度上取決于每個設計的具體結構和接口。”

覆蓋率指標可以顯示您實現目標的進展情況。“覆蓋率指標是評估設計驗證質量的關鍵，”Microchip 的 Selwan 表示。“功能覆蓋率與結構覆蓋率指標相輔相成，例如語句覆蓋率、分支覆蓋率、條件覆蓋率、翻轉覆蓋率和有限狀態機 (FSM) 覆蓋率。提取高度可配置的嵌入式 IP 核（例如 MIV_RV32）的覆蓋率指標更具挑戰性，通常需要進行大量測試才能滿足覆蓋率要求。工具供應商目前正在努力改進其產品，使其能夠從高度可配置的實現中提取覆蓋率指標。”

定義這些指標需要技術精湛的工程師。“微架構中哪些部分值得測量覆蓋率？哪些隊列容易溢出？這項工作成本不低，而且我不知道有什么自動化方法可以實現，”Hamid說道。“客戶必須逐一標記他們想要覆蓋的內容。這是一個成本很高的問題，但至少我們可以描述它，只要有足夠的時間和資金，我們就可以著手去做。現在我們發現這個系統中的Q5沒有發生溢出。這能實現嗎？它是否可行？如果可行，需要什么樣的場景？這些信息在全局范圍內往往是未知的，也就是說，沒有人知道——甚至架構師也不知道。我們沒有足夠的細節來判斷這種情況是否可行。我們正在做出工程決策，確定哪些部分需要確定性地進行交叉，而其他部分則隨機化。但這只是考慮個別場景，而這些場景的順序安排可能會導致不同的硬件問題。”

完整性要求理解不同覆蓋類型之間的關系。“僅僅知道你的 RTL 代碼執行到了第 247 行是不夠的，”Palfy 說，“你需要知道在所有重要條件下是否都執行到了這一行，相關的斷言是否正確觸發，你的測試計劃是否真正旨在驗證該場景，以及它是否映射到特定的架構需求。你需要將所有覆蓋數據統一起來，同時保持它們之間的關系、層次結構和可追溯性。想象一下，能夠看到來自每個驗證引擎（仿真、模擬、形式化測試）的覆蓋數據被智能地合并，同時保持設計結構，跟蹤哪些測試貢獻了哪些覆蓋，最重要的是，還能顯示其中的差距。”

驗證漏洞

除了實現層面的覆蓋漏洞之外，如今整個理念層面也存在覆蓋漏洞。隨著時間的推移，人們正在努力填補這些漏洞。

“RISC-V 生態系統的一大缺陷在于核心指令集架構 (ISA) 之外缺乏標準化的硬件接口，”Stevens 表示。“可擴展的片上系統 (SoC) 集成依賴于處理器與系統其他部分（包括互連）之間可預測、可互操作且可驗證的連接。正因如此，實現驗證才顯得尤為重要。雖然許多 RISC-V 開發人員采用了現有的接口，例如 AMBA CHI，但這些規范的篇幅已超過 1000 頁，其中很多內容對于典型的 RISC-V 系統而言都是不必要的。真正能夠造福社區的是一個專注于 RISC-V 的子集，或者一套與實際應用場景相符的精簡接口標準。這樣的標準化將顯著減少重復的驗證工作，提高覆蓋率的一致性，并加速多廠商之間的互操作性。”

有些差距遠不止功能性問題。“我最近和一位工程師聊過，他剛為一個汽車應用完成了RISC-V內核的流片，”帕爾菲說道。“這個內核通過了所有架構測試，但在軟件啟動三個月后，他們發現分支預測器的準確率跟拋硬幣一樣低。技術上正確，但功能上毫無用處。他們承諾的所有性能根本沒有實現。而且世界上沒有任何測試套件能發現這個問題，因為性能驗證并非生態系統的標準化內容。每個人都在構建自己的定制基礎設施來回答‘這東西真的運行得快嗎？’這個問題。”

然而，速度快也會帶來其他問題。“對于某些設計，當你提高時鐘性能時，設計中的某些部分會變成熱點，你真的需要開始關注這些問題了，”凱爾夫問道。“我們可以運行實際工作負載和合成工作負載，看看是否會觸發熱點。這與功耗問題息息相關。真正關注這一點的公司，例如汽車和數據中心，希望確保他們能夠測試這些熱點，并通過調整時鐘來驗證他們能夠處理熱阻和功耗問題。”

汽車行業和其他一些應用領域一樣，給這個問題增添了新的層面。“如果你正在為汽車或工業應用構建 RISC-V 系統，那么在安全性和可靠性驗證方面，你將面臨全新的挑戰，”Palfy 說道。“ISO 26262 標準并不關心你是否通過了 ISA 測試。它關注的是故障注入、錯誤處理以及功能安全機制的有效性。現有的測試套件在設計之初并沒有考慮到這些，所以你只能從零開始。”

其他技術的作用

形式化驗證增加了一系列互補的功能，這些功能發揮著重要作用。“早期的 RISC-V 討論中就提到了形式化方法，”Palfy 說。“當時有一種樂觀的想法：‘這是一個開放規范。我們可以對整個內核進行形式化驗證，使其符合指令集架構 (ISA)，并證明其正確性。’這在理論上很美好，但在實踐中卻非常殘酷。”

然而，形式化驗證仍然發揮著重要作用。“形式化驗證正成為解決方案中越來越重要的組成部分，”史蒂文斯說道。“它在架構合規性方面尤其強大——確保指令集架構（ISA）屬性對所有合法指令序列都成立——以及在實現驗證中強制執行硬件協議的正確性。但形式化驗證并不能取代動態驗證或系統級驗證，尤其是在涉及完整的片上系統（SoC）行為和實際工作負載時。在實踐中，形式化方法扮演著補充角色，證明深度邊界情況的正確性，而仿真和模擬則建立端到端的完整性。”

形式化驗證正被積極應用。“采用形式化驗證提供了一種方法，可以在一定范圍內全面測試我們設計的有效性，從而從一開始就提高代碼質量，”Selwan說道。“靜態形式化工具被廣泛用于及早發現和解決缺陷，從而最大限度地縮短后續驗證周期。形式化驗證是我們開發周期中的一個重要環節，通過驗證，它將繼續在實現高質量嵌入式IP產品方面發揮重要作用。”

新的人工智能功能也可以得到充分利用。“RISC-V 是應用智能體人工智能進行驗證的絕佳領域，” ChipAgents首席執行官 William Wang 表示。“我們已經看到智能體人工智能在形式化驗證方面取得了顯著成功，尤其因為處理器設計主要由控制信號構成，這使得它們非常適合形式化推理和符號探索。這與人工智能加速器形成鮮明對比，后者往往涉及更多以數據為中心的流程，不太適合純粹的形式化技術。隨著 RISC-V 的普及，人工智能驅動的形式化方法可以顯著加速架構一致性驗證和實現驗證，為確保日益復雜、可配置的設計的正確性和覆蓋率提供可擴展的方法。”

參考鏈接

https://semiengineering.com/does-your-risc-v-core-meet-with-the-standard/