“万众一芯”是一个开源开放的芯片验证平台，致力于用 AI 和软件的方式重构芯片验证。
平台自主研发了一系列开源工具，可以大幅提升验证效率，降低验证门槛，众包验证工作。开源高性能 RISC-V 处理器核“香山”是首批使用该平台的项目之一。
期待您与我们一起，通过创新的验证技术、开放的协作模式，让芯片验证从“人力密集”走向“智能高效”，共同构建AI驱动的芯片验证新范式。
近日，万众一芯团队的研究成果——《Democratizing and Accelerating Hardware Verification with Software-Native Optimization》正式被ISCA 2026录用。这是硬件验证方法学领域一项具有里程碑意义的工作，标志着万众一芯在推动验证技术走向智能化、软件化方向迈出了关键一步。
ISCA（International Symposium on Computer Architecture）是计算机体系结构领域历史最悠久、影响力最高的顶级会议之一。论文的录用，既是对万众一芯在验证基础设施层面系统性创新的高度认可，也代表着“软件原生验证”这一技术路线开始进入国际学术视野。
以下是论文内容概述，论文全文将在正式发表后公开，欢迎感兴趣的开发者阅读、试用，并参与到后续的社区工作中来。
一、为什么“用了软件语言”还不够？
近年来，越来越多验证框架开始支持用Python、Scala等通用语言编写testbench，看起来离“软件化”更近了。但论文指出，这类方法仍停留在语言替换层面，其核心验证语义——时序控制、事务生命周期、可观测性——仍然由RTL仿真器（simulator）掌控。
这意味着，即便testbench写在软件语言里，验证流程本质上仍是simulator-centric。软件侧代码只能通过cycle stepping或回调与设计交互，既难以与软件生态深度融合，也难以真正降低参与门槛。
论文将这一问题归结为三项挑战：
时序表达的二难：软件是顺序执行，硬件是事件驱动，现有机制在表达能力和时序正确性之间难以两全；
生态组件难以复用：大量成熟的验证IP（VIP）依赖simulator内部机制，无法直接在软件环境中使用。
性能与调试难以兼顾：传统DPI/VPI接口在大规模设计下，调试能力与仿真性能彼此牵制。
二、UCV 想改变的是什么？
针对上述问题，论文提出了UnityChip Verification（UCV），一项完全由万众一芯自主研发的验证基础设施方案。UCV的核心思路是：将验证过程中最关键的语义，从simulator中“提升”出来，交由软件平台统一管理。
在UCV架构下，simulator仅作为硬件设计的执行后端，负责cycle-accurate的电路仿真；而时序推进、测试用例与仿真器之间的调度、调试观测接口，全部由平台定义、实现并管理。
UCV整体分为三层：
顶层：面向用户的统一软件接口；
中间层：平台运行时，定义时序与交互语义；
底层：backend adapter，将不同simulator的行为约束在边界之内。
围绕这一架构，UCV实现了三项关键机制：
软件原生的时序与交互（XClock / XData）：将逻辑时间、采样边界、带时序语义的数据访问显式交由软件侧管理，支持在异步运行时中表达event-driven、cycle-accurate的交互；
透明的硬件-软件映射（XEvent / XSocket）：将simulator内部的硬件事件和事务类型映射为软件可见、可协调的对象，使传统VIP能与软件testbench在统一环境中协同工作；
非侵入式内省（MemD）：通过hook modules和memory direct pointers，在软件侧实现低开销的调试可观测性，避免完全依赖simulator暴露的调试接口。
三、端到端验证：以分支预测单元为例
论文以一个典型的pipelined branch predictor unit（BPU）为例，完整展示了UCV的验证流程。
BPU验证中，多个in-flight branches同时存在，一次prediction request会跨多个cycle执行，testbench需要在多个cycle间协调驱动与采样。同时，用于提供预测结果的predictor tables位于SRAM中，单靠波形很难直接查看其内部语义。
通过UCV，验证过程被组织为四个步骤：
将RTL打包为软件模块：BPU被导出为独立软件库，测试不再依赖特定simulator工程；
用异步编程方式驱动：借助XClock提供显式时间点，开发者可以将跨cycle的交互写成随时间推进的异步流程，避免在per-cycle状态机中手工维护所有中间状态；
与simulator内VIP协同：通过XEvent将VIP内部事件映射到软件侧，再经XSocket桥接事务通信，软件任务可直接与VIP协调，无需繁琐胶水代码；
直接查看SRAM表项：通过XData与MemD扩展，开发者可以直接以表项视角查看和比较predictor tables内容，而非仅靠波形反推。
最终，UCV会自动收集功能覆盖率、代码覆盖率，并生成包含failing assertions、transaction context与诊断信息的HTML报告。
四、效果：效率提升与门槛降低的双重验证
论文从性能（acceleration）和普及度（democratization）两个维度评估了UCV。
性能层面：
调试接口MemD路径相比Cocotb，最高可实现25.2倍仿真速度提升，峰值内存占用降低46%–77%；
复用传统验证组件时，基于XSocket的方案相比纯UVM baseline，运行速度提升约16.6%，验证代码量减少12%；
在大规模设计（如香山处理器）上，UCV相对纯Verilator baseline的吞吐下降不超过3%；
普及度层面：
论文围绕香山处理器开展了为期六个月的社区研究。数据显示：
UCV社区共吸引520位关注者，其中95人注册参与，25人产出可运行测试，11人累计发现30个此前未知的bug；
5位具有软件背景的本科生在2个月内确认了10个branch prediction bug，而对照组中，一位有经验的硬件工程师在5个月内发现2个可比bug；
社区参与者整体达到了98.3%的行覆盖率。
这些数据表明，software-native的组织方式，并不只是让代码“看起来更像软件”，而是真正帮助更多软件背景的开发者，参与到了有实质产出的硬件验证工作中。
五、总结：从“依附仿真器”到“软件定义验证”
这项工作的目标，并不是简单地把testbench换一种语言来写，而是将硬件验证从“软件代码依附于simulator运行”，推进到“由软件平台定义验证语义，simulator作为后端执行设计”的新阶段。
围绕这一目标，UCV从时序、事务生命周期和可观测性三个维度，重新组织了硬件验证的基础接口，并用BPU的端到端流程展示了这套方法的落地能力。
ISCA 26的录用，是对这条技术路线的一次重要认可，也是对万众一芯团队在验证基础设施方向长期投入的肯定。 我们相信，software-native的验证组织方式，能够让硬件验证变得更高效，也能让更多不同背景的开发者参与进来，共同推动开源芯片生态的发展。
万众一芯 UnityChip
“万众一芯”官网：open-verify.cc
GitHub：https://github.com/XS-MLVP/UnityChipForXiangShan
GitLink：https://www.gitlink.org.cn/XS-MLVP/UnityChipForXiangShan