UCV: 通过软件原生优化实现硬件验证的民主化与加速

原文链接: ISCA 2026 Submission #414 UnityChip Verification (UCV)

摘要

硬件验证占芯片开发工作量的约 70%，在 CPU 设计中，验证工程师与设计师的比例可达 5:1。传统硬件验证强调验证资产的重用，而新兴的软件框架将验证嵌入通用编程语言以提高可用性。然而，这些框架仍以模拟器为中心，严重依赖模拟器控制的时序、事务生命周期和可观测性，限制了验证的进一步民主化和加速。

本文提出 UnityChip Verification (UCV)，一个软件原生验证平台，将事件调度和控制重新置于显式软件事件循环内，同时将模拟器视为可插拔后端。UCV 识别并解决了三个关键挑战：

  1. 软件与硬件时序之间的编程范式鸿沟
  2. 组合现有验证组件的困难
  3. 性能与可调试性之间的权衡

在 XiangShan 和 RocketChip 上的评估表明，UCV 同时提升了加速和民主化：相比 Cocotb，UCV 实现高达 25倍 的运行时加速和 76% 的内存降低；复用现有组件时吞吐量提升 16.6%。在社区部署中，软件背景的新贡献者中有 26.3% 产出可运行测试，11人共同发现 30个 此前未知的 bug。

1. 问题定义

“Hardware verification is critical in chip development, accounting for approximately 70% of project timelines. In CPU design, verification engineers often outnumber designers and can reach 5:1.”

硬件验证是芯片开发中的关键环节，但面临以下核心挑战：

1.1 编程范式鸿沟

硬件遵循时钟驱动的事件驱动时序模型，而软件以顺序方式执行，没有原生的时钟概念。现有机制只能满足其中一方面：

  • 周期精确控制（如 PyMTL、ChiselTest）：提供可预测的同步语义，但将交互限制在粗略的周期边界，无法表达异步或周期内行为
  • 回调驱动机制（如 Cocotb）：扩展了表达能力，但将回调时序委托给模拟器，可能在信号稳定前恢复软件协程，导致瞬态或陈旧观测

1.2 验证组件复用困难

现有的硬件验证 IP（如参考模型、激励生成器）依赖于硬件端的事件和事务，被软件-硬件边界隔离。复用这些组件需要：

  • 事件同步：实现跨域执行流的对齐
  • 事务调度：协调软件和硬件环境之间的交替执行

1.3 性能与可调试性权衡

高性能模拟器通过合并计算流和减少中间状态来优化性能，而调试需要插入调试代码和跟踪中间状态，这与性能目标相冲突。例如，Verilator 启用 VPI 调试会导致 70% 性能损失和程序大小翻倍。

2. 方法框架

UCV 的核心洞察是将验证执行与模拟器运行时解耦，使验证逻辑能够独立于模拟器驱动的控制流演进。

2.1 软件原生架构

UCV 架构对比 图：不同验证架构对比 - (a) 传统 (UVM) (b) 模拟器中心 (Cocotb) (c) 软件原生 (UCV)

UCV 采用三层架构：

  1. 验证逻辑层：用软件语言（Python、Scala 等）编写的测试平台
  2. UCV 平台层：提供软件原生 API 进行验证调度和设计状态访问
  3. 模拟器后端层：RTL 模拟器作为可插拔后端，仅负责执行硬件设计

2.2 三大核心技术

➀ 软件原生时序与交互

UCV 引入软件原生时序模型，提供事件级表达能力，同时保证跨后端模拟器的周期精确、时钟对齐语义。关键特性：

  • 显式软件事件循环：UCV 拥有时间推进和观测边界的控制权
  • 异步运行时兼容：与现代软件异步运行时兼容，可复用软件测试库
  • 周期精确保证：RTL 设计表现为包含异步逻辑的软件包

➁ 透明硬件-软件映射

UCV 设计跨域同步机制，将模拟器中实例化的硬件组件提升为托管软件对象，保留调度能力：

  • 事件同步：实现硬件事件在软件侧的可见性
  • 事务调度：协调跨域的数据交互，避免 CPU 争用或死锁
  • VIP 复用：直接复用现有硬件验证 IP（如 UVM VIP）

➂ 非侵入式内省方法

