RISC-V验证的独特之处?

半导体工程公司坐下来讨论RISC-V处理器的验证与Pete Hardee，集团主管产品管理节奏；Mike Eftimakis，公司战略和生态系统副总裁Codasip；的创始人兼首席执行官西蒙·大卫曼治之软件；Sven Beyer，处理器验证的程序经理西门子EDA；Kiran Vittal，联盟合作伙伴营销高级总监Synopsys对此；Breker Verification的首席执行官Dave Kelf和Viosoft Corporation的总裁兼CTO Hieu Tran。以下是那次谈话的节选。

SE: RISC-V处理器的验证与其他ASIC有什么不同?

Kelf处理器验证是一个全新的世界。我们知道Arm和英特尔对处理器质量的期望非常高。在RISC-V中，我们必须尝试遵循这一点。首先，有标准的验证类型的活动，确保它工作，确保微架构是健全的，并获得与指令集的兼容性。然后，你必须确保这些设备实际上适合它们将要使用的系统。它们是否适合中断正常工作?系统是相干的吗?处理器和系统其他部分之间的负载存储是否正常工作?它是否足够有效?是否存在瓶颈? All these factors have to be tested in processors that don’t have to be tested in regular blocks or the uncore blocks. This is the big difference. And to try and realize this verification, it’s very complex. Arm has invested something like $150 million. There are a large number of clock cycles required to verify these cores. RISC-V is still building up toward that, and they have a long way to go.

荷迪处理器验证的不同之处在于，我们试图实现的是ISA中的每条指令都给出完全相同的结果，在每种情况下都完全符合程序员手册。处理器验证和ASIC验证之间的最大区别在于，ASIC通常用于更受约束的环境中，用于更明确的目的，而处理器则用于完全不可预见的方式。基本上，处理器必须完全按照程序员的手册操作，无论程序员试图做什么，或者它将进入什么应用程序。这是一个比一般ASIC验证更难的问题。

Eftimakis:要创建一个RISC-V CPU，很多人已经尝试过了，你要么完全鲁莽，要么必须是一个验证专家。一个IP块具有一组已定义的输入和一组已定义的输出。处理器拥有所有可能的程序，这些程序在未来可以被发明出来，并且在过去已经被发明出来。所以这意味着不可能完整，甚至不可能预见所有可能发生的事件组合，再加上随机的中断等等。它需要大量复杂的验证，这是标准IP不需要的，特别是当您知道将在哪种配置中使用它时。

Davidmann这些高端的处理器需要成千上万条指令¹⁵是Arm为验证高端应用程序核心所需的周期数提供的报价。RISC-V将触及这些核心。这是大多数人从未遇到过的事情。他们正在验证UVM的小块，做单元测试，把一个ASIC放在一起，但是他们在这些巨大的处理器上授权，所以很少有人这样做。这在公众面前是一种未知的艺术形式，但RISC-V的挑战将其提升到一个新的水平，因为RISC-V规范中有很多是由实现定义的。在它的特权规范中，你可以采用所有这些不同的方式，它们都是合法的。所以第一个挑战是巨大的，而人们没有这样的经验。第二个挑战是，你可以做出很多选择。这些都是实现选择，它们都是完全合法的，并且都应该得到相同的结果。第三个原因是，RISC-V之所以存在，或者将被接受，是因为它给了你创新和选择新设计的自由。 That means that every processor is likely to be different by design, but yet still has to be compliant. So you have three nightmares, and you have to figure out how you can do this, how you can replicate that amount of verification. We calculated it requires 30 years on an emulator. That’s a huge amount of verification. And then you’ve got all these implementation choices, so everybody can be different, and how do you test that? Another challenge is how do you ensure compliance when you’re extending it? These are three or four real big challenges, for which the world does not have the experience.

Tran:验证处理器核心与ASIC或其他外设的区别是什么?我注意到的一件事是它依赖于上下文。特定指令的行为取决于它之前执行的内容。你不能仅仅通过输入一堆随机指令来验证处理器的行为，并观察它是否以相同的方式执行。从上下文来看，即使在单个处理器中，你也有用户模式和系统模式，你有一系列需要验证的指令，而这些在今天还没有完全完成。当RISC-V成长起来，并开始在Linux等系统上变得更加可行时，你会发现验证挑战变得更加复杂，因为没有足够的机制能够在比RTOS或裸金属操作系统更复杂的环境下彻底审查RISC-V的行为。

