RISC-V設計在兼容的情況下能走多遠?
答案并不總是黑白分明的，因為RISC-V的概念與以前的開源項目非常不同。但是，隨著對RISC-V的興趣和活動的持續增長，正在進行建設性的討論，以解決設計開放標準ISA的一些挑戰。
RISC-V國際的首席技術官Mark Himelstein說:“RISC-V標準是實現兼容的。“然而，我們通常不會使用‘兼容’這個詞，因為最終目標是讓應用程序在與Profile兼容的實現之間運行。遵從是達成兼容的一種手段。”
縮小這兩種定義范圍的問題之一是歷史背景。與某些開放處理器項目(如OpenSPARC)不同，它不涉及源代碼。OpenSPARC提供了對Sun微系統處理器的RTL描述的訪問，而不是提供像RISC-V這樣的ISA。
Codasip高級技術營銷總監Roddy Urquhart表示:“RISC- v與早期的RISC指令集的不同之處在于它是模塊化的。RISC-V要求使用RV32I或RV64I等基本整數指令集，并批準了各種可選的標準擴展。它還為自定義指令定義了指令編碼空間。為了符合ISA，一個必要條件是使用適當的基本整數集，但如果使用標準擴展和/或自定義擴展的組合，則ISA符合RISC-V。”
盡管如此，這個謎題還有很多碎片，對于如何定義它還有很大的回旋余地。
“要符合RISC-V標準，你實際上只需要實現非常小的指令子集，”Synopsys的杰出架構師Rob Aitken說。然后你可以說你的設計是risc - v兼容的，因為它實現了最小整數指令集。它背后的整個想法是一個加速器可以被固定到系統中，然后你可以有任何操作碼，等等，你想要的加速器，它可以與RISC-V最小指令塊共存于指令集空間中。所有這些在哲學上都被允許作為標準的一部分。因此，實際上，“兼容”只意味著我實現了我說我實現的RISC-V片段，而我所做的任何其他事情都在定義的可擴展性框架內，而且它就是這樣。這與之前的isa完全不同，在之前的isa中，即使有任何可擴展性，也非常有限。”
Arm的執行副總裁兼首席架構師Richard Grisenthwaite解釋說:“遵從性是二元的:要么100%遵從，要么不遵從。如果您想要運行的軟件依賴于您沒有構建的指令，那么它將無法在您的硬件上運行。如果你想讓在你的設備上運行的軟件成為廣泛使用的生態系統的一部分，那么使用在其他硬件上不可用的指令是沒有意義的——這可能會在鼓勵軟件作者編寫不可移植的軟件時產生問題。這就是為什么Arm和許多其他ISA提供商(包括開源廠商)正在使用一系列名稱擴展來有效地標準化架構的原因。如果您遵循這些擴展和規范，那么遵從性就不是問題，但這并不能讓您獲得開源所期望的靈活性。”
理解開放標準isa設計環境中的遵從性仍然具有挑戰性。
的首席執行官西蒙·大衛曼(Simon Davidmann)表示:“要正確地完成這項工作，需要大量的資源。”“合規關乎控制。如果您希望與定義兼容，則必須有人提供演示和執行遵從性的能力。像Arm這樣的公司所做的就是用很多不同的方式控制它，就像過去所有isa所做的那樣。他們說，‘這是我們的定義。你不能把它從這個信封里拿出來。“在Arm上，你不能添加指令，不能改變解碼，不能添加寄存器，因為如果你做了任何一件事，它就不是‘Arm’，他們給你的許可不允許你這樣做。”即使是谷歌、三星和其他架構授權方，在法律上也不允許阻止它成為Arm。”
然而，Arm允許架構許可方稍微改變RTL，但不允許更改源代碼。大衛曼說:“你可以在管道中增加一個額外的階段，或者你可以以不同的方式實現它，蘋果在M1和M2中就是這樣做的。”“但他們怎么能證明它仍然是一只手臂呢?”它如何與Arm兼容?Arm提供了重要的技術，這取決于你授權的是什么，以及你被允許在多大程度上擺弄它。例如，某人只是授權一個小的內核，不允許改變它，他只會得到一些非常簡單的兼容性測試來檢查它，因為他們不允許做任何事情來改變它。他們不能真正改變勞教制度，所以沒什么可做的。他們可以合成它，他們可以針對不同的東西，得到不同的門，但他們不允許改變RTL，而像蘋果、谷歌、三星或聯發科這樣的Arm架構授權商可以改變管道階段。他們可以做自己喜歡的事情，實際上，有些人可以從頭開始。他們可以說，‘我們會接受你的文件，然后按照我們喜歡的方式構建它。我們如何證明它是兼容的?對于架構許可方來說，作為他們數百萬美元的一部分，他們獲得了大量的兼容性技術，包括參考、測試和框架。然后他們可以檢查一下，看看它是不是還是一只胳膊，然后他們必須把它修好。”
此外，雖然嵌入式處理器的用戶經常從源代碼編譯他們的軟件，但在其上運行的豐富操作系統和應用程序是以二進制文件的形式交付的。
Urquhart指出，這需要基本整數集和可選標準擴展的組合保持一致。RISC-V International通過定義RVA22U64等配置文件對其進行了標準化，這些配置文件指定了標準擴展的強制組合。因此，在某些上下文中，除了遵守ISA之外，還要遵守概要文件是很重要的。例如，如果設計是作為RTL實現的，它可以根據指令精確的模型進行驗證嗎?這將要求模型包括基本整數指令、選定的標準擴展和自定義指令。”
例如，Codasip Studio可以生成一個UVM環境來執行此操作。但是從這個角度來看，法規遵循過程對設計或設計過程有影響。
根據RISC-V International的Himelstein的說法，今年批準了第一個“配置文件”，其中包含由指令狀態和行為組成的一代擴展，這些擴展可以一起工作。擴展要么是強制性的，要么是可選的。選擇與概要文件兼容的實現必須實現所有必需的擴展。配置文件為整個社區的操作系統和工具鏈提供了一個單一的目標。”
如果存在不合規問題，供應商將發布勘誤表和恢復計劃。Himelstein說:“如果這是故意的，允許自定義更改，那么供應商就不能將他們的產品標榜為RISC-V profile兼容。”
每個架構都有這個問題。Himelstein指出:“我們有一套基本的測試，可以通過模擬器進行驗證，得出最佳結果。”“但這取決于供應商證明他們已經做了足夠的DV、系統測試、軟件測試等。我們不是認證機構。需要有一個可行的軟件經濟來驅動每個人都與概要文件兼容，這樣軟件供應商就可以為每個操作系統類型提供一個跨多種實現的版本。我們是一個社區，這個社區是一個不斷改進的組織。我們一直在努力改進模擬器和測試。”
碎片化風險
在軟件領域，碎片化一直是一個令人擔憂的問題。雖然開放硬件標準不一定需要開源編譯器的支持，但LLVM社區和GCC社區都在努力支持RISC-V，并且偏離硬件標準會對開源實現產生影響。
西門子數字工業軟件公司軟件工程總監Catherine Moore解釋說:“在RISC-V領域，花了很長時間才獲得批準的部分標準是RISC-V標準的矢量擴展。“許多硬件供應商在該標準被批準之前確實需要該擴展，所以許多硬件供應商離開并實現了他們認為的標準，并實現了他們自己的標準版本，等等。所以現在這些東西被硬編碼到他們的標準版本中，這偏離了最終批準的標準。因此，他們不得不開發編譯工具來支持他們的標準衍生產品，當然，我們看到的是碎片化。”
這反過來又為那些為開源編譯器工具提供定制軟件服務的組織創造了機會。
摩爾說:“當這些硬件標準變得支離破碎時，這是一個巨大的支持機會，因為大多數構建開源組件的人都希望將這些組件提交并接受到他們正在構建的開源社區中。”“但是，例如，GCC將不接受任何偏離標準的提交，因此在RISC-V中一次性實現矢量擴展的供應商需要在GCC或LLVM提供的社區支持之外支持它。”
碎片化的后果是顯著的，其結果是支持它的成本將更高，因為在設計中實現不同的標準部分是在社區之外的。
即便如此，RISC-V也允許自定義指令集。“RISC-V標準有一個擴展，允許供應商創建自己的定制指令，”Moore說。“碎片化與此是分開的，因為有一個如何創建單獨指令的標準。有一種編碼將事物標記為獨立和專有的。這些東西應該被視為本標準的一部分。實現與標準批準方式不同的擴展是你遇到麻煩的地方，至少在軟件世界是這樣。”
敲響警鐘
為了使RISC-V設計與另一個ISA兼容，需要進行大量的驗證兼容性測試。
Imperas的Davidmann表示:“RISC-V并不像Arm那樣提倡合規。“他們沒有資源來提供兼容性測試。他們所做的是自愿工作，創建開放社區測試，基本上是非常簡單的兼容性。我認為目前還沒有非常好的兼容性套件。在我們的第一次工作中，當我們的模型和參考模擬器在兼容性組中時，我們創建了一些測試，并創建了一個參考來嘗試幫助解決這個問題，但是沒有可用的資源。在商業公司中，你不得不認為英特爾從芯片中賺了一大筆錢，所以它可以在驗證兼容性方面投入大量資金。Arm通過授權內核賺了很多錢，所以這些核心有巨大的收入來源，他們所做的就是投資于他們的生態系統，很多都是在兼容性方面。RISC-V生態系統沒有資金。每個人都是獨立的個體。他們在兼容性中所做的是，“這里有一些簡單的測試，你必須運行它們。”當您運行完后，將您的數據發送給我們，我們將允許您使用RISC-V兼容的徽章。’但這不是一個商業上合理的保險政策。”
此外，遵守是核查的必要但不充分的組成部分。
Codasip的Urquhart說:“微架構設計可能有各種與ISA或配置文件遵從性無關的錯誤。”例如，可能存在競爭條件或中斷或緩存接口問題。考慮到處理器設計具有非常大的狀態空間，RTL的驗證要比硬連接加速器塊復雜得多。通常，我們會結合多種方法來發現漏洞，包括直接測試、約束隨機方法和正式驗證。”
的艾特肯也認為，合規測試很棘手。“無論是開放的ISA還是封閉的ISA，都是如此。實際上，可定制或可擴展對象的遵從性變得更具挑戰性。你這么說是什么意思?如果你在Arm或x86中有一個非法的操作碼，它只會說，'非法指令'，就這樣。但是在RISC-V設計中，取決于操作碼是什么，它實際上可能是非法的操作碼。可能是別人加進去的。他們一定要告訴別人嗎?這個領域可能存在許多灰色地帶，因為它可能非常混亂，所以人們通過選擇定義良好的子集來回避整個問題。”
與可擴展ISA相比，固定ISA的遵從性和驗證之間的區別稍微清晰一些。“這個東西能執行它應該執行的指令嗎?”這個問題很容易回答。”艾特肯說。“它有它聲稱的其他功能嗎?”它是否以一種合規的方式做到了這一點?在它結束的地方和某種實現錯誤開始的地方之間有一個灰色地帶，部分原因是ISA與體系結構或微體系結構與該微體系結構的特定實現之間的區別。如果只有一個，問題出在哪里?作為一個用戶，你可能不知道。即使作為一款產品的開發者，你也可能無法確定你的問題在這個連續體的哪個部分。如果它在“這里”，而我們對規范的解釋是錯誤的，那么這就是一個合規問題。如果我們正確地解釋了規范，但我們錯誤地實現了它，這可能是架構錯誤，微架構錯誤或實現錯誤，這取決于你到底做了什么，因為你錯誤地實現了它。”
開發者如何確定?“你不知道，”他說。“你只知道，最終你必須找出問題所在，并加以解決。但是準確的描述是什么被破壞了，以及我們是如何描述它的，并不一定清楚。因此，這將歸結為務實的觀點，即‘以前行不通，現在可以了。打勾。“為什么以前沒有成功?”嗯，這很復雜。”
警示語
大衛曼說，歸根結底，RISC-V中的兼容性測試并不是驗證，這意味著當它們完成時，它們可能只覆蓋了規范中實際功能的10%或20%。“RISC-V真正陷入麻煩的地方在于，客戶可以在實現上做出太多選擇，以至于實際上很難編寫適用于所有這些不同設計的測試。對于一個試圖構建由軟件定義的芯片的行業來說，他們在RISC-V上給予的自由是非常棒的，但這種自由意味著它在兼容性方面是一個完全的噩夢。RISC-V行業還沒有真正理解這種兼容性挑戰的復雜性，他們絕對沒有投入資源。”
的Grisenthwaite補充說:“合規性確實是驗證的一部分，但重要的是要有精確而全面的規范，說明需要構建什么才能符合要求。當涉及到個人指令時，這是直截了當的;對于其他項目，它更復雜，如果軟件依賴于所涉及的行為，那么細微的不遵守可能與明顯的失敗一樣是一個大問題。重要的是要記住，遵從性是驗證的一個子集，它涉及到更密切地查找特定于特定實現的問題，包括性能異常。驗證顯然是設計過程的核心——通常是最耗時的部分——并且驗證方法變得值得信賴和有彈性，因為它已經在廣泛的用戶生態系統中部署了數百萬種設計。”
可擴展的體系結構使其更加困難。
“如果你想要一個可擴展的ISA，那就變得更具挑戰性了，”Davidmann總結道。“有一家公司有資金來投資這個項目。社區投資對業余愛好者不起作用。當Arm在Linux上遇到問題時，他們成立了Linaro，這是每年3000萬到4000萬美元的投資。這不可能是愛好俱樂部。必須有全職的工程師。對于RISC-V，您可能應該有一個20人的全職團隊來構建兼容性技術。它包括引用、驗證能力和測試。所有這一切的影響是，如果您要授權一個處理器，您需要知道兩件事。它是否符合標準，所以一切都能正常工作?還有別的蟲子在里面嗎?這些是每個IP供應商都會被他們的客戶問到的問題，而RISC-V國際公司今天并不關心應該關注的合規性問題。他們說這是書面的。他們的行為并不表明他們對此感到擔憂。”
熱門新聞
Global