UCV 在软件原生层实现内省和调试：

  • 指针钩子：访问底层电路状态的指针，无需插桩额外中间信号
  • 按需计算：根据信号相关性选择性激活计算
  • 性能保持：避免创建中间状态，保持高性能

2.3 工作流程

UCV 工作流程 图：UCV 平台概览 - 左侧为验证和打包工作流，右侧为运行时平台结构

UCV 工作流程包含三个步骤：

  1. 封装 RTL 设计：将 RTL 设计编译为动态库，通过 SWIG 生成多语言绑定
  2. 注册到事件运行时：将设计暴露为具有显式周期精确事件操作的软件对象
  3. 编写和运行测试：使用现有测试框架（如 pytest、JUnit）编写和运行测试

3. 实验结果

3.1 性能对比

指标 Cocotb UCV 提升
运行时加速 1× 25× 25倍
峰值内存使用 100% 24% 降低 76%
复用组件吞吐量 基准 +16.6% 提升 16.6%
验证代码行数 基准 -12% 减少 12%

3.2 功能支持对比

框架 软件原生封装 事件驱动验证 硬件 VIP 复用 调试器 速度
UVM ✗ ✔ ✔ ✔ 慢
Fault ✔ ✗ ✗ ✗ 中等
ChiselTest ✔ ✗ ✗ ✗ 中等
PyMTL ✔ ✗ ✗ ✗ 较快
Cocotb 部分 部分 ✗ ✔ 慢
UCV ✔ ✔ ✔ ✔ 快

3.3 社区部署结果

在围绕 XiangShan（香山）的六个月社区研究中：

指标 数值
关注者 520 人
贡献者 95 人 (18.3%)
产出可运行测试 25 人 (26.3%)
发现未知 bug 11 人发现 30 个 bug

典型案例：5 名软件背景本科生在 2 个月内确认 10 个 分支预测 bug，而有经验的硬件工程师需要长达 5 个月才能发现 2 个 comparable bug。

4. 优点与局限

4.1 优点

  1. 显著性能提升：25倍加速和 76% 内存降低
  2. 降低入门门槛：软件开发者可使用熟悉的测试框架参与硬件验证
  3. 组件复用：支持直接复用现有 UVM VIP 等硬件验证组件
  4. 非侵入式调试：在保持性能的同时提供强大的调试能力
  5. 多语言支持：通过 SWIG 生成绑定，支持 Python、Scala 等多种语言

4.2 局限

  1. 模拟器依赖：仍需 RTL 模拟器作为后端，无法完全替代
  2. 复杂设计支持：对于超大规模 SoC 的验证效率有待进一步验证
  3. 生态成熟度：相比 UVM 等成熟框架，UCV 的生态系统仍在建设中
  4. 学习成本：虽然降低了软件开发者的门槛，但硬件验证知识仍是必需的

5. 总结

UCV 通过软件原生验证架构重新定义了硬件验证的范式，将控制权从模拟器转移到软件事件循环，同时保持周期精确性。这一架构不仅带来了显著的性能提升（25倍加速），更重要的是民主化了硬件验证——让软件背景的开发者也能有效参与硬件验证工作。

在开源处理器 XiangShan 和 RocketChip 上的验证表明，UCV 能够同时实现加速和民主化，为硬件验证领域开辟了新的可能性。随着 AI 芯片设计的复杂度不断增加，UCV 的软件原生方法有望成为未来硬件验证的重要方向。

参考文献

  1. Accellera. Universal Verification Methodology (UVM) 1.2 User’s Guide, 2020.
  2. IEEE. IEEE Standard for Standard SystemC Language Reference Manual. IEEE Std 1666-2011, 2012.
  3. IEEE. IEEE Standard for Verilog Hardware Description Language. IEEE Std 1364-2005, 2006.
  4. Linux Foundation. The Linux Kernel Archives, 2024.
  5. pytest-dev. pytest: helps you write better programs, 2024.
  6. Python Software Foundation. asyncio — Asynchronous I/O, 2024.
  7. UC Berkeley. Rocket Chip Generator, 2024.
  8. Veripool. Verilator: Fast free Verilog/SystemVerilog simulator, 2024.
  9. SWIG. Simplified Wrapper and Interface Generator, 2024.
  10. Wang, H., et al. XiangShan: An Open-Source High-Performance RISC-V Processor. MICRO 2022.

本文基于 ISCA 2026 Submission #414 整理，仅供学术交流使用。