RISC-V設計在兼容的情況下能走多遠?

答案並不總是黑白分明的，因為(wei) RISC-V的概念與(yu) 以前的開源項目非常不同。但是，隨著對RISC-V的興(xing) 趣和活動的持續增長，正在進行建設性的討論，以解決(jue) 設計開放標準ISA的一些挑戰。

RISC-V國際的首席技術官Mark Himelstein說:“RISC-V標準是實現兼容的。“然而，我們(men) 通常不會(hui) 使用‘兼容’這個(ge) 詞，因為(wei) 最終目標是讓應用程序在與(yu) Profile兼容的實現之間運行。遵從(cong) 是達成兼容的一種手段。”

縮小這兩(liang) 種定義(yi) 範圍的問題之一是曆史背景。與(yu) 某些開放處理器項目(如OpenSPARC)不同，它不涉及源代碼。OpenSPARC提供了對Sun微係統處理器的RTL描述的訪問，而不是提供像RISC-V這樣的ISA。

Codasip高級技術營銷總監Roddy Urquhart表示:“RISC- v與(yu) 早期的RISC指令集的不同之處在於(yu) 它是模塊化的。RISC-V要求使用RV32I或RV64I等基本整數指令集，並批準了各種可選的標準擴展。它還為(wei) 自定義(yi) 指令定義(yi) 了指令編碼空間。為(wei) 了符合ISA，一個(ge) 必要條件是使用適當的基本整數集，但如果使用標準擴展和/或自定義(yi) 擴展的組合，則ISA符合RISC-V。”

盡管如此，這個(ge) 謎題還有很多碎片，對於(yu) 如何定義(yi) 它還有很大的回旋餘(yu) 地。

“要符合RISC-V標準，你實際上隻需要實現非常小的指令子集，”Synopsys的傑出架構師Rob Aitken說。然後你可以說你的設計是risc - v兼容的，因為(wei) 它實現了最小整數指令集。它背後的整個(ge) 想法是一個(ge) 加速器可以被固定到係統中，然後你可以有任何操作碼，等等，你想要的加速器，它可以與(yu) RISC-V最小指令塊共存於(yu) 指令集空間中。所有這些在哲學上都被允許作為(wei) 標準的一部分。因此，實際上，“兼容”隻意味著我實現了我說我實現的RISC-V片段，而我所做的任何其他事情都在定義(yi) 的可擴展性框架內(nei) ，而且它就是這樣。這與(yu) 之前的isa完全不同，在之前的isa中，即使有任何可擴展性，也非常有限。”

Arm的執行副總裁兼首席架構師Richard Grisenthwaite解釋說:“遵從(cong) 性是二元的:要麽(me) 100%遵從(cong) ，要麽(me) 不遵從(cong) 。如果您想要運行的軟件依賴於(yu) 您沒有構建的指令，那麽(me) 它將無法在您的硬件上運行。如果你想讓在你的設備上運行的軟件成為(wei) 廣泛使用的生態係統的一部分，那麽(me) 使用在其他硬件上不可用的指令是沒有意義(yi) 的——這可能會(hui) 在鼓勵軟件作者編寫(xie) 不可移植的軟件時產(chan) 生問題。這就是為(wei) 什麽(me) Arm和許多其他ISA提供商(包括開源廠商)正在使用一係列名稱擴展來有效地標準化架構的原因。如果您遵循這些擴展和規範，那麽(me) 遵從(cong) 性就不是問題，但這並不能讓您獲得開源所期望的靈活性。”

理解開放標準isa設計環境中的遵從(cong) 性仍然具有挑戰性。

的首席執行官西蒙·大衛曼(Simon Davidmann)表示:“要正確地完成這項工作，需要大量的資源。”“合規關(guan) 乎控製。如果您希望與(yu) 定義(yi) 兼容，則必須有人提供演示和執行遵從(cong) 性的能力。像Arm這樣的公司所做的就是用很多不同的方式控製它，就像過去所有isa所做的那樣。他們(men) 說，‘這是我們(men) 的定義(yi) 。你不能把它從(cong) 這個(ge) 信封裏拿出來。“在Arm上，你不能添加指令，不能改變解碼，不能添加寄存器，因為(wei) 如果你做了任何一件事，它就不是‘Arm’，他們(men) 給你的許可不允許你這樣做。”即使是穀歌、三星和其他架構授權方，在法律上也不允許阻止它成為(wei) Arm。”

