01、RISC-V验证的复杂性
RISC-V处理器因其灵活性和可扩展性而受到广泛关注，但如果没有高效且有效的验证策略，错误的实现可能会导致行业问题。
在 RISC-V 出现之前，处理器验证对于大多数半导体公司来说几乎成为一门失传的艺术。专业知识被浓缩到少数提供处理器或处理器 IP 的商业公司中，并且经常开发自己的内部流程和工具。但开源RISC-V ISA 的出现以及开源实现的激增引起了人们的极大兴趣。
去年，RISC-V International 宣布了多项新的扩展。此外，鼓励用户进行自己的扩展和修改。除此之外，核心的实现方式有很多种，但规范中的细节往往是开放的。然而，虽然开发这些扩展可能是一个相对快速且简单的过程，但验证它们却并不那么容易。
很少有标准或开源工具可以帮助处理器验证。RISC-V 是一种开放的 ISA，任何人都可以使用它并实现处理器。但 RISC-V 市场的领导者知道，仅仅因为他们不需要支付许可费，并不意味着 RISC-V 是便宜的选择。如果你想成功使用 RISC-V，验证就没有捷径。
这远远超出了测试说明的范围。很多人天真地认为验证处理器就是测试指令是否有效。他们构建一个测试生成器或者引入合规性套件来执行此操作，但真正的问题与微架构、管道、异步事件以及所有这些类型的事物有关。关于微架构验证的复杂性，没有标准方法，甚至没有公开讨论。
对于给定 CPU 所需的验证存在一定程度的低估，RISC-V 带来了大量的控制和数据路径复杂性。它提供了广泛的复杂性，这些复杂性可以来自目标应用程序、正在查看的指令集、是否从 32 位过渡到 64 位，或者想要使用哪个核心扩展。
尽管如此，芯片行业仍然可以快速学习。从事 RISC-V 工作的人员都具有传统 CPU 架构背景，可能英特尔、AMD 或 Arm，他们现在正在开发 RISC-V。他们正在重复使用所学到的一切，并应用它来确保你不会重新发明轮子。这就是为什么社区以相对较快的周转速度建立了这个生态系统。
但这并不容易。RISC-V 微架构的验证正处于十字路口，需要平衡开放性和灵活性的优势与多样性和复杂性的挑战。随着生态系统的成熟，解决这些挑战对于将 RISC-V 打造为其他微架构的可靠且安全的替代方案至关重要。通过社区驱动的方法、持续创新和对标准化的关注，RISC-V 的验证环境无疑将不断发展并迎接挑战。
02、验证方法
超越随机
已经开发了许多用于 ASIC 验证的技术。处理器验证与常规 ASIC 验证不同，ASIC 中的 AS 代表特定应用程序。完全验证芯片是否适合其预期应用是有限的。处理器验证不是。处理器指令集架构 (ISA) 中的每个操作都必须经过验证，以便在每种可能情况（每种指令组合）中提供指定的行为。在通用应用中，在验证处理器 IP 时无法预测这一点。
SystemVerilog和UVM是 ASIC 验证的主力。UVM 是生成随机指令的好方法。但它有局限性。例如，覆盖范围。如果你说你对“添加指令”有100%的覆盖率，那么你的覆盖率一定和我有不同的含义，因为不太可能你覆盖了所有可能的组合。另外，向处理器提供典型方法是生成一堆随机指令。也许能够根据要测试的特定区域来调整这些指令，但这是尝试验证处理器的一种非常低效的方法。它会消除一些简单的错误，但你必须提高效率。
确实存在几种指令生成器。如果你考虑一个具有一点定向随机性的机器，你可以指导它测试 32 位加法指令，但存在风险，那么它将需要数十万条指令。测试生成器正在不断发展。任何人都可以在一个下午编写一个简单的随机测试生成器。RISC-V 测试生成领域有大量技术正在不断发展，而且它们正变得越来越复杂。
但问题仍然存在：这足够吗？很多工程师都在进行受限随机操作，这提供了很多价值，根据传统 CPU 提供商的经验以及在 RISC-V 内核中看到的情况，感觉是基于模拟的验证还不够。这就是为什么必须考虑形式验证等替代方法。它可以针对带来大量并发性的控制路径复杂性，以及数据路径复杂性。
自下而上
处理器以自下而上的方式进行验证，类似于当今系统的验证方式。处理器子单元包括分支预测、管道的一部分或任何类型的内存系统（例如缓存），当我们根据某些属性解释被测特定设备应该是什么时，我们可以将这些属性捕获并定义命令词汇表。可以创建一个生成器来创建这些命令的序列。它将一直添加命令到该序列中，直到找到一些相对于黄金参考模型而言会出错的序列。然后，它开始通过删除不影响其生成错误能力的命令来缩小序列。这不仅对于发现错误，而且对于诊断、调试和修复它们都有很大的好处。这对于一大类子单元来说往往非常有效。子单元经过验证后，就可以进行集成。
现在，需要一种更加混合的验证策略。形式化很有用，因为从根本上来说，形式化工具会运用所有可能的输入组合来破坏 ISA 指定的行为，这些行为通常被捕获为 SystemVerilog 断言，主要处理器供应商还拥有广泛的验证套件，包括 UVM 测试平台和测试软件。仿真对于完整验证大型处理器的所有元件以及确保集成到 SoC 中的正确行为是必要的，同时还允许在被测处理器上执行测试软件。
早期为子单元开发的属性仍然可以使用。微架构验证通过两种方式进行，第一种方法当架构验证断言和覆盖在形式验证中失败时，会自动发现错误。架构的 RTL 实现可能会导致架构违规，这些违规很容易被识别为功能错误，甚至是安全错误，或者通过机密性-完整性-可用性三元组的安全问题。通过微架构验证加强严格性的第二种方法是进行大量检查并覆盖所有 RTL 接口，并让形式验证工具跨不同功能设计组件检测故障。这种方法具有增加错误搜寻的附加价值，以及通过组合推理增加收敛性和增加整体覆盖率。
大多数人通过将实现与黄金模型进行比较来验证处理器。有些人认为通过比较指令痕迹就可以认为他们做得很好，但是，当引入异步事件、多问题管道或无序执行等内容时，这种方法就会开始出现真正的问题。另外，该规范并非在每个方面都精确。它没有说明当六个相同优先级的中断同时发生时会发生什么。微架构选择采用哪一种，以及处于流程的哪个阶段？在 RTL、管道和微架构中，有许多实现选择，每个核心的选择都是不同的。
RISC-V 的一大吸引力在于，可以自由地（而且几乎是被鼓励）修改处理器，使其更适合特定应用。挑战在于你投入的每一项内容都会使验证难度加倍。添加东西非常容易，想要以高质量的方式将它们推出市场是非常困难的。很多人没有意识到自定义指令增加的复杂性。他们必须自己完成所有这些验证。对于添加的所有内容，必须完全重新验证所有内容，甚至更多。必须考虑它如何影响设计的其余部分，特别是如果它改变了管道中的内容、ALU 中的冲突、缓存系统问题或加载存储内容。
验证什么时候完成收敛？
验证永远不会完成。普遍接受的方法是，如果做得足够，风险是可控的。
报告告诉你你已经做了一些事情，它给你一定程度的信心，但这并不能告诉你一切。如果使用模拟，可以生成大量覆盖率报告，这些报告将使你有信心说你已经验证了设计的很大一部分，并且覆盖率证明了这一点，并且发现了某些类别的错误。鉴于其复杂性，这种覆盖范围还不够。
但处理器覆盖范围是独一无二的。每个人在谈论报告时都在使用不同的语言，浏览和接触现有的 4.32 亿条指令变体中的每一种都是非常容易的。但那时，它只是说你测试了你的解码器。你没有真正测试任何其他指令序列的组合以及管道可能发生的情况。也许可以通过与设计师坐下来讨论来做得更好。确定他们真正担心的事情，并关注比其他指令更危险的不同组合。
随着 RISC-V 中引入新的自定义指令和矢量扩展等项目，了解微架构决策如何影响整个 SoC 及其上运行的工作负载非常重要，硬件辅助验证，例如虚拟原型功能、仿真和硬件原型设计，是整个验证流程中的关键组成部分。这些技术有助于确保 RISC-V 微架构决策不会对功耗和性能权衡产生负面影响。
当涉及到安全时，就需要更加严格。根据最终产品所需的认证级别，他们必须达到一定程度的故障覆盖率，它要求注入明确定义的故障，这些故障是由 ISO 26262 为功能安全而定义的。你进行故障分析，然后生成诊断覆盖率。如果在设计中关键功能插入这些故障，是否有内置的安全机制来根据这些故障的严重程度来处理这些故障？
RISC-V 的开源特性也使其面临潜在的安全风险。虽然透明度允许社区驱动的审查，但这也意味着对手可以访问相同的信息，这需要强大的安全验证，确保微架构能够抵御不同的攻击媒介。与封闭式架构相比，挑战更加严峻，因为专有设计可以对其安全功能保密。
需要针对处理器验证进行调整来获得更多专用验证工具。当处理器由五家不同的公司设计时，围绕这些处理器不需要太多测试生成器或正式工具，因为它们都是内部构建的，但现在有了 RISC-V，肯定存在一个围绕 RISC-V ISA 进行架构分析、验证、形式化等方面的市场。我们搭建了RISC-V DV环境进行验证。随着时间的推移，我们会看到人们为性能分析工具和正式工具这样做，但现在还处于早期阶段。
本文转自：知芯有道，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
