对于RISC-V处理器因其灵活性和可扩展性而受到广泛关注，但如果没有高效验证策略，错误的设计实现可能会影响RISC-V的继续推广。

在RISC-V出现之前，对于大多数半导体公司来说，处理器验证几乎成为一门屠龙之技。专业知识被浓缩到少数几家提供处理器或处理器 IP 的商业公司中，并且经常开发自己的内部流程和工具。但是，开源 RISC-V ISA 的出现以及开源实现的激增引起了人们的极大兴趣，并且需要适当的工具和专业知识。

在过去的一年里，RISC-V International宣布了几项新的扩展。此外，鼓励用户进行自己的扩展和修改。虽然开发这些扩展可能是一个相对快速和简单的过程，但验证它们并不容易。

很少有标准或开源工具可以帮助处理器验证。RISC-V 是一个开放的 ISA，任何人都可以接受它并实现处理器。但RISC-V市场的领导者知道，仅仅因为他们不需要支付许可使用费，并不意味着RISC-V是便宜的选择。

如果你想在RISC-V上取得成功，验证是没有捷径的。

很多人天真地认为验证处理器就是测试指令是否有效。他们去构建一个测试生成器，做这个，做那个，或者引入一个验证套件，但真正的问题与微架构、pipeline有关。对于微架构验证的复杂性，没有标准的方法，甚至没有公开讨论。

对于给定的 RISC-V CPU，验证容易被低估。RISC-V带来了大量的控制和数据路径复杂性。包括预测执行、乱序执行等等为更具挑战性的工作负载提供更高性能的常用技术，这些技术是RISV-V成为服务器级设备中被采用CPU的必备技术。但这些技术也会导致可以利用的安全漏洞，例如 Spectre 和 Meltdown。

RISC-V的开发人员很多来自传统的CPU架构背景，他们正在重用所学到的任何东西。但这仍然不容易，RISC-V和传统的CPU有一些生态上的区别。

RISC-V微架构的验证正处于一个十字路口，既要平衡开放性和灵活性的优势，又要应对多样性和复杂性的挑战。随着生态系统的成熟，应对这些挑战对于将RISC-V确立为其他微架构（ARM、X86）的可靠和安全替代方案至关重要。

通过社区驱动的方法、持续的创新和对标准化的关注，RISC-V的验证环境无疑将不断发展并迎接挑战。

不止随机

处理器验证不同于常规的ASIC验证，处理器验证空间更大。ASIC 中的 AS 代表特定应用。完全验证芯片的预期应用是有限且有界的。处理器验证不是。处理器指令集架构 （ISA） 中的每个操作都必须经过验证，以便在每种可能性（每种指令组合）中提供指定的行为，而在验证处理器 IP 时无法预测这一点。

SystemVerilog 和 UVM 是 ASIC 验证的主力军。UVM 是进行随机指令生成的好方法，但它有局限性。例如，覆盖率。如果你说你对“add指令”有 100% 的覆盖率，你一定有与我不同的覆盖率含义，因为我不相信你涵盖了所有可能的组合。此外，向处理器提供激励的典型方法是生成一堆随机指令。你也许能够根据要测试的特定区域来调整这些指令，但这是尝试验证处理器的一种非常低效的方法。它会发现一些简单的错误，但你必须继续提高验证效率。

很多客户都在做受约束的随机，事实上确实存在几个指令生成器，可以定向随机地为你生成数十万条指令。但这够了吗？

根据传统CPU供应商的经验，以及在RISC-V内核中看到的情况，基于仿真的验证是不够的。这就是为什么你必须考虑其他方法，比如Formal验证。

处理器以自下而上的方式进行验证，类似于当今系统的验证方式。处理器子单元包括分支预测、pipeline的一部分或内存系统，如cache缓存。这也往往是Formal方法的亮点。有些人在受约束的随机性下这样验证prefetch buffer/ALUs/register models/multipliers/load store unit，他们得到了很好的覆盖。但是，如果你不使用Formal验证，你就有可能在那里留下一些极端的情况，这就是验证的最后一公里，有遗留bug的风险。

使用Formal验证处理器子模块

验证子单元后，可以集成它们。可以想象在启动 Linux 时发现 ALU 错误是一种什么样的体验。