然而，Arm允許架構許可方稍微改變RTL，但不允許更改源代碼。大衛曼說:“你可以在管道中增加一個(ge) 額外的階段，或者你可以以不同的方式實現它，蘋果在M1和M2中就是這樣做的。”“但他們(men) 怎麽(me) 能證明它仍然是一隻手臂呢?”它如何與(yu) Arm兼容?Arm提供了重要的技術，這取決(jue) 於(yu) 你授權的是什麽(me) ，以及你被允許在多大程度上擺弄它。例如，某人隻是授權一個(ge) 小的內(nei) 核，不允許改變它，他隻會(hui) 得到一些非常簡單的兼容性測試來檢查它，因為(wei) 他們(men) 不允許做任何事情來改變它。他們(men) 不能真正改變勞教製度，所以沒什麽(me) 可做的。他們(men) 可以合成它，他們(men) 可以針對不同的東(dong) 西，得到不同的門，但他們(men) 不允許改變RTL，而像蘋果、穀歌、三星或聯發科這樣的Arm架構授權商可以改變管道階段。他們(men) 可以做自己喜歡的事情，實際上，有些人可以從(cong) 頭開始。他們(men) 可以說，‘我們(men) 會(hui) 接受你的文件，然後按照我們(men) 喜歡的方式構建它。我們(men) 如何證明它是兼容的?對於(yu) 架構許可方來說，作為(wei) 他們(men) 數百萬(wan) 美元的一部分，他們(men) 獲得了大量的兼容性技術，包括參考、測試和框架。然後他們(men) 可以檢查一下，看看它是不是還是一隻胳膊，然後他們(men) 必須把它修好。”

此外，雖然嵌入式處理器的用戶經常從(cong) 源代碼編譯他們(men) 的軟件，但在其上運行的豐(feng) 富操作係統和應用程序是以二進製文件的形式交付的。

Urquhart指出，這需要基本整數集和可選標準擴展的組合保持一致。RISC-V International通過定義(yi) RVA22U64等配置文件對其進行了標準化，這些配置文件指定了標準擴展的強製組合。因此，在某些上下文中，除了遵守ISA之外，還要遵守概要文件是很重要的。例如，如果設計是作為(wei) RTL實現的，它可以根據指令精確的模型進行驗證嗎?這將要求模型包括基本整數指令、選定的標準擴展和自定義(yi) 指令。”

例如，Codasip Studio可以生成一個(ge) UVM環境來執行此操作。但是從(cong) 這個(ge) 角度來看，法規遵循過程對設計或設計過程有影響。

根據RISC-V International的Himelstein的說法，今年批準了第一個(ge) “配置文件”，其中包含由指令狀態和行為(wei) 組成的一代擴展，這些擴展可以一起工作。擴展要麽(me) 是強製性的，要麽(me) 是可選的。選擇與(yu) 概要文件兼容的實現必須實現所有必需的擴展。配置文件為(wei) 整個(ge) 社區的操作係統和工具鏈提供了一個(ge) 單一的目標。”

如果存在不合規問題，供應商將發布勘誤表和恢複計劃。Himelstein說:“如果這是故意的，允許自定義(yi) 更改，那麽(me) 供應商就不能將他們(men) 的產(chan) 品標榜為(wei) RISC-V profile兼容。”

每個(ge) 架構都有這個(ge) 問題。Himelstein指出:“我們(men) 有一套基本的測試，可以通過模擬器進行驗證，得出最佳結果。”“但這取決(jue) 於(yu) 供應商證明他們(men) 已經做了足夠的DV、係統測試、軟件測試等。我們(men) 不是認證機構。需要有一個(ge) 可行的軟件經濟來驅動每個(ge) 人都與(yu) 概要文件兼容，這樣軟件供應商就可以為(wei) 每個(ge) 操作係統類型提供一個(ge) 跨多種實現的版本。我們(men) 是一個(ge) 社區，這個(ge) 社區是一個(ge) 不斷改進的組織。我們(men) 一直在努力改進模擬器和測試。”

碎片化風險

在軟件領域，碎片化一直是一個(ge) 令人擔憂的問題。雖然開放硬件標準不一定需要開源編譯器的支持，但LLVM社區和GCC社區都在努力支持RISC-V，並且偏離硬件標準會(hui) 對開源實現產(chan) 生影響。

