这和我最近的一些体会，其实有些所见略同。

从2023年起，我每年都会参加RISC-V的欧洲峰会，每次也都会做一期短视频聊聊参会感受。今年特别忙，还没来得及做，但其实想法早就有了。如果说第一年峰会的感觉是「RISC-V会是芯片未来」，第二年是「RISC-V更加无处不在」，那今年的感受就是：

RISC-V的发展，已经进入深水区。

前几年大家都在拥抱趋势，畅想未来；今年就能明显感到，很多公司和机构都在面临交付甚至创收的压力。从原理做个原型其实不是最难的，难的是从原型做出一个能解决实际问题的、达到可交付标准的产品。

而衡量一颗芯片是否达到可交付标准，就是看验证（verification）。有调查机构做过统计，2024年只有14%的芯片项目能做到一次性流片成功，剩下那些都是因为各种各样没被发现的bug导致需要再次流片。还有机构统计过，现在一个芯片项目中，高达70%的资源都被验证环节消耗掉了。所以毫不夸张的说，验证已经成为现代芯片开发的最大痛点，或许没有之一。

但对于RISC-V来说，验证其实还有一些远超常规的、独特且严峻的挑战，这是很多其他芯片验证工作中很少、甚至是不会遇到的。今天这篇文章就展开聊聊这个问题。

在分析RISC-V芯片验证的独特挑战之前，有必要科普一下做芯片验证到底要做哪些事情，这样你就能更深刻体会为什么RISC-V的验证竟然会更难了。

我们不妨以自研一颗RISC-V内核举例，看看一个典型的验证流程都包含哪些阶段。

首先是规格验证（Spec Verification），这也是所有验证的起手式。在实际开始搭验证环境、甚至在写第一行验证代码前，验证工程师需要根据处理器的架构和功能规格制定验证计划（vPlan），从而确保设计包含ISA规范要求的所有功能，并为每项功能制定测试方案。对于RISC-V内核验证，这通常涉及核对指令集架构(ISA)规范，确认设计支持所有规定的指令、特权级和异常行为，划分功能点、并确定对应的覆盖信息和测试用例、采用怎样的验证方法学等等。规格验证阶段的输出是详细的验证计划和初步测试集，奠定后续验证工作的基础。

但很可惜的是，我了解到一些RISC-V核的开发团队，竟然都没有完整的验证计划，那后续的工作就无从谈起了。

有了验证计划，就能选择合适的验证方法开展对应的验证工作了。比如形式化验证（Formal Verification）就是通过编写形式化断言（Assertions）和属性（property），利用形式验证工具来证明设计是否满足属性要求。形式验证适用于证明永不发生或永远成立的设计性质，例如“无死锁/活锁”“缓存一致性协议正确性”或“用户模式无法访问内核模式内存”等。形式验证可以在设计早期发现角落情况错误，并提供穷尽性证明，覆盖仿真难以触及的状态空间。

更传统的方式一般基于功能仿真（Functional Simulation），即使用仿真器运行设计的RTL模型，配合测试平台产生的激励，检查设计行为是否符合期望。通常来说，测试平台（testbench）大都采用基于SystemVerilog UVM等方法学进行构建。

在模块级仿真中，对处理器各子模块（ALU、取指单元、缓存等）进行定向测试和随机测试，确保基本功能正确。在核心级和SoC级仿真中，运行大规模指令流或完整的软件镜像。在系统级仿真中，还会运行和测试操作系统（Linux等）在RTL上的启动，验证内核与外设协同工作及异常处理、上下文切换等系统行为。

针对RISC-V内核，经常会使用指令流生成器（如开源的riscv-dv工具）随机产生指令序列，以及运行RISC-V官方合规测试套件验证指令行为。在仿真过程中，需要使用参考模型（如Spike、QEMU等）与RTL运行结果进行对比，确保每条指令的结果与黄金模型一致。

验证的一个灵魂拷问，是判断何时停止，这就涉及到覆盖率分析（Coverage Analysis）的问题。覆盖率包括代码覆盖（如语句、分支、状态机覆盖）和功能覆盖（针对规格定义的功能点的覆盖）。验证团队会制定覆盖率目标，并在仿真和形式验证后收集覆盖率数据。对于复杂的RISC-V内核，特别需要关注指令功能覆盖（每条指令和组合是否测试到）、异常场景覆盖（如各种异常/中断的触发和恢复）、乱序执行下重排场景覆盖，以及内存一致性场景覆盖等。

