验证涉及多个学科，每个学科都至关重要，而且都变得日益复杂。RISC-V 又增加了一个学科——架构一致性——直到最近，这方面的研究还只是少数几家公司在私下进行。
采用 RISC-V 的一个关键原因是希望提升性能或功耗特性。然而，如何有效地衡量这些优势尚不明确。如何在不影响软件可移植性的前提下，权衡架构特性与这些特定应用目标之间的关系？
RISC-V国际组织（RVI）正在评估自身需要参与的程度。在定义RISC-V内核方面，RVI是否对社区负有责任？如何才能确定某个实现符合相关规范？除非开展全面的验证工作，否则这并非易事。
至少部分困惑源于功能验证领域从未对验证完备性做出明确定义。如果将其视为所有可能性的乘积，很快就会导致一个棘手的问题。尽管如此，业界仍然能够发布有效的产品，这证明了那些能够判断哪些因素至关重要，以及如何实现验证流程的工程师的卓越能力，从而使投入的时间和金钱获得良好的回报。
一致性验证是一项大多数工程师已经遗忘的验证技能，但业界必须迅速迎头赶上。“架构一致性验证和实现验证之间的区别至关重要，尽管它们经常被混为一谈，这让验证工程师们感到棘手，”西门子EDA解决方案管理总监Vladislav Palfy说道。“架构一致性验证旨在确认你设计的东西是否真的是一个RISC-V内核。你需要验证它是否按定义执行指令、正确处理异常、正确实现内存模型等等。它验证的是你是否按照官方规范使用了正确的RISC-V语言。另一方面，实现验证则旨在确保你的特定设计在实际应用中能够正常工作，而实际应用中往往会出现各种各样的问题。我们指的是所有微架构细节，例如流水线实现、缓存一致性、分支预测，以及那些只有在最不方便的时候才会出现的特殊情况，通常是在咖啡因和截止日期临近的情况下。”
虽然这两项任务听起来相似，但它们需要不同的方法，而且在某些情况下，定义和执行这些任务的责任可能由不同的团队或组织承担。“尽管这两项活动有共同之处，但它们之间存在细微差别，验证方法也截然不同，”Breker Verification Systems 的首席执行官 Dave Kelf 表示。“RISC-V 内核供应商现在正面临着与 Arm、Intel 和其他公司相同的问题，他们正努力解决这些问题，并在新的验证流程开发方面投入巨资。”
RVI 一直在努力完成这项任务的一部分。“RVI 一直在攻克认证难题，”Breker 的创始人兼首席技术官 Adnan Hamid 表示。“认证原本只是架构验证的一小部分，但由于扩展功能的不断增加，它仍然是一个日益严峻的问题。其范围非常广泛，而且并非一成不变。他们一直在添加新的内容。整个行业不得不共同探索一种覆盖率可追溯性流程，这相当于要逐节审查规范，也就是用荧光笔标记出需要验证的句子。这是第一步。然后，将这些句子提取出来，进行分类，并确定需要覆盖的自由度。这是组织工作。接下来，制定测试流程，并决定如何实现该测试流程。你需要从这些规范规则开始，一直追溯到原始规范，实现全程可追溯性。”
软件兼容性
RISC-V 以及任何其他处理器的成功都与其周围的生态系统密切相关。“目前，RISC-V 的标准化工作主要集中在架构一致性上，确保实现中所有软件可见的部分都按照指令集架构 (ISA) 和平台规范进行运行，” Arteris产品管理和市场总监 Ashley Stevens 表示。“架构一致性测试套件验证指令、CSR、特权模式、中断行为、内存模型以及其他 ISA 可见的组件——包括中断控制器或 IOMMU（当它们包含在软件契约中时）。这些测试套件在社区、公司和标准组织的贡献下不断完善，为功能完整性提供了坚实的基准。这可以通过 ISA 级别的覆盖率指标或与参考模型的差异测试来衡量。”
并非所有人都关心软件兼容性。“如果你是一家大型供应商，你可能不会太在意标准的开放性和互操作性，因为一切都由你掌控，” Synopsys战略项目和系统解决方案执行总监 Frank Schirrmeister 表示。“你只是为了自己而做，无需证明核心架构是否能够正确解读指令集架构 (ISA) 和相关规范，从而确保软件能够在不同核心的平台上运行。这与为了开放性而设计软件的情况截然不同。如果你看看 RVI 组织，他们希望进行类似其他领域的合规性检查。而合规性检查的真正目的就是为了实现软件的互操作性。如果你的软件通过了合规性检查，那么它就应该能够在不同的平台上运行。”
RISC-V 架构并非易于实现。“RISC-V 的致命弱点恰恰在于其最大的优势——开放指令集架构的灵活性，”Breker 公司的 Kelf 表示。“这种宝贵的灵活性也可能导致不同来源的设备之间出现不兼容的情况，因为工程师们需要努力理解不断发展的 ISA 规范。这种不兼容性降低了软件栈在不同设备间的可移植性，从而导致显著的工程开销。”
这就是为什么需要对问题进行限定。“RISC-V 的起源和理念在于开放性和可扩展性，”Synopsys 设计验证解决方案产品经理 Aimee Sutton 表示。“RISC-V 没有统一的定义。创建配置文件是为了方便软件移植，但没有人会因为偏离了指令集架构 (ISA) 就断言这不是 RISC-V 内核。我们的 RISC-V 验证解决方案定义了 ISA 覆盖范围，并使其可配置和可扩展，以便客户能够充分利用这些代码。SystemVerilog 代码超过 10 万行。客户可以利用这些代码，然后专注于编写更符合自身设计需求的、更有价值的覆盖范围。”
标准仍然是兼容性的核心。“架构一致性和实现验证是独立进行的，但对于确保整体 IP 验证的完整性至关重要，”Microchip Technology FPGA 业务部门的技术专家 Pierre Selwan 表示。“架构一致性通常是通过遵守所有相关标准和规范来实现的。黄金参考模型用于确保相关扩展的 ISA 合规性。所有标准总线及其相应的接口以及任何其他标准化模块都会进行测试。”
归根结底，一致性意味着一组特定的测试用例已经与黄金模型进行了比对。“RVI 通过哈维穆德学院开发了一套相对简单的测试用例，”Kelf 说。“他们可以完成大部分非特权测试，但当涉及到特权测试时，自动化就变得困难得多。他们必须手动编写这些测试用例。对于他们认为自己无法完成，且 RVI 无法从其他开源解决方案中获取的功能，我们将介入并提供所需的测试用例。这些功能将更加复杂，难以手动编写，但我们可以通过我们的测试合成工具生成这些测试用例。”
从合规到实施
“建立合规性面临两大挑战。首先，要确保核心系统能够正常运行；其次，要确保核心系统始终能够正确运行，” Axiomise首席执行官 Ashish Darbari 表示。 “虽然基于仿真的单元测试和合规性测试套件能够解决存在性挑战（即测试通过）的问题，但它们并非解决完全合规性问题的理想方案，也就是说，无论指令何时执行，所有指令的所有交错组合都能对所有操作数正确运行。形式化技术是进行此类详尽分析的自然选择，并且通过使用强大的不变量（这些不变量可以通过形式化模型检测工具进行验证）不断成功地证明了这一点。这种方法的优势在于，除了发现功能性缺陷外，它还能捕获死锁、活锁、安全性和可靠性问题。一旦缺陷被修复，就会再次运行不变量以获得详尽的证明，从而毫无疑问地证明缺陷已被捕获。场景覆盖率（六维覆盖率的一部分）提供了基于证明的对可能场景的洞察，为架构师和验证工程师提供了深入的见解。”
然而，要完全确信某项功能有效并非易事。“覆盖率指标就像验证仪表盘上的不同仪器，每个指标都衡量着一些重要的东西，但没有哪个指标能够单独讲述完整的故事，”西门子的帕尔菲说道。“代码覆盖率告诉你哪些逻辑被执行过。功能覆盖率告诉你哪些场景被测试过。断言覆盖率确认特定属性在执行过程中是否成立。每个指标都提供了一部分真相，但关键在于——它们讲述的都是不同的故事，而且往往是孤立存在的。你的代码覆盖率可能非常出色，但却完全忽略了RISC-V指令流水线中的一个关键边界情况。你可能完美地完成了功能场景的测试，但却从未真正测试过那些对认证至关重要的架构合规性要点。”
几十年来，用于获取覆盖率信息的设计测试流程基本保持不变。“我们会进行大量的压力测试，在指定的扩展范围内随机发送数千条指令，”Microchip公司的Selwan说道。“我们还会使用大量的测试平台来验证实现的完整性。”
测试执行速度越快越好。“我们缓解验证周期挑战的方法之一是使用硬件辅助验证来加快测试执行速度，”Synopsys 的 Sutton 表示。“覆盖率是其中的一部分，因为它能帮助你了解测试内容。这并非简单地用大量测试用例进行海量测试，但这无疑是解决我们之前提到的 10 到 18 个测试周期挑战的一种方法。”
越来越多的引擎正被赋予加速验证的使命。“我们的目标是能够部署整个验证流程，这意味着可以使用所有类型的验证引擎，”Synopsys 的 Schirrmeister 表示。“这涵盖了从虚拟平台架构到硬件辅助验证和验证 IP 的整个过程，其中验证 IP 对接口尤为重要。测试生成工具也融入其中。例如，要考察架构覆盖率——指令、权限、通过、异常等。为了测试这些覆盖率，可以使用覆盖组，这些覆盖组可以在仿真环境中运行。然后还要考察各种场景。因此，情况变得更加复杂。形式化验证在某些方面表现出色。”
测试综合的一项重要功能是它可以针对多种执行引擎。“你需要能够为仿真、模拟、FPGA 和芯片后测试环境综合测试内容，”Breker 公司的 Hamid 说道。“这可能包括事务级测试，也可能包括运行在内核上的软件。在每个层级，测试覆盖率都会提高大约 10² 倍。例如，你可以在仿真环境中测试10⁴ 个用例，在模拟环境中测试 10⁶个用例，在芯片后测试环境中测试10⁸ 个用例。在芯片后测试10⁸或 10⁹个用例也是合理的。”
你不能总是重复验证同样的东西。“实现验证占据了工程工作的大部分精力，”Arteris 公司的 Stevens 说。“这包括微架构的极端情况、时序交互、一致性、顺序、安全属性以及软件无法看到的硬件间协议接口。要实现完整性，需要仿真、模拟、UVM 环境、覆盖率驱动的测试以及越来越多地使用形式化验证。与自然映射到指令级覆盖率的架构测试不同，实现完整性很难量化。它很大程度上取决于每个设计的具体结构和接口。”
覆盖率指标可以显示您实现目标的进展情况。“覆盖率指标是评估设计验证质量的关键，”Microchip 的 Selwan 表示。“功能覆盖率与结构覆盖率指标相辅相成，例如语句覆盖率、分支覆盖率、条件覆盖率、翻转覆盖率和有限状态机 (FSM) 覆盖率。提取高度可配置的嵌入式 IP 核（例如 MIV_RV32）的覆盖率指标更具挑战性，通常需要进行大量测试才能满足覆盖率要求。工具供应商目前正在努力改进其产品，使其能够从高度可配置的实现中提取覆盖率指标。”
定义这些指标需要技术精湛的工程师。“微架构中哪些部分值得测量覆盖率？哪些队列容易溢出？这项工作成本不低，而且我不知道有什么自动化方法可以实现，”Hamid说道。“客户必须逐一标记他们想要覆盖的内容。这是一个成本很高的问题，但至少我们可以描述它，只要有足够的时间和资金，我们就可以着手去做。现在我们发现这个系统中的Q5没有发生溢出。这能实现吗？它是否可行？如果可行，需要什么样的场景？这些信息在全局范围内往往是未知的，也就是说，没有人知道——甚至架构师也不知道。我们没有足够的细节来判断这种情况是否可行。我们正在做出工程决策，确定哪些部分需要确定性地进行交叉，而其他部分则随机化。但这只是考虑个别场景，而这些场景的顺序安排可能会导致不同的硬件问题。”
完整性要求理解不同覆盖类型之间的关系。“仅仅知道你的 RTL 代码执行到了第 247 行是不够的，”Palfy 说，“你需要知道在所有重要条件下是否都执行到了这一行，相关的断言是否正确触发，你的测试计划是否真正旨在验证该场景，以及它是否映射到特定的架构需求。你需要将所有覆盖数据统一起来，同时保持它们之间的关系、层次结构和可追溯性。想象一下，能够看到来自每个验证引擎（仿真、模拟、形式化测试）的覆盖数据被智能地合并，同时保持设计结构，跟踪哪些测试贡献了哪些覆盖，最重要的是，还能显示其中的差距。”
验证漏洞
除了实现层面的覆盖漏洞之外，如今整个理念层面也存在覆盖漏洞。随着时间的推移，人们正在努力填补这些漏洞。
“RISC-V 生态系统的一大缺陷在于核心指令集架构 (ISA) 之外缺乏标准化的硬件接口，”Stevens 表示。“可扩展的片上系统 (SoC) 集成依赖于处理器与系统其他部分（包括互连）之间可预测、可互操作且可验证的连接。正因如此，实现验证才显得尤为重要。虽然许多 RISC-V 开发人员采用了现有的接口，例如 AMBA CHI，但这些规范的篇幅已超过 1000 页，其中很多内容对于典型的 RISC-V 系统而言都是不必要的。真正能够造福社区的是一个专注于 RISC-V 的子集，或者一套与实际应用场景相符的精简接口标准。这样的标准化将显著减少重复的验证工作，提高覆盖率的一致性，并加速多厂商之间的互操作性。”
有些差距远不止功能性问题。“我最近和一位工程师聊过，他刚为一个汽车应用完成了RISC-V内核的流片，”帕尔菲说道。“这个内核通过了所有架构测试，但在软件启动三个月后，他们发现分支预测器的准确率跟抛硬币一样低。技术上正确，但功能上毫无用处。他们承诺的所有性能根本没有实现。而且世界上没有任何测试套件能发现这个问题，因为性能验证并非生态系统的标准化内容。每个人都在构建自己的定制基础设施来回答‘这东西真的运行得快吗？’这个问题。”
然而，速度快也会带来其他问题。“对于某些设计，当你提高时钟性能时，设计中的某些部分会变成热点，你真的需要开始关注这些问题了，”凯尔夫问道。“我们可以运行实际工作负载和合成工作负载，看看是否会触发热点。这与功耗问题息息相关。真正关注这一点的公司，例如汽车和数据中心，希望确保他们能够测试这些热点，并通过调整时钟来验证他们能够处理热阻和功耗问题。”
汽车行业和其他一些应用领域一样，给这个问题增添了新的层面。“如果你正在为汽车或工业应用构建 RISC-V 系统，那么在安全性和可靠性验证方面，你将面临全新的挑战，”Palfy 说道。“ISO 26262 标准并不关心你是否通过了 ISA 测试。它关注的是故障注入、错误处理以及功能安全机制的有效性。现有的测试套件在设计之初并没有考虑到这些，所以你只能从零开始。”
其他技术的作用
形式化验证增加了一系列互补的功能，这些功能发挥着重要作用。“早期的 RISC-V 讨论中就提到了形式化方法，”Palfy 说。“当时有一种乐观的想法：‘这是一个开放规范。我们可以对整个内核进行形式化验证，使其符合指令集架构 (ISA)，并证明其正确性。’这在理论上很美好，但在实践中却非常残酷。”
然而，形式化验证仍然发挥着重要作用。“形式化验证正成为解决方案中越来越重要的组成部分，”史蒂文斯说道。“它在架构合规性方面尤其强大——确保指令集架构（ISA）属性对所有合法指令序列都成立——以及在实现验证中强制执行硬件协议的正确性。但形式化验证并不能取代动态验证或系统级验证，尤其是在涉及完整的片上系统（SoC）行为和实际工作负载时。在实践中，形式化方法扮演着补充角色，证明深度边界情况的正确性，而仿真和模拟则建立端到端的完整性。”
形式化验证正被积极应用。“采用形式化验证提供了一种方法，可以在一定范围内全面测试我们设计的有效性，从而从一开始就提高代码质量，”Selwan说道。“静态形式化工具被广泛用于及早发现和解决缺陷，从而最大限度地缩短后续验证周期。形式化验证是我们开发周期中的一个重要环节，通过验证，它将继续在实现高质量嵌入式IP产品方面发挥重要作用。”
新的人工智能功能也可以得到充分利用。“RISC-V 是应用智能体人工智能进行验证的绝佳领域，” ChipAgents首席执行官 William Wang 表示。“我们已经看到智能体人工智能在形式化验证方面取得了显著成功，尤其因为处理器设计主要由控制信号构成，这使得它们非常适合形式化推理和符号探索。这与人工智能加速器形成鲜明对比，后者往往涉及更多以数据为中心的流程，不太适合纯粹的形式化技术。随着 RISC-V 的普及，人工智能驱动的形式化方法可以显著加速架构一致性验证和实现验证，为确保日益复杂、可配置的设计的正确性和覆盖率提供可扩展的方法。”
来源：编译自semiengineering
参考链接：https://semiengineering.com/does-your-risc-v-core-meet-with-the-standard/
本文转自：半导体行业观察，转载此文目的在于传递更多信息，版权归原作者所有。如不支持转载，请联系小编demi@eetrend.com删除。