西門子數字工業(ye) 軟件公司軟件工程總監Catherine Moore解釋說:“在RISC-V領域，花了很長時間才獲得批準的部分標準是RISC-V標準的矢量擴展。“許多硬件供應商在該標準被批準之前確實需要該擴展，所以許多硬件供應商離開並實現了他們(men) 認為(wei) 的標準，並實現了他們(men) 自己的標準版本，等等。所以現在這些東(dong) 西被硬編碼到他們(men) 的標準版本中，這偏離了最終批準的標準。因此，他們(men) 不得不開發編譯工具來支持他們(men) 的標準衍生產(chan) 品，當然，我們(men) 看到的是碎片化。”

這反過來又為(wei) 那些為(wei) 開源編譯器工具提供定製軟件服務的組織創造了機會(hui) 。

摩爾說:“當這些硬件標準變得支離破碎時，這是一個(ge) 巨大的支持機會(hui) ，因為(wei) 大多數構建開源組件的人都希望將這些組件提交並接受到他們(men) 正在構建的開源社區中。”“但是，例如，GCC將不接受任何偏離標準的提交，因此在RISC-V中一次性實現矢量擴展的供應商需要在GCC或LLVM提供的社區支持之外支持它。”

碎片化的後果是顯著的，其結果是支持它的成本將更高，因為(wei) 在設計中實現不同的標準部分是在社區之外的。

即便如此，RISC-V也允許自定義(yi) 指令集。“RISC-V標準有一個(ge) 擴展，允許供應商創建自己的定製指令，”Moore說。“碎片化與(yu) 此是分開的，因為(wei) 有一個(ge) 如何創建單獨指令的標準。有一種編碼將事物標記為(wei) 獨立和專(zhuan) 有的。這些東(dong) 西應該被視為(wei) 本標準的一部分。實現與(yu) 標準批準方式不同的擴展是你遇到麻煩的地方，至少在軟件世界是這樣。”

敲響警鍾

為(wei) 了使RISC-V設計與(yu) 另一個(ge) ISA兼容，需要進行大量的驗證兼容性測試。

Imperas的Davidmann表示:“RISC-V並不像Arm那樣提倡合規。“他們(men) 沒有資源來提供兼容性測試。他們(men) 所做的是自願工作，創建開放社區測試，基本上是非常簡單的兼容性。我認為(wei) 目前還沒有非常好的兼容性套件。在我們(men) 的第一次工作中，當我們(men) 的模型和參考模擬器在兼容性組中時，我們(men) 創建了一些測試，並創建了一個(ge) 參考來嚐試幫助解決(jue) 這個(ge) 問題，但是沒有可用的資源。在商業(ye) 公司中，你不得不認為(wei) 英特爾從(cong) 芯片中賺了一大筆錢，所以它可以在驗證兼容性方麵投入大量資金。Arm通過授權內(nei) 核賺了很多錢，所以這些核心有巨大的收入來源，他們(men) 所做的就是投資於(yu) 他們(men) 的生態係統，很多都是在兼容性方麵。RISC-V生態係統沒有資金。每個(ge) 人都是獨立的個(ge) 體(ti) 。他們(men) 在兼容性中所做的是，“這裏有一些簡單的測試，你必須運行它們(men) 。”當您運行完後，將您的數據發送給我們(men) ，我們(men) 將允許您使用RISC-V兼容的徽章。’但這不是一個(ge) 商業(ye) 上合理的保險政策。”

此外，遵守是核查的必要但不充分的組成部分。

Codasip的Urquhart說:“微架構設計可能有各種與(yu) ISA或配置文件遵從(cong) 性無關(guan) 的錯誤。”例如，可能存在競爭(zheng) 條件或中斷或緩存接口問題。考慮到處理器設計具有非常大的狀態空間，RTL的驗證要比硬連接加速器塊複雜得多。通常，我們(men) 會(hui) 結合多種方法來發現漏洞，包括直接測試、約束隨機方法和正式驗證。”

的艾特肯也認為(wei) ，合規測試很棘手。“無論是開放的ISA還是封閉的ISA，都是如此。實際上，可定製或可擴展對象的遵從(cong) 性變得更具挑戰性。你這麽(me) 說是什麽(me) 意思?如果你在Arm或x86中有一個(ge) 非法的操作碼，它隻會(hui) 說，'非法指令'，就這樣。但是在RISC-V設計中，取決(jue) 於(yu) 操作碼是什麽(me) ，它實際上可能是非法的操作碼。可能是別人加進去的。他們(men) 一定要告訴別人嗎?這個(ge) 領域可能存在許多灰色地帶，因為(wei) 它可能非常混亂(luan) ，所以人們(men) 通過選擇定義(yi) 良好的子集來回避整個(ge) 問題。”