当RTL在单核级别验证趋于完善后，还需在更高层次进行系统级验证。例如，多核SoC环境下验证缓存一致性、片上互连和外设接口。可采用FPGA原型或硬件仿真器来加速运行真实软件负载。系统级验证也包括功耗管理验证（如电源域切换、时钟门控等情景），以及安全启动、错误注入测试等特殊场景。

验证并非一次性完成，而是需要在设计更新迭代中持续进行，这就需要进行旷日持久的回归测试（Regression Testing）。每当RTL有修改或添加新功能，需要运行既有的测试集合进行回归，确保新改动没有引入对旧功能的破坏。一般对于CPU验证来说，回归中需要反复运行大规模随机指令流测试，每晚或每周运行上亿条指令的仿真，才有可能捕获概率极低的Bug情况。

前面介绍的这些步骤只是一些有代表性的验证工作，实际上做的时候会更加纷繁复杂。但对于RISC-V来说，还有一些验证层面的独特挑战，我总结了三点：

第一是RISC-V的「验证剪刀差」。一方面，买RISC-V IP的人期望他们所采用的RISC-V内核能拥有与业界成熟的商业IP（如Arm）相媲美的质量和可靠性；另一方面，RISC-V内核的开发者（无论是开源社区还是内部团队）往往不具备同等规模的验证资源来达成这一目标。

事实上，这个差距的量级是惊人的。据统计数据，顶级的商业处理器IP供应商会投入高达10^15（一千万亿）个验证周期来验证一颗处理器内核。这个数字相当于让15,000台仿真器不间断地运行整整一年。对于大多数RISC-V开发团队来说，达到这样的验证强度几乎是不可能的。

这个问题的本质，其实源自RISC-V的开源属性。由于RISC-V是指令集架构而不是芯片架构本身，好处是所有人都能用这个指令集来设计微架构、进而开发芯片产品，但问题是每个致力于开发RISC-V内核和芯片的团队都要走一遍完整的验证流程，在验证层面这相当于本来就有限的资源的进一步分散。相比之下，对于x86巨头和arm来说，他们可以投入大量资源打磨少数IP或芯片设计，然后把同样的产品卖给多数人，和RISC-V正好相反。

因此，如何利用有限的工程师和工具资源来弥合这一巨大的质量预期差距，构成了RISC-V验证的首要战略挑战

RISC-V的第二个独特验证挑战，是灵活性带来的组合爆炸问题。RISC-V ISA由一个精简的基础整数指令集（如RV32I）和一系列可选的标准扩展（如M、A、F、D、C、B、V等）组成，它还允许设计者添加自定义指令来构建特定领域加速器。

但这种灵活性导也致了ISA配置的“组合爆炸”。验证一个简单的RV32I内核、与验证一个集成了浮点、原子、压缩、位操作、矢量扩展以及自定义AI指令的复杂RV64GCV内核，在复杂性上有着天壤之别。每一个标准扩展的组合，以及自定义指令与标准指令之间的交互，都可能产生细微且难以预料的边界条件和功能缺陷，从而形成一个庞大无比的验证空间，进一步放大了验证难度。

很遗憾，至少到目前，除了我的研究团队发表过面向RISC-V指令集扩展的验证研究工作（尽管很初期），我好像还没太看过其他学者或团队专门研究这个问题。

第三个挑战，是开源设计和闭源验证的矛盾。虽然RISC-V主打开源开放，但更多是设计层面的开源。在验证领域，仍然缺少足够好、足够多的开源验证工具、验证IP（VIP）、参考项目等等。从公司的角度，即使他们选择开源一些自研的RISC-V内核或IP，也更多是基于扩大和共建生态考虑，开源的内容通常都已经经过充分内部验证，而这些验证工作本身并不会开源出来。

值得注意的是，这三个挑战并非孤立存在，而是相互叠加，使问题呈指数级恶化。一个资源有限的团队（验证剪刀差），需要去验证一个独一无二的ISA配置（模块化困境），而这个配置又实现在一个高度复杂的自定义微架构之上、且缺少足够的开源验证工具（闭源验证）。这种局面意味着，任何一个自研RISC-V内核的项目，其团队都同时扮演了处理器IP供应商和SoC集成商的双重角色。他们不仅要负责将内核集成到SoC中，更要对内核本身的质量负全部责任——而这正是顶级IP供应商投入巨量资源去完成的任务。