现在，需要一种更加混合的验证策略。Formal验证是有用的，因为从根本上说，Formal验证会执行所有可能的输入组合来验证ISA指定的行为，这些行为通常被描述为SystemVerilog断言。主要的处理器供应商还拥有广泛的验证套件，包括UVM测试平台和测试软件。仿真对于全面验证大型处理器的所有模块更是必要的，并确保将正确的行为集成到 SoC 中，同时还允许在被测处理器上执行测试软件。

令人惊讶的是，一个处理器核心中可以有很多错误，并且仍然能够启动 Linux。通过真实的linux系统启动，你会发现各种在其他EDA验证和Formal验证中找不到的东西，比如很多异步时序。

大多数人通过将实现的功能与参考模型进行比较来验证处理器。规格并非在各个方面都精确，它可能没有说明当六个相同优先级的中断同时发生时会发生什么。微架构选择采用哪一个，在pipeline的哪个阶段处理，这些选择因处理器内核而异。这个时候参考模型可能会起到意想不到的作用，当参考模型和RTL设计比对不通过时，你就会分析设计是否合理！

RISC-V的一大吸引力在于，你可以自由地修改处理器，使其更适合特定应用。挑战在于，你投入的每一件事情都会使验证加倍，复杂性加倍。添加东西非常容易，但是很难让它们以高质量出口。很多人没有意识到自定义指令增加的复杂性。他们必须自己进行所有这些验证。对于你添加的所有内容，必须完全重新验证所有内容，以及这个添加不会影响更多内容。你必须考虑它如何影响设计的其余部分，特别是如果它改变了pipeline中的内容、ALU 中的冲突、cache系统的问题或load store的东西。

你什么时候完成？
验证永远不会完成。普遍接受的想法是，当验证做得足够时，风险是可控的。

验证的过程就是告诉你已经做了哪些事情，验证给了你一定程度的信心，但它并不能保证不会有问题。如果你使用仿真，你可以生成大量的覆盖率报告，这些报告会让你有信心说你已经激发了你的设计的大部分，并且覆盖率证明了这一点，并且你已经发现了某些类别的错误。

由于处理器验证的复杂性，这种覆盖范围是不够的。

处理器覆盖率不仅仅是所有指令以及指令的耦合，此时你只是关注处理器中的解码器。你并没有真正测试其他任何东西，包括指令序列以及pipeline中发生的情况。

随着 RISC-V 中引入新的自定义指令，了解微架构以及如何影响整个 SoC 及其上运行的工作负载非常重要。硬件辅助验证，如虚拟原型功能、仿真和硬件原型设计，是整个验证流程中的关键组成部分。这些技术有助于确保RISC-V微架构决策不会对功耗和性能tradeoff产生负面影响。

当涉及到安全时，需要更加严格。根据最终产品所需的认证级别，他们必须达到一定程度的故障覆盖率。需要注入定义明确的故障，这些故障由 ISO 26262 为功能安全而定义。进行故障分析，然后生成诊断覆盖率。如果在设计中为关键功能插入这些故障，你是否内置了安全机制来处理这些故障？

当无法完成验证时，启发式方法往往变得很重要。原则性建议是，在验证是不要认为自己是一个验证工程师，需要站在用户的角度使用这款芯片，即必须继续运行真正的软件。在你运行一段时间后，一切似乎都正常。这是一个非常有价值的事情，即使无法量化，但是仍旧有很大的意义。

RISC-V的开源特性也使其面临潜在的安全风险。虽然透明度允许社区驱动的审查，但这也意味着对手可以访问相同的信息。这需要强大的安全验证，确保微架构能够抵御各种攻击。与封闭式架构相比，RISC-V的安全挑战更加严峻，专有设计可以对其安全功能保密。

RISC-V需要更多专用的验证工具。当处理器由五家不同的公司设计时，对这些处理器的测试生成器或Formal工具的需求并不大，因为它们都是在各个公司内部构建的。但现在有了RISC-V，围绕RISC-V ISA的架构分析、验证、Formal肯定有一个市场。

随着时间的推移，我们会看到人们为RISC-V的性能分析工具和Formal工具，但现在还为时过早。

下图列出了验证处理器微架构时可以考虑的方法。

处理器的验证方法。