與(yu) 可擴展ISA相比，固定ISA的遵從(cong) 性和驗證之間的區別稍微清晰一些。“這個(ge) 東(dong) 西能執行它應該執行的指令嗎?”這個(ge) 問題很容易回答。”艾特肯說。“它有它聲稱的其他功能嗎?”它是否以一種合規的方式做到了這一點?在它結束的地方和某種實現錯誤開始的地方之間有一個(ge) 灰色地帶，部分原因是ISA與(yu) 體(ti) 係結構或微體(ti) 係結構與(yu) 該微體(ti) 係結構的特定實現之間的區別。如果隻有一個(ge) ，問題出在哪裏?作為(wei) 一個(ge) 用戶，你可能不知道。即使作為(wei) 一款產(chan) 品的開發者，你也可能無法確定你的問題在這個(ge) 連續體(ti) 的哪個(ge) 部分。如果它在“這裏”，而我們(men) 對規範的解釋是錯誤的，那麽(me) 這就是一個(ge) 合規問題。如果我們(men) 正確地解釋了規範，但我們(men) 錯誤地實現了它，這可能是架構錯誤，微架構錯誤或實現錯誤，這取決(jue) 於(yu) 你到底做了什麽(me) ，因為(wei) 你錯誤地實現了它。”

開發者如何確定?“你不知道，”他說。“你隻知道，最終你必須找出問題所在，並加以解決(jue) 。但是準確的描述是什麽(me) 被破壞了，以及我們(men) 是如何描述它的，並不一定清楚。因此，這將歸結為(wei) 務實的觀點，即‘以前行不通，現在可以了。打勾。“為(wei) 什麽(me) 以前沒有成功?”嗯，這很複雜。”

警示語

大衛曼說，歸根結底，RISC-V中的兼容性測試並不是驗證，這意味著當它們(men) 完成時，它們(men) 可能隻覆蓋了規範中實際功能的10%或20%。“RISC-V真正陷入麻煩的地方在於(yu) ，客戶可以在實現上做出太多選擇，以至於(yu) 實際上很難編寫(xie) 適用於(yu) 所有這些不同設計的測試。對於(yu) 一個(ge) 試圖構建由軟件定義(yi) 的芯片的行業(ye) 來說，他們(men) 在RISC-V上給予的自由是非常棒的，但這種自由意味著它在兼容性方麵是一個(ge) 完全的噩夢。RISC-V行業(ye) 還沒有真正理解這種兼容性挑戰的複雜性，他們(men) 絕對沒有投入資源。”

的Grisenthwaite補充說:“合規性確實是驗證的一部分，但重要的是要有精確而全麵的規範，說明需要構建什麽(me) 才能符合要求。當涉及到個(ge) 人指令時，這是直截了當的;對於(yu) 其他項目，它更複雜，如果軟件依賴於(yu) 所涉及的行為(wei) ，那麽(me) 細微的不遵守可能與(yu) 明顯的失敗一樣是一個(ge) 大問題。重要的是要記住，遵從(cong) 性是驗證的一個(ge) 子集，它涉及到更密切地查找特定於(yu) 特定實現的問題，包括性能異常。驗證顯然是設計過程的核心——通常是最耗時的部分——並且驗證方法變得值得信賴和有彈性，因為(wei) 它已經在廣泛的用戶生態係統中部署了數百萬(wan) 種設計。”

可擴展的體(ti) 係結構使其更加困難。

“如果你想要一個(ge) 可擴展的ISA，那就變得更具挑戰性了，”Davidmann總結道。“有一家公司有資金來投資這個(ge) 項目。社區投資對業(ye) 餘(yu) 愛好者不起作用。當Arm在Linux上遇到問題時，他們(men) 成立了Linaro，這是每年3000萬(wan) 到4000萬(wan) 美元的投資。這不可能是愛好俱樂(le) 部。必須有全職的工程師。對於(yu) RISC-V，您可能應該有一個(ge) 20人的全職團隊來構建兼容性技術。它包括引用、驗證能力和測試。所有這一切的影響是，如果您要授權一個(ge) 處理器，您需要知道兩(liang) 件事。它是否符合標準，所以一切都能正常工作?還有別的蟲子在裏麵嗎?這些是每個(ge) IP供應商都會(hui) 被他們(men) 的客戶問到的問題，而RISC-V國際公司今天並不關(guan) 心應該關(guan) 注的合規性問題。他們(men) 說這是書(shu) 麵的。他們(men) 的行為(wei) 並不表明他們(men) 對此感到擔憂。”