浅谈RISC-V微架构验证方式

对于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工具，但现在还为时过早。

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

处理器的验证方法。

审核编辑：黄飞