同样遗憾的是，很多团队并没有意识到这个问题。

当然，不能只抛问题，不提解法。现在看来，并不存在太多弯道超车、换道超车的可能，也不应该寄希望于奇技淫巧。最靠谱的方法，可能还是需要踏实投钱，利用好已有的工业级验证工具。只不过，在使用过程中可以更聪明的发挥不同工具的特点，实现1+1>2的效果。

以EDA巨头Cadence的验证工具举例，他们提供了完整的RISC-V验证套件，在上面说的各个层面都有自己的布局，很多是行业遥遥领先的存在，相信也是包括我在内的很多芯片工程师日常在用的。

比如，对于仿真来说，Cadence有Xcelium逻辑仿真器，它原生支持多种常用的验证语言和验证方法学（SystemVerilog, SystemC, UVM 等），能够充分利用多核并行加速长测试用例的运行。此外还有一些验证专用IP（VIP），这些VIP与Xcelium以及Cadence的调试环境（如Verisium Debug）紧密集成，能够高效地发现并定位DUT与参考模型之间的差异，加速复杂错误的调试过程。

这里稍微提两句Verisium，它并不是一个工具，而是Cadence做的基于AI驱动的验证平台，集成了多个验证APP，包括Verisium Debug、Verisium Manager、Verisium AutoTriage等等，分别用来做基于AI的电路调试、验证规划与管理、通过机器学习策略去做错误分析等等。之所以多说两句这个工具平台，是因为现在AI辅助验证已经是EDA巨头们争相发力的重点，想要从事验证行业的朋友可以多关注下这方面，我自己也在做这方面的研究，之后也会更多分享一下，记得点赞+关注我。

对于原型验证和硬件仿真加速，Cadence的Palladium仿真器和Protium原型平台可以在接近芯片实际运行的环境下运行操作系统、应用程序，以发现RTL仿真难以覆盖的时序和系统交互问题。其中Palladium调试能力更强、能支持更大的设计；Protium基于FPGA加速，性能更高，可以运行完整操作系统（Linux、Android）和应用程序等大型软件栈，从而在芯片流片前进行大规模的软件兼容性和性能测试。很重要的是，Palladium和Protium之间共享统一的编译流程，使得设计可以从重调试的Palladium环境快速迁移到重性能的Protium环境。

在大规模验证中，Cadence还会提供大量VIP（如AXI总线VIP、TileLink总线VIP、存储器模型等）来模拟标准总线和器件行为，避免验证团队重复造轮子，提高验证效率。

此外，之前还提过，Cadence还有JasperGold形式化验证平台，能专门用来对内核中最关键、最难仿真的部分进行穷尽式验证，特别适合验证诸如总线仲裁和乱序调度等复杂的控制逻辑，也可以发现深层次的安全漏洞，如物理内存保护（PMP）单元的权限绕过，或可能导致侧信道攻击（Side-Channel Attacks）的微架构行为。

既然提到形式化验证就再多说一点，Cadence还在构建名叫Jasper RVV的形式化验证工具，专门用来做RISC-V的指令集架构ISA验证。目前的RVV模型支持RVI20U32 Profile，并且在增加对RVI20U64的支持。看不懂这个的没关系，可以把这些看成是RISC-V指令集的一些「官方规范」。这个RVV模型就类似前面说的Spike、QEMU等模型，只不过放到了形式化验证领域，这样人们就可以直接形式化验证一个RISC-V的ISA设计了，这个也是行业的刚需，就看谁先做出来了。

和前面介绍验证步骤时类似，这里介绍的一些验证工具只是整个验证流程中的「九牛一毛」。我去年听了DVcon和一些其他的验证相关的会议，发现各家验证方案厂商已经在把AI放到验证中了，比如用AI自动分析日志、自动进行错误定位、自动分析代码会产生怎样的错误等等。

回到文章开头群友发的那句感慨。其实倒不是因为做RISC-V公司多了所以更卷，而是因为很多技术越卷越难了。特别是验证重要性不断提升的当下，提升一点验证性能，就会放大到对整个项目的很大帮助。

我几乎没推荐过大家去从事芯片验证的工作，但或许现在这是个值得研究和投身的领域。

（注：本文不代表老石任职单位的观点。）

老石谈芯社群组建中！扫码添加小助手进群～