Vittal:正如其他人所说，处理器验证具有挑战性。有很多灵活性，并且详尽地验证处理器并不容易。ASIC和处理器之间的主要区别是涉及更多的数据路径。我们都知道著名的英特尔浮点错误。当您有如此多的数据路径时，当您不知道给定环境中该处理器的不同应用程序时(因为您不是在寻找每一个组合)，您就需要一些非常具体的技术、方法、技能和工具的采用等。对于标准ASIC，有不同的ip。您可能有协议和验证ip来帮助验证ASIC的某些部分。但对于处理器，您必须深入研究并验证所有可能的组合。

拜尔处理器验证曾经是这个世界上仅限于武器和英特尔的一门学科。他们有专业知识、方法和计算能力来正确地完成这项工作。现在，有了免费的RISC-V，本质上每个人都在试图重播这个，以充分利用RISC-V的自由。一方面，它有英特尔和Arm同样的复杂性问题，但另一方面，由于自定义的自由，如果你添加自己的自定义寄存器和指令，你就增加了一个全新的复杂性，超出了固定处理器所面临的问题。

SE:我们过去有验证和验证，但似乎我们又加入了第三个，那就是一致性。这些事情之间有什么关系?这些任务之间有多少重叠或分离?

荷迪:我不确定一致性是一个单独的事情，但我们肯定必须同时考虑验证和验证。在RISC-V的世界里，有很多方法来描述我试图创建的处理器。Chisel是其中一种主要的方法。我需要做的是验证我创建的处理器是否满足要求，ISA中包含所需的所有内容，并且ISA是可实现的。然后是验证，即检查ISA的每一部分，ISA的实现，在每种情况下，在每种组合中，包括那些在你开始时无法预见的事情-程序员未来可能对这个东西做的任何事情。所以那些确认和验证的概念已经涵盖了它。我对什么进行验证，我对什么进行验证?这就是ISA的黄金参考模型变得极其重要的地方。基于SAIL及其变体的模型正在出现，它们对正在构建的内容有更完整的形式化定义。诸如此类的事情对于验证非常重要，以确保我涵盖了所有这些可能性。 We’re still at a nascent stage there. Chisel borrowed some concepts from other programming languages, etc. SAIL made an improvement on that in terms of moving toward a golden reference that can be verified against. Look at what Arm and Intel have done in terms of their disciplined approach to describing their ISA, and how that ISA is captured. Arm has presented at the Jasper user groups previously about formally verifying the ISA. Having that golden reference model, that is truly golden, and being able to verify against it with all the methods under the sun. We’ve talked about simulation and emulation, but to find all of the eventualities, formal methods are indispensable. So all of those things have to be used. Compliance always has been a big thing. Intel made a huge deal about compliance to the x86. Same thing with Arm. I’m not sure that compliance is a distinctly different thing. You can cover it with validation and verification, you just got to be a lot more disciplined about it.

Davidmann: Chisel来自伯克利，但工业界并不使用Chisel。很少人——只有几个学者，一两家公司。大多数设计都是在Verilog和SystemVerilog中完成的。为什么呢?这是因为您无法验证无法调试的东西。每个人都可能使用生成器之类的东西来生成它，但所有的设计都是在Verilog或SystemVerilog中完成的。未来将会有更好的语言。我是架构定义语言和Chisel构造硬件的忠实粉丝。这些都很棒，下一代的SystemVerilog将会拥有这些功能。但在它被采用之前，它会有模拟器，调试器等等。 You cannot just have a new language. When we built SystemVerilog 20 years ago, that’s where we started. And it drove us nuts, because you couldn’t debug in the language you wrote in. Chisel still has that problem.

Eftimakis:现在是讨论高级语言的时候了，因为这正是我们开发处理器时所做的。我们有一种方法和工具，不仅可以从高级语言生成RTL，还可以生成软件环境、调试器、编译器等。这样就能确保所有东西都能相互配合。如果你想要使用它，这是必要的。

Tran:如果你看看RISC-V, Chisel可能被视为用于创建RISC-V的主流语言，但还有其他语言，如SpinalHDL, bluspec，除此之外还有其他变体。我们所讨论的是以不同方式使用的不同实现的多样性。请记住，RISC-V还没有被部署为嵌入式系统的主要计算资源。它总是某种微控制器，或者充其量是芯片系统内部的一些附件。

Eftimakis那不是真的。在嵌入式系统中，有很多系统都将RISC-V作为主处理器。