RISC-V架构面临软件可移植性挑战_risc-v|CPU|ARM

文章图片

本文由半导体产业纵横（ID：ICVIEWS）编译自semiengineering
为了实现软件的可移植性，需要一种硬件与软件之间的契约，但RISC-V的定义尚不够明确，以至于我们还不知道这种契约应该是什么。

与会嘉宾

Arteris公司的客户服务副总裁John Min、
Codasip公司的首席技术官Zdeněk P?ikryl、
西门子EDA的市场总监Neil Hand、
Synopsys公司的战略项目与系统解决方案执行总监Frank Schirrmeister、
Axiomise公司的首席执行官Ashish Darbari、
Breker Verification公司的首席执行官Dave Kelf

拥有明确的指令集架构（ISA）、定义好的架构以及完整的规范时，验证处理器就已经很困难了。而 RISC-V 却不具备这些条件。这是否会导致定义一致性变得更加困难？
Hand：RISC-V的优势在于其可定制性，但这也是它的劣势。大多数人没有意识到，当你做出更改时，你几乎已经抛弃了IP供应商的所有验证工作。你必须评估当前的状况。在某些方面，你可以选择特定的架构，但你不必修改处理器。你可以找一个IP供应商，采用他们的处理器，进行验证，然后说：“我将把这个视为标准，并打算在此基础上开发加速器。 ”因为这样做更安全。这是风险与收益的权衡。我想在哪里承担风险，以及我能从中获得什么回报？很多人最初被这种巨大的灵活性所吸引，却没有意识到这种灵活性也带来了巨大的责任，即确保在尝试更改时不会出错。
Min：也许我们应该回到定义上。不同的阶段适合不同的定义。所以，也许一致性是在架构层面上定义的。也许验证或确认是在微架构层面上进行的。这取决于你正在验证、确认或遵循的是哪个规范。
Kelf：Arm有一个处理器架构和建立在其上的指令集，这就是他们正在验证的内容。他们投入了大量的精力来确保它运行得非常好。而RISC-V ，你有一个ISA ，然后有非常多潜在的架构。每个人都想出了各种聪明且不同的方法，这甚至还没有考虑到添加指令。所以，首先，这就是为什么“配置文件”的想法如此强大。现在，你正试图设置一些边界，并将验证问题组织成至少是可以实现的东西。否则，由于它的可变性，几乎是不可能实现的。除此之外，你还需要处理这种可变指令的情况。在RISC-V对此大做文章之前， Arm是不允许这样做的。所以， Arm现在虽然允许使用可变指令，但他们在主架构和可添加指令的小区域之间设置了一道巨大的防火墙。即便如此，他们在验证这方面也遇到了问题。对于来自不同公司的可变架构，以及额外的指令，配置文件在一定程度上有助于解决这个问题。至少我们可以制定一些可以认证的定义。你需要那个“黄金模型” 。但即便如此，这仍然很困难。那么，你如何创建与架构无关、与添加的额外指令无关的深入验证测试，并确保无论谁获得这些处理器，都能绝对依赖它来运行他们的软件栈，而不会出错呢？大多数都会出问题。
Hand：如果你看看RISC-V最初的用例，它确实是为嵌入式系统设计的。他们编写所有的软件，使用定制的编译器。这真的不重要。如果你开始看现在推出的RISC-V系统，无论是单板计算机还是笔记本电脑，你都必须考虑生态系统。这些处理器最好与指令集兼容。这真的取决于你的用例是什么。
P?ikryl：不仅是指令集。这只是故事的一部分。他们根据规范编译配置文件。这是目前缺少的，因为我们确实有这些架构测试。它存在于GitHub上。你可以运行它，但它几乎不会给你任何信息。它只会告诉你， “汇编良好，二进制良好。 ”仅此而已。它不会告诉你，当我从用户模式切换到另一种模式时，是否正确地完成了切换。这就是我认为如果做得正确，认证可能会有所帮助的地方。
Kelf：而这正是社区目前正在努力弄清楚的问题。我们如何才能正确地做到这一点？
Hand：考虑到你所说的，你能正确地做到这一点吗？你有多种架构，取决于配置文件，取决于扩展，你有数十种微架构来实现其中任何一种。对规范的不同解释层出不穷。然后你还需要实现，这可能会在微架构内再次引入不同的东西，而你又进入了物理实现阶段，这为整个事情带来了新的转折。
Min：这是从另一个角度谈论核心内部。但我们是否还需要关注内核外部？哪些总线，甚至是那些可能有未记录小端口的标准总线。当Arm设计一个处理器和网络芯片时，他们可以绕过这个问题，因为他们将其视为一个嵌入式系统。但当我们参与进来时，情况就不同了。
Hand：这就是你开始看到一些混合系统的原因吗？当他们真的需要利用软件生态系统时，他们会选择一个处理器，但当他们真的需要优化和压榨处理器的最后一点性能时，他们会选择RISC-V架构。你的确会看到越来越多的混合系统采用多种处理器架构。也许他们在说，对于这种特殊情况，这是最安全的选择。人们喜欢把它说成是一场生死之战。其实不然。
Lin：这是一个优化选择。
Kelf：但你提出了一个很好的观点。仅仅是处理器吗？现在我们在看整个SoC——甚至可能是中断控制器、内存管理单元，以及处理器周围的所有基本组件。你可以看到它正在慢慢扩展，涵盖了所有这些SoC组件。
验证所有定义为RISC-V的内容是一回事，但它未定义的内容呢？当我们开始谈论硬件/软件契约时，这意味着它们之间共享的一切。为了有一个符合性的概念，你必须知道契约正在被履行。但契约并没有定义。你如何处理这些情况？
Kelf：我们有很多客户都在使用SoC ，他们从其他地方引入了RISC-V 。这些处理器中有很多都有漏洞，要么是对ISA的误解，要么就是完全的漏洞。人们认为，当他们获得一个处理器 IP时，就像获得了一个Arm处理器一样能正常工作，而且非常出色。在很多情况下，处理器IP很糟糕，因为ISA虽然已经做了大量工作，但定义仍不够完善。这确实是个问题。
Hand：这也是使用形式化方法的优势之一，因为要得到答案，就必须有约束条件。约束条件就成了未定义内容的参考。为了让它通过，你必须有约束条件。我们的团队在检测工作核心时，会突然发现所有这些错误。通常是在规范的灰色区域，或者是没有定义的寻址模式。记录下来后你至少有了关于漏洞的文档。你可以使用不同的技术来填补处理器规范中的空白。如果Codasip团队说现在可以保证这种沙盒环境，而且因为这是一个生成的设计，你们不会干扰其他部分，那这就变得非常强大了。现在你们说可以改变某些东西而不会破坏其他东西。这通常是个问题。你只是调整一个寻址模式，却可能会突然引发一堆麻烦。形式化方法可以帮助你识别出这些麻烦，但随后你需要确定这是有意为之还是无意的？
【RISC-V架构面临软件可移植性挑战】P?ikryl：你要花时间确定正确的界限，检查常见的变化，然后我们来创建界限。在这些边界之内，你就很安全。如果确实跨越了这些边界，那么你需要承担所有的验证责任。
Hand：这样做确实有好处，但在享受这些好处的同时，你必须明确：‘我愿意接受的边界是什么？我愿意承担的风险有多大？我是否要将它视为已知良好的IP ，并信任我的供应商提供的IP是可靠的？我是选择信任但验证吗？’我获取供应商的IP ，然后在其上运行合规性测试套件，看看它是否工作正常。还是因为我清楚自己在做什么并且信任自己，所以把它当作是无拘无束的冒险？能力越大，责任也越大。
P?ikryl：说到规范中的漏洞，这在开始时尤其如此。现在比以前好多了。但在开始的时候，我们遇到了很多这样的问题。有时候，我们认为我们已经搞定了，因为我们正确地解释了规范。然后我们和不同的供应商交谈，询问他们对此的看法。你们是怎么理解的？在某些情况下，它是一致的，但在其他情况下则不是。然后我们必须达成一致。
Darbari：在为SoC设计电源控制器时，我发现了大量由处理器实现中的架构问题引起的设计实现问题。这些问题是在使用形式化工具中的预加载固件映像验证电源控制器设计时发现的。这是在验证的早期阶段进行的，因为我们被告知设计已经通过仿真验证，而形式验证只是最后的部分。然而，暴露出的问题意味着整个处理器设计必须重新架构。我可能听起来像个老古董，但正式版不仅可以验证硬件，还可以验证硬件和软件（即固件）的边界。高速缓存子系统也是利用形式化捕捉内存模型相关错误的一个例子，它暴露了微妙的弱内存模型类型错误。
Schirrmeister：这让我想起了你在模拟中遇到的LRM问题，人们至今仍在争论竞态条件和如何解释语言参考手册。在其他处理器架构中，你知道中断发生时会发生什么。事情被存储起来，你有一种方法可以告诉处理器把东西放到栈上并保存所有寄存器。根据我所了解的，在RISC-V中，这一点没有定义。你需要弄清楚硬件软件契约以及中断来临时该做什么。我的处理器会做什么？软件开发者并不关心这些。他们不想考虑这些。他们希望硬件能为他们解决这些问题。运行认证合规性的委员会将为特定的配置文件定义这些事情应该如何操作。
P?ikryl：没错。我们确实有基本规定ISA的配置文件。然后，我们还有一些平台，其中一项任务就是定义一些东西，比如我应该在系统中使用哪种中断控制器。也许你需要一个特定的操作系统。这些活动都是为了确定这些细节。这可以是盖章或认证过程的一部分。你不仅要符合rva23或其他标准，还要遵循平台定义。
Hand：退一步讲， RISC-V已经远远领先于被RISC-V所取代的处理器。看看RISC-V所取代的是什么，那大都是人们自己构建的自定义处理器。过去是一个供应商，一套软件基础设施。那他们的解读是什么？现在你有多个团队，多种解读，相互交叉验证。你如何看待这个问题？随着越来越多的人进入生态系统并对其进行解读，标准正变得更加稳健。参与的人越多，标准就越稳健，对最终用户和最终消费者来说就越可靠。随着生态系统的发展，它也会变得更加强大，这比其他替代方案要好得多。如果有100家不同的处理器供应商，他们都有自己的软件生态系统，都有自己的勘误表，那可能会写满一本教科书。只有在极端情况下，你才会发现问题，比如你的自动驾驶汽车冲下桥去。
Min：RISC-V在过去六七年里取得了长足的进步。我们正在达到可以解决第二个问题——软件工程师或CPU工程师问题的阶段。到目前为止， RISC-V主要由硬件工程师推动，并且以硬件为中心。随着重点转向一致性验证，软件人员将推动这一进程，因为他们只想编写一次软件，就能在多个硬件实例上运行。这种一致性将由软件驱动，而不是硬件或测试。一家公司的网络浏览器能否在另一家公司的Linux计算机上成功运行？这本身就会成为一个验证测试或确认测试。同样，也会有软件驱动的软件基准测试。
*声明：本文系原作者创作。文章内容系其个人观点，我方转载仅为分享与讨论，不代表我方赞成或认同，如有异议，请联系后台。