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设计环境中的遵从性仍然具有挑战性。
Imperas Software的首席执行官西蒙·大卫曼(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的验证要比硬连接加速器块复杂得多。通常，我们会结合多种方法来发现漏洞，包括直接测试、约束随机方法和正式验证。”
Synopsys的艾特肯也认为，合规测试很棘手。“无论是开放的ISA还是封闭的ISA，都是如此。实际上，可定制或可扩展对象的遵从性变得更具挑战性。你这么说是什么意思?如果你在Arm或x86中有一个非法的操作码，它只会说，'非法指令'，就这样。但是在RISC-V设计中，取决于操作码是什么，它实际上可能是非法的操作码。可能是别人加进去的。他们一定要告诉别人吗?这个领域可能存在许多灰色地带，因为它可能非常混乱，所以人们通过选择定义良好的子集来回避整个问题。”
与可扩展ISA相比，固定ISA的遵从性和验证之间的区别稍微清晰一些。“这个东西能执行它应该执行的指令吗?”这个问题很容易回答。”艾特肯说。“它有它声称的其他功能吗?”它是否以一种合规的方式做到了这一点?在它结束的地方和某种实现错误开始的地方之间有一个灰色地带，部分原因是ISA与体系结构或微体系结构与该微体系结构的特定实现之间的区别。如果只有一个，问题出在哪里?作为一个用户，你可能不知道。即使作为一款产品的开发者，你也可能无法确定你的问题在这个连续体的哪个部分。如果它在“这里”，而我们对规范的解释是错误的，那么这就是一个合规问题。如果我们正确地解释了规范，但我们错误地实现了它，这可能是架构错误，微架构错误或实现错误，这取决于你到底做了什么，因为你错误地实现了它。”
开发者如何确定?“你不知道，”他说。“你只知道，最终你必须找出问题所在，并加以解决。但是准确的描述是什么被破坏了，以及我们是如何描述它的，并不一定清楚。因此，这将归结为务实的观点，即‘以前行不通，现在可以了。打勾。“为什么以前没有成功?”嗯，这很复杂。”
警示语
大卫曼说，归根结底，RISC-V中的兼容性测试并不是验证，这意味着当它们完成时，它们可能只覆盖了规范中实际功能的10%或20%。“RISC-V真正陷入麻烦的地方在于，客户可以在实现上做出太多选择，以至于实际上很难编写适用于所有这些不同设计的测试。对于一个试图构建由软件定义的芯片的行业来说，他们在RISC-V上给予的自由是非常棒的，但这种自由意味着它在兼容性方面是一个完全的噩梦。RISC-V行业还没有真正理解这种兼容性挑战的复杂性，他们绝对没有投入资源。”
Arm的Grisenthwaite补充说:“合规性确实是验证的一部分，但重要的是要有精确而全面的规范，说明需要构建什么才能符合要求。当涉及到个人指令时，这是直截了当的;对于其他项目，它更复杂，如果软件依赖于所涉及的行为，那么细微的不遵守可能与明显的失败一样是一个大问题。重要的是要记住，遵从性是验证的一个子集，它涉及到更密切地查找特定于特定实现的问题，包括性能异常。验证显然是设计过程的核心——通常是最耗时的部分——并且验证方法变得值得信赖和有弹性，因为它已经在广泛的用户生态系统中部署了数百万种设计。”
可扩展的体系结构使其更加困难。
“如果你想要一个可扩展的ISA，那就变得更具挑战性了，”Davidmann总结道。“有一家公司有资金来投资这个项目。社区投资对业余爱好者不起作用。当Arm在Linux上遇到问题时，他们成立了Linaro，这是每年3000万到4000万美元的投资。这不可能是爱好俱乐部。必须有全职的工程师。对于RISC-V，您可能应该有一个20人的全职团队来构建兼容性技术。它包括引用、验证能力和测试。所有这一切的影响是，如果您要授权一个处理器，您需要知道两件事。它是否符合标准，所以一切都能正常工作?还有别的虫子在里面吗?这些是每个IP供应商都会被他们的客户问到的问题，而RISC-V国际公司今天并不关心应该关注的合规性问题。他们说这是书面的。他们的行为并不表明他们对此感到担忧。”
Semiconductor Engineering - Deep Insights For Chip Engineers (semiengineering.com)
热门新闻
Global
