淺談RISC-V微架構(gòu)驗(yàn)證方式

對(duì)于RISC-V 處理器因其靈活性和可擴(kuò)展性而受到廣泛關(guān)注，但如果沒(méi)有高效驗(yàn)證策略，錯(cuò)誤的設(shè)計(jì)實(shí)現(xiàn)可能會(huì)影響RISC-V的繼續(xù)推廣。

在RISC-V出現(xiàn)之前，對(duì)于大多數(shù)半導(dǎo)體公司來(lái)說(shuō)，處理器驗(yàn)證幾乎成為一門屠龍之技。專業(yè)知識(shí)被濃縮到少數(shù)幾家提供處理器或處理器 IP 的商業(yè)公司中，并且經(jīng)常開(kāi)發(fā)自己的內(nèi)部流程和工具。但是，開(kāi)源 RISC-V ISA 的出現(xiàn)以及開(kāi)源實(shí)現(xiàn)的激增引起了人們的極大興趣，并且需要適當(dāng)?shù)墓ぞ吆蛯I(yè)知識(shí)。

在過(guò)去的一年里，RISC-V International宣布了幾項(xiàng)新的擴(kuò)展。此外，鼓勵(lì)用戶進(jìn)行自己的擴(kuò)展和修改。雖然開(kāi)發(fā)這些擴(kuò)展可能是一個(gè)相對(duì)快速和簡(jiǎn)單的過(guò)程，但驗(yàn)證它們并不容易。

很少有標(biāo)準(zhǔn)或開(kāi)源工具可以幫助處理器驗(yàn)證。RISC-V 是一個(gè)開(kāi)放的 ISA，任何人都可以接受它并實(shí)現(xiàn)處理器。但RISC-V市場(chǎng)的領(lǐng)導(dǎo)者知道，僅僅因?yàn)樗麄儾恍枰Ц对S可使用費(fèi)，并不意味著RISC-V是便宜的選擇。

如果你想在RISC-V上取得成功，驗(yàn)證是沒(méi)有捷徑的。

很多人天真地認(rèn)為驗(yàn)證處理器就是測(cè)試指令是否有效。他們?nèi)?gòu)建一個(gè)測(cè)試生成器，做這個(gè)，做那個(gè)，或者引入一個(gè)驗(yàn)證套件，但真正的問(wèn)題與微架構(gòu)、pipeline有關(guān)。對(duì)于微架構(gòu)驗(yàn)證的復(fù)雜性，沒(méi)有標(biāo)準(zhǔn)的方法，甚至沒(méi)有公開(kāi)討論。

對(duì)于給定的 RISC-V?CPU，驗(yàn)證容易被低估。RISC-V帶來(lái)了大量的控制和數(shù)據(jù)路徑復(fù)雜性。包括預(yù)測(cè)執(zhí)行、亂序執(zhí)行等等為更具挑戰(zhàn)性的工作負(fù)載提供更高性能的常用技術(shù)，這些技術(shù)是RISV-V成為服務(wù)器級(jí)設(shè)備中被采用CPU的必備技術(shù)。但這些技術(shù)也會(huì)導(dǎo)致可以利用的安全漏洞，例如 Spectre 和 Meltdown。

RISC-V的開(kāi)發(fā)人員很多來(lái)自傳統(tǒng)的CPU架構(gòu)背景，他們正在重用所學(xué)到的任何東西。但這仍然不容易，RISC-V和傳統(tǒng)的CPU有一些生態(tài)上的區(qū)別。

RISC-V微架構(gòu)的驗(yàn)證正處于一個(gè)十字路口，既要平衡開(kāi)放性和靈活性的優(yōu)勢(shì)，又要應(yīng)對(duì)多樣性和復(fù)雜性的挑戰(zhàn)。隨著生態(tài)系統(tǒng)的成熟，應(yīng)對(duì)這些挑戰(zhàn)對(duì)于將RISC-V確立為其他微架構(gòu)（ARM、X86）的可靠和安全替代方案至關(guān)重要。

通過(guò)社區(qū)驅(qū)動(dòng)的方法、持續(xù)的創(chuàng)新和對(duì)標(biāo)準(zhǔn)化的關(guān)注，RISC-V的驗(yàn)證環(huán)境無(wú)疑將不斷發(fā)展并迎接挑戰(zhàn)。

不止隨機(jī)

處理器驗(yàn)證不同于常規(guī)的ASIC驗(yàn)證，處理器驗(yàn)證空間更大。ASIC 中的 AS 代表特定應(yīng)用。完全驗(yàn)證芯片的預(yù)期應(yīng)用是有限且有界的。處理器驗(yàn)證不是。處理器指令集架構(gòu) （ISA）中的每個(gè)操作都必須經(jīng)過(guò)驗(yàn)證，以便在每種可能性（每種指令組合）中提供指定的行為，而在驗(yàn)證處理器 IP 時(shí)無(wú)法預(yù)測(cè)這一點(diǎn)。

SystemVerilog 和 UVM 是 ASIC 驗(yàn)證的主力軍。UVM 是進(jìn)行隨機(jī)指令生成的好方法，但它有局限性。例如，覆蓋率。如果你說(shuō)你對(duì)“add指令”有 100% 的覆蓋率，你一定有與我不同的覆蓋率含義，因?yàn)槲也幌嘈拍愫w了所有可能的組合。此外，向處理器提供激勵(lì)的典型方法是生成一堆隨機(jī)指令。你也許能夠根據(jù)要測(cè)試的特定區(qū)域來(lái)調(diào)整這些指令，但這是嘗試驗(yàn)證處理器的一種非常低效的方法。它會(huì)發(fā)現(xiàn)一些簡(jiǎn)單的錯(cuò)誤，但你必須繼續(xù)提高驗(yàn)證效率。

