RISC-V 设计中，架构一致性验证与实现验证缺一不可但二者存在本质区别，而具备架构一致性验证经验的工程师寥寥无几。RISC-V 虽赋予设计高度灵活性，却也埋下了生态系统碎片化的隐患。从数学角度而言，对所有指令组合进行穷尽测试根本无法实现，因此工程师们正逐步摆脱单纯的 “暴力测试” 模式。验证工作涉及多个专业领域，每个领域都至关重要且复杂度与日俱增。RISC-V 更是新增了架构一致性这一验证维度 —— 直到近期，该领域也仅由少数企业闭门研究。
企业采用 RISC-V 的核心诉求之一，是提升芯片的性能或优化功耗特性。但目前尚未形成统一标准的是，如何有效量化这些收益？如何在兼顾特定应用场景目标的前提下，对架构特性进行取舍，同时不损害软件的可移植性？
RISC-V 国际基金会（RVI）正评估自身的参与边界：在定义 RISC-V 内核的标准上，基金会是否对社区负有责任？又该如何判定一款设计实现是否符合相关规范？即便不开展全流程的验证工作，这一问题也难以解答。
行业内的诸多困惑，部分源于功能验证领域从未对“验证完整性” 给出明确定义。若将验证完整性理解为所有可能性的交叉组合，很快便会陷入无法解决的困境。尽管如此，行业仍能持续推出可用的产品，这正是得益于工程师们的专业判断 —— 他们能确定验证的核心重点，并设计出高投入产出比的验证流程。
架构一致性验证是多数工程师已生疏的技能，而整个行业必须加速补位。西门子 EDA 解决方案管理总监弗拉迪斯拉夫・帕尔菲表示：“架构一致性验证与实现验证的区别是根本性的，而人们常将二者混为一谈，这让验证工程师们倍感困扰。架构一致性验证要回答的是：你所设计的产品是否真的是一款 RISC-V 内核？需要验证其是否按规范执行指令、正确处理异常、精准实现内存模型等，本质是验证设计是否严格遵循官方规范实现了 RISC-V 的标准特性。而实现验证则聚焦于确保特定设计在实际场景中可正常工作，现实中，设计往往会以各种意想不到的方式出现故障。这一环节需要关注所有微架构细节，比如流水线实现、缓存一致性、分支预测，以及那些往往在研发截止日期、工程师熬夜攻坚时才会暴露的特殊边缘场景。”
尽管这两项工作看似相似，但其实现方法截然不同，在部分企业中，定义和执行这两项工作的责任甚至分属不同团队或机构。布雷克验证系统公司首席执行官戴夫・克尔夫指出：“二者虽有共通之处，但细微的差异决定了验证方法也必须做出相应调整。如今，RISC-V 内核厂商正面临与 ARM、英特尔等企业相同的问题，为解决这些问题，他们也在投入巨资研发新的验证流程。”
RISC-V 国际基金会已着手推进相关工作。布雷克验证系统创始人兼首席技术官阿德南・哈米德称：“基金会正开展认证相关工作。认证被视为架构验证的一小部分，但随着 RISC-V 扩展指令集的不断增加，这一工作的难度和规模也在持续扩大。其覆盖范围极广且并非固定不变，新的特性还在不断被加入。整个行业正携手打造一套覆盖率可追溯的流程，核心是梳理官方规范中的规范性规则 —— 即逐节分析规范，标记出需要验证的条款，这是第一步。随后提取这些条款并进行分类，明确需要覆盖的设计自由度，这是流程的组织环节。接下来还需设计测试流程并确定落地方式，而整个过程都需要实现从规范性规则到原始规范的全程可追溯。”
软件兼容性
RISC-V 及其他任何处理器的成功，都与其周边的生态系统紧密相关。阿尔泰瑞斯产品管理与营销总监阿什利・史蒂文斯表示：“当前 RISC-V 的标准化工作高度聚焦架构一致性，确保设计中所有软件可见的特性，都符合指令集架构（ISA）和平台规范的定义。架构一致性测试套件会对指令、控制状态寄存器（CSRs）、特权模式、中断行为、内存模型，以及其他软件可见的组件进行验证 —— 若中断控制器、IOMMU（输入输出内存管理单元）属于软件交互范畴，也会纳入验证范围。在社区、企业和标准组织的共同贡献下，这些测试套件正不断完善，为功能完整性验证提供了坚实的基础。而功能完整性的验证，主要通过指令集架构级的覆盖率指标，或与黄金参考模型的差分测试来实现。”
并非所有企业都关注软件兼容性。新思科技战略项目与系统解决方案执行董事弗兰克・希尔梅斯特称：“大型厂商或许无需过度担忧标准的开放性和互操作性，因为他们拥有完整的生态体系。这类厂商的 RISC-V 设计仅服务于自身需求，无需证明其内核在架构层面能正确解析指令集架构和相关配置文件，也无需保证软件能跨不同内核在这些配置文件上运行。这与为追求开放性而进行的设计截然不同。RISC-V 国际基金会则希望打造类似其他领域的一致性检测机制，而这一机制的核心目的，就是实现软件的互操作性：只要通过某一配置文件的一致性检测，软件就能在所有支持该配置文件的 RISC-V 内核上运行。”
但 RISC-V 的特性让这一目标的实现充满挑战。布雷克验证系统的克尔夫表示：“RISC-V 的阿喀琉斯之踵，恰恰是其最大的优势 —— 开放指令集架构带来的灵活性。工程师们在理解不断演进的指令集架构规范过程中，这种宝贵的灵活性可能会导致不同厂商的器件出现兼容性问题。而兼容性缺失会降低软件栈在不同器件间的可移植性，进而产生巨大的工程开发成本。”
这也是为何需要对 RISC-V 的设计边界进行约束。新思科技设计验证解决方案产品经理艾米・萨顿称：“开放性和可扩展性是 RISC-V 的设计初衷和核心理念，因此并不存在统一的 RISC-V 定义。配置文件的推出，本是为了提升软件可移植性，但绝不会出现因设计偏离指令集架构，就被判定为非 RISC-V 内核的情况。我们的 RISC-V 验证解决方案已定义了指令集架构覆盖率，且支持配置和扩展，客户可直接复用相关代码 —— 这套方案包含逾 10 万行 SystemVerilog 代码。客户基于此，可将精力集中在编写与自身设计相关的、更具针对性的覆盖率验证代码。”
标准仍是兼容性的核心支撑。微芯科技 FPGA 事业部技术院士皮埃尔・塞尔万表示：“架构一致性验证与实现验证虽独立开展，但都是保障 IP 验证完整性的核心环节。架构一致性验证通常通过遵循所有相关标准和规范实现，黄金参考模型则被用于确保所有相关扩展指令集的指令集架构一致性。同时，所有标准总线、对应的接口，以及其他标准化模块，都会纳入验证范围。”
归根结底，一致性的判定标准，是某一测试集的结果与黄金参考模型的比对结果。克尔夫补充道：“RISC-V 国际基金会正与哈维穆德学院合作，开发一系列相对基础的测试用例。这些用例可完成大部分非特权模式测试，但在特权模式测试中，自动化实现的难度会大幅提升，只能手动编写用例。对于基金会无力开发、且无法从其他开源方案中获取的测试用例，我们正接手开发。这类测试用例针对的是更复杂的特性，手动编写难度极高，而我们可通过测试综合工具自动生成。”
从架构一致性验证到实现验证
阿克西姆赛斯公司首席执行官阿希什・达尔巴里表示：“实现一致性验证面临两大核心挑战：一是确保内核能正常工作，二是确保内核在所有场景下都能正确工作。基于仿真的单元测试和一致性测试套件，只能验证内核‘能否正常工作’这一基础问题 —— 即测试用例通过即可，但并不适用于验证‘全场景正确工作’的完整一致性，比如无法验证所有指令的任意组合，在任意执行时机下，针对所有操作数都能正确运行。形式化验证技术是这类穷尽分析的理想选择，借助形式化模型检测工具验证关键不变量，该技术已在这类场景中取得了成功应用。这一方法的优势在于，除了能发现功能缺陷，还能检测出死锁、活锁问题，以及各类安全、可靠性隐患。缺陷修复后，可重新运行不变量验证，通过穷尽性证明确认缺陷已被彻底解决。作为六维覆盖率的重要组成部分，场景覆盖率能为架构师和验证工程师提供基于证明的场景分析视角，带来更深入的设计洞察。”
即便如此，要对设计的可用性形成完全的信心，仍存在诸多挑战。西门子 EDA 的帕尔菲称：“覆盖率指标就像验证仪表盘上的各类仪表，每一项都能反映关键信息，但单独一项都无法呈现完整的验证状态。代码覆盖率反映哪些逻辑被执行过，功能覆盖率反映哪些场景被测试过，断言覆盖率则确认执行过程中特定属性是否始终成立。每一项指标都能揭示部分真相，但问题在于，这些指标往往相互独立，无法形成联动。比如，代码覆盖率表现优异，却可能完全遗漏 RISC-V 指令流水线中的关键边缘场景；功能场景的验证全部完成，却可能从未对认证所需的核心架构一致性要点进行压力测试。”
通过运行设计获取覆盖率信息的流程，数十年来基本没有变化。微芯科技的塞尔万表示：“行业普遍采用大规模的压力测试，针对指定的扩展指令集持续输入数千条随机指令。同时，会搭建多个测试平台，验证设计实现的功能完整性。”
测试的执行速度越快，验证效率越高。新思科技的萨顿称：“我们缓解验证周期压力的方法之一，是采用硬件辅助验证技术提升测试执行速度，而覆盖率分析是其中的关键环节 —— 它能让工程师明确验证的重点。验证并非单纯的暴力测试、运行海量周期即可，尽管这确实是应对 10^18 量级验证周期挑战的方法之一。”
如今，越来越多的验证引擎被用于提升测试速度。新思科技的希尔梅斯特表示：“行业的目标是实现全验证流程的协同部署，即整合各类验证引擎的能力。这一流程从虚拟平台架构设计开始，延伸至硬件辅助验证和验证 IP—— 验证 IP 对接口验证尤为重要，测试生成工具也正融入这一体系。首先是架构覆盖率验证，比如指令、特权模式、通断、异常等场景，需通过覆盖组实现，通常在仿真环境中运行；随后是场景级验证，复杂度会进一步提升，而形式化验证技术能在这类问题的部分场景中发挥优势。”
测试综合技术的核心能力之一，是支持为各类执行引擎生成测试用例。布雷克验证系统的哈米德称：“测试用例需要能适配仿真、硬件仿真、FPGA 验证和硅后验证等多种场景，既包括事务级测试用例，也包括可在内核上运行的软件测试用例。在不同的验证层级，能实现的覆盖率会呈数量级提升：仿真环境中可完成 10^4 量级的用例测试，硬件仿真中可达 10^6 量级，硅后验证中则能实现 10^8 量级，甚至 10^9 量级的硅后验证用例测试也具备可行性。”
企业无法承担重复验证的成本。阿尔泰瑞斯的史蒂文斯表示：“实现验证是工程师投入精力最多的环节，涵盖微架构边缘场景、时序交互、缓存一致性、执行顺序、安全特性，以及软件不可见的硬件间协议接口等内容。要实现实现验证的完整性，需要结合仿真、硬件仿真、UVM 验证环境、覆盖率驱动的测试，同时越来越多地采用形式化验证技术。与能直接映射为指令级覆盖率的架构验证不同，实现验证的完整性更难量化，其验证重点高度依赖于各设计的具体结构和接口。”
覆盖率指标是验证工作推进的重要依据。微芯科技的塞尔万称：“覆盖率指标是评估设计验证质量的核心，功能覆盖率需与结构性覆盖率指标相互补充，后者包括语句覆盖率、分支覆盖率、条件覆盖率、翻转覆盖率和有限状态机覆盖率等。对于 MIV_RV32 这类高度可配置的嵌入式 IP 核，提取覆盖率指标的难度更高，通常需要通过大量的测试运行才能满足覆盖率要求。目前，工具厂商正持续升级产品，以实现从高度可配置的设计中提取覆盖率指标。”
定义覆盖率指标，需要资深工程师的专业判断。哈米德表示：“微架构中哪些部分值得做覆盖率验证？哪些队列存在溢出风险？这类工作的实现成本不菲，且目前尚无自动化工具能完成。客户需要逐一梳理并标记需要覆盖的点，这一问题的解决成本很高，但至少我们能明确问题所在，只要投入足够的时间和资金，就能推进解决。比如我们会发现，某一系统中的 Q5 队列从未出现过溢出 —— 这种情况是否可能发生？是否存在触发路径？若存在，需要哪些场景？从全局来看，这类信息往往是未知的，即便是架构师也无法给出答案。我们缺乏足够的设计细节来判断这类场景是否存在，因此只能通过工程判断，确定需要确定性验证的场景，其余则采用随机验证。但这一方法仅针对单一场景，而场景的执行顺序不同，也可能导致硬件出现不同的问题。”
实现验证完整性，需要理解不同类型覆盖率之间的关联。帕尔菲表示：“仅知道 RTL 代码中第 247 行被执行过，远远不够。我们需要知道这一行代码是否在所有关键条件下都被执行过、其相关断言是否触发正常、测试计划是否原本就计划验证该场景、以及该场景是否对应特定的架构要求。所有覆盖率数据需要实现统一整合，同时保留相互间的关联、维持设计的层级结构、保证全程可追溯。试想一下，若能将仿真、硬件仿真、形式化验证等所有验证引擎的覆盖率数据进行智能融合，同时保留设计结构、追踪各测试用例对覆盖率的贡献，最重要的是能清晰呈现验证缺口 —— 这将大幅提升验证效率。”
验证缺口
除了设计实现中的覆盖率漏洞，当前整个验证理念也存在诸多覆盖缺口，行业正逐步推进这些缺口的填补工作。
史蒂文斯表示：“RISC-V 生态的一大核心缺口，是除核心指令集架构外，缺乏标准化的硬件接口。可扩展的片上系统集成，依赖于处理器与系统其他组件（包括互连架构）之间可预测、可互操作、可验证的接口连接，而这正是实现验证的核心价值所在。尽管许多 RISC-V 开发者会采用 AMBA CHI 等现有接口，但这类规范的篇幅已超千页，其中大部分内容对典型的 RISC-V 系统而言并无必要。真正能为社区带来价值的，是一套面向 RISC-V 的精简接口子集，或一套贴合实际应用场景的轻量化接口标准。这类标准化工作，将大幅减少重复的验证工作、提升覆盖率的一致性，并加速多厂商产品间的互操作性。”
部分验证缺口还超出了功能验证的范畴。帕尔菲分享道：“我近期与一位工程师交流，他刚完成一款车用 RISC-V 内核的流片。该内核通过了所有架构验证测试，但在软件调试开展三个月后，工程师发现其分支预测的准确率如同抛硬币一般低。从技术角度看，该内核的设计是合规的，但从功能角度看，毫无实用价值，厂商承诺的性能指标完全无法实现。而目前全球范围内，没有任何一套测试套件能检测出这类问题 —— 因为性能验证尚未成为 RISC-V 生态的标准化内容，每家企业都在搭建自己的定制化基础设施，来回答‘这款产品的实际运行速度是否达标’这一问题。”
但追求高性能，又会引发新的问题。克尔夫表示：“对于部分设计，提升时钟频率以优化性能时，设计中的部分区域会成为热功耗热点，这一问题需要重点关注。我们可通过运行实际工作负载和合成工作负载，检测热功耗热点的触发情况，这一测试也会为功耗分析提供依据。汽车、数据中心等领域的企业对这一问题高度关注，他们需要通过调节时钟频率，模拟并验证热功耗热点的触发场景，同时认证产品能否承受相应的热阻和功耗压力。”
与其他部分应用领域一样，汽车领域为 RISC-V 验证增加了新的维度。帕尔菲称：“若为汽车或工业应用设计 RISC-V，工程师将面临功能安全和可靠性验证的全新挑战。ISO 26262 汽车功能安全标准并不关心产品是否通过了指令集架构测试，而是要求验证故障注入、错误处理机制的有效性，以及功能安全机制的运行表现。现有测试套件的设计并未考虑这些要求，因此企业需要从零开始搭建相关验证体系。”
其他验证技术的应用价值
形式化验证技术提供了一套互补的能力，在 RISC-V 验证中占据重要地位。帕尔菲表示：“早期的 RISC-V 相关探讨中，就已提及形式化验证方法，当时业内还抱有乐观的设想：‘RISC-V 是开放规范，我们可通过形式化验证，将整个内核与指令集架构进行比对，从而证明设计的正确性。’这一设想在理论上十分完美，但在实际落地中难度极大。”
尽管如此，形式化验证仍能发挥重要作用。史蒂文斯表示：“形式化验证正成为解决方案中越来越重要的部分，在架构一致性验证中表现尤为突出 —— 能确保指令集架构的各项属性在所有合法指令序列中都成立；同时，在实现验证中，该技术也能有效保障硬件协议的正确性。但形式化验证无法替代动态验证和系统级验证，尤其是在涉及完整片上系统行为和实际工作负载的场景中。在实际应用中，形式化验证主要发挥互补作用：通过穷尽验证解决深度边缘场景的正确性问题，而仿真和硬件仿真则负责实现端到端的完整性验证。”
目前，形式化验证技术已得到广泛应用。塞尔万表示：“形式化验证的落地，为在限定范围内对设计有效性进行穷尽测试提供了方法，从源头提升了代码质量。静态形式化工具被广泛用于早期的缺陷发现和修复，从而最大限度缩短后续的验证周期。形式化验证是我们研发流程的重要组成部分，通过持续的验证实践，其在高可靠性嵌入式 IP 产品的研发中，将持续发挥重要价值。”
人工智能的新能力也可被充分利用。芯智体公司首席执行官威廉・王表示：“RISC-V 是智能体式人工智能在验证领域的绝佳应用场景。我们已成功将智能体式人工智能应用于形式化验证，尤其是处理器设计以控制类信号为主，非常适合形式化推理和符号化探索 —— 这与 AI 加速器形成鲜明对比，AI 加速器的设计以数据中心式流程为主，难以单纯通过形式化技术实现验证。随着 RISC-V 的普及，人工智能驱动的形式化验证方法，将大幅加速架构一致性验证和实现验证的进程，为日益复杂、高度可配置的设计，提供可扩展的正确性和覆盖率验证方案。
原文：
https://semiengineering.com/does-your-risc-v-core-meet-with-the-standard
EETOP创芯大讲堂芯片课程推荐
热门跟贴