來源：編譯自semiengineering

本文轉(zhuǎn)自：半導體行業(yè)觀察

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

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

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

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

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

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

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

軟件兼容性

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

并非所有人都關心軟件兼容性。“如果你是一家大型供應商，你可能不會太在意標準的開放性和互操作性，因為一切都由你掌控，” Synopsys戰(zhàn)略項目和系統(tǒng)解決方案執(zhí)行總監(jiān) Frank Schirrmeister 表示?！澳阒皇菫榱俗约憾觯瑹o需證明核心架構(gòu)是否能夠正確解讀指令集架構(gòu) (ISA) 和相關規(guī)范，從而確保軟件能夠在不同核心的平臺上運行。這與為了開放性而設計軟件的情況截然不同。如果你看看 RVI 組織，他們希望進行類似其他領域的合規(guī)性檢查。而合規(guī)性檢查的真正目的就是為了實現(xiàn)軟件的互操作性。如果你的軟件通過了合規(guī)性檢查，那么它就應該能夠在不同的平臺上運行。”

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

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

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

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

從合規(guī)到實施

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

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

幾十年來，用于獲取覆蓋率信息的設計測試流程基本保持不變?！拔覀儠M行大量的壓力測試，在指定的擴展范圍內(nèi)隨機發(fā)送數(shù)千條指令，”Microchip公司的Selwan說道?！拔覀冞€會使用大量的測試平臺來驗證實現(xiàn)的完整性?！?/span>

測試執(zhí)行速度越快越好?！拔覀兙徑怛炞C周期挑戰(zhàn)的方法之一是使用硬件輔助驗證來加快測試執(zhí)行速度，”Synopsys 的 Sutton 表示。“覆蓋率是其中的一部分，因為它能幫助你了解測試內(nèi)容。這并非簡單地用大量測試用例進行海量測試，但這無疑是解決我們之前提到的 10 到 18 個測試周期挑戰(zhàn)的一種方法?！?/span>

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

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

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

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

定義這些指標需要技術精湛的工程師?！拔⒓軜?gòu)中哪些部分值得測量覆蓋率？哪些隊列容易溢出？這項工作成本不低，而且我不知道有什么自動化方法可以實現(xiàn)，”Hamid說道?！翱蛻舯仨氈鹨粯擞浰麄兿胍采w的內(nèi)容。這是一個成本很高的問題，但至少我們可以描述它，只要有足夠的時間和資金，我們就可以著手去做?，F(xiàn)在我們發(fā)現(xiàn)這個系統(tǒng)中的Q5沒有發(fā)生溢出。這能實現(xiàn)嗎？它是否可行？如果可行，需要什么樣的場景？這些信息在全局范圍內(nèi)往往是未知的，也就是說，沒有人知道——甚至架構(gòu)師也不知道。我們沒有足夠的細節(jié)來判斷這種情況是否可行。我們正在做出工程決策，確定哪些部分需要確定性地進行交叉，而其他部分則隨機化。但這只是考慮個別場景，而這些場景的順序安排可能會導致不同的硬件問題。”

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

驗證漏洞

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

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

有些差距遠不止功能性問題?！拔易罱鸵晃还こ處熈倪^，他剛為一個汽車應用完成了RISC-V內(nèi)核的流片，”帕爾菲說道?！斑@個內(nèi)核通過了所有架構(gòu)測試，但在軟件啟動三個月后，他們發(fā)現(xiàn)分支預測器的準確率跟拋硬幣一樣低。技術上正確，但功能上毫無用處。他們承諾的所有性能根本沒有實現(xiàn)。而且世界上沒有任何測試套件能發(fā)現(xiàn)這個問題，因為性能驗證并非生態(tài)系統(tǒng)的標準化內(nèi)容。每個人都在構(gòu)建自己的定制基礎設施來回答‘這東西真的運行得快嗎？’這個問題?！?/span>

然而，速度快也會帶來其他問題?！皩τ谀承┰O計，當你提高時鐘性能時，設計中的某些部分會變成熱點，你真的需要開始關注這些問題了，”凱爾夫問道?！拔覀兛梢赃\行實際工作負載和合成工作負載，看看是否會觸發(fā)熱點。這與功耗問題息息相關。真正關注這一點的公司，例如汽車和數(shù)據(jù)中心，希望確保他們能夠測試這些熱點，并通過調(diào)整時鐘來驗證他們能夠處理熱阻和功耗問題?！?/span>

汽車行業(yè)和其他一些應用領域一樣，給這個問題增添了新的層面?！叭绻阏跒槠嚮蚬I(yè)應用構(gòu)建 RISC-V 系統(tǒng)，那么在安全性和可靠性驗證方面，你將面臨全新的挑戰(zhàn)，”Palfy 說道?！癐SO 26262 標準并不關心你是否通過了 ISA 測試。它關注的是故障注入、錯誤處理以及功能安全機制的有效性?，F(xiàn)有的測試套件在設計之初并沒有考慮到這些，所以你只能從零開始?！?/span>

其他技術的作用

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

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

形式化驗證正被積極應用?！安捎眯问交炞C提供了一種方法，可以在一定范圍內(nèi)全面測試我們設計的有效性，從而從一開始就提高代碼質(zhì)量，”Selwan說道?！办o態(tài)形式化工具被廣泛用于及早發(fā)現(xiàn)和解決缺陷，從而最大限度地縮短后續(xù)驗證周期。形式化驗證是我們開發(fā)周期中的一個重要環(huán)節(jié)，通過驗證，它將繼續(xù)在實現(xiàn)高質(zhì)量嵌入式IP產(chǎn)品方面發(fā)揮重要作用?！?/span>

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

參考鏈接

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