很多客戶都在做受約束的隨機(jī)，事實(shí)上確實(shí)存在幾個(gè)指令生成器，可以定向隨機(jī)地為你生成數(shù)十萬(wàn)條指令。但這夠了嗎？

根據(jù)傳統(tǒng)CPU供應(yīng)商的經(jīng)驗(yàn)，以及在RISC-V內(nèi)核中看到的情況，基于仿真的驗(yàn)證是不夠的。這就是為什么你必須考慮其他方法，比如Formal驗(yàn)證。

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

使用Formal驗(yàn)證處理器子模塊

驗(yàn)證子單元后，可以集成它們?？梢韵胂笤趩?dòng) Linux 時(shí)發(fā)現(xiàn) ALU 錯(cuò)誤是一種什么樣的體驗(yàn)。

現(xiàn)在，需要一種更加混合的驗(yàn)證策略。Formal驗(yàn)證是有用的，因?yàn)閺母旧险f(shuō)，F(xiàn)ormal驗(yàn)證會(huì)執(zhí)行所有可能的輸入組合來(lái)驗(yàn)證ISA指定的行為，這些行為通常被描述為SystemVerilog斷言。主要的處理器供應(yīng)商還擁有廣泛的驗(yàn)證套件，包括UVM測(cè)試平臺(tái)和測(cè)試軟件。仿真對(duì)于全面驗(yàn)證大型處理器的所有模塊更是必要的，并確保將正確的行為集成到 SoC 中，同時(shí)還允許在被測(cè)處理器上執(zhí)行測(cè)試軟件。

令人驚訝的是，一個(gè)處理器核心中可以有很多錯(cuò)誤，并且仍然能夠啟動(dòng) Linux。通過(guò)真實(shí)的linux系統(tǒng)啟動(dòng)，你會(huì)發(fā)現(xiàn)各種在其他EDA驗(yàn)證和Formal驗(yàn)證中找不到的東西，比如很多異步時(shí)序。

大多數(shù)人通過(guò)將實(shí)現(xiàn)的功能與參考模型進(jìn)行比較來(lái)驗(yàn)證處理器。規(guī)格并非在各個(gè)方面都精確，它可能沒(méi)有說(shuō)明當(dāng)六個(gè)相同優(yōu)先級(jí)的中斷同時(shí)發(fā)生時(shí)會(huì)發(fā)生什么。微架構(gòu)選擇采用哪一個(gè)，在pipeline的哪個(gè)階段處理，這些選擇因處理器內(nèi)核而異。這個(gè)時(shí)候參考模型可能會(huì)起到意想不到的作用，當(dāng)參考模型和RTL設(shè)計(jì)比對(duì)不通過(guò)時(shí)，你就會(huì)分析設(shè)計(jì)是否合理！

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

你什么時(shí)候完成？
驗(yàn)證永遠(yuǎn)不會(huì)完成。普遍接受的想法是，當(dāng)驗(yàn)證做得足夠時(shí)，風(fēng)險(xiǎn)是可控的。

驗(yàn)證的過(guò)程就是告訴你已經(jīng)做了哪些事情，驗(yàn)證給了你一定程度的信心，但它并不能保證不會(huì)有問(wèn)題。如果你使用仿真，你可以生成大量的覆蓋率報(bào)告，這些報(bào)告會(huì)讓你有信心說(shuō)你已經(jīng)激發(fā)了你的設(shè)計(jì)的大部分，并且覆蓋率證明了這一點(diǎn)，并且你已經(jīng)發(fā)現(xiàn)了某些類別的錯(cuò)誤。

由于處理器驗(yàn)證的復(fù)雜性，這種覆蓋范圍是不夠的。

處理器覆蓋率不僅僅是所有指令以及指令的耦合，此時(shí)你只是關(guān)注處理器中的解碼器。你并沒(méi)有真正測(cè)試其他任何東西，包括指令序列以及pipeline中發(fā)生的情況。

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

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

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

RISC-V的開(kāi)源特性也使其面臨潛在的安全風(fēng)險(xiǎn)。雖然透明度允許社區(qū)驅(qū)動(dòng)的審查，但這也意味著對(duì)手可以訪問(wèn)相同的信息。這需要強(qiáng)大的安全驗(yàn)證，確保微架構(gòu)能夠抵御各種攻擊。與封閉式架構(gòu)相比，RISC-V的安全挑戰(zhàn)更加嚴(yán)峻，專有設(shè)計(jì)可以對(duì)其安全功能保密。

RISC-V需要更多專用的驗(yàn)證工具。當(dāng)處理器由五家不同的公司設(shè)計(jì)時(shí)，對(duì)這些處理器的測(cè)試生成器或Formal工具的需求并不大，因?yàn)樗鼈兌际窃诟鱾€(gè)公司內(nèi)部構(gòu)建的。但現(xiàn)在有了RISC-V，圍繞RISC-V ISA的架構(gòu)分析、驗(yàn)證、Formal肯定有一個(gè)市場(chǎng)。

隨著時(shí)間的推移，我們會(huì)看到人們?yōu)镽ISC-V的性能分析工具和Formal工具，但現(xiàn)在還為時(shí)過(guò)早。

下圖列出了驗(yàn)證處理器微架構(gòu)時(shí)可以考慮的方法。