资讯详情

深入了解 · 专业解读

从零搭建RISC-V验证框架：RV32I指令集验证与随机指令流生成实践

发布时间：2026/10/7 4:14:51
从零搭建RISC-V验证框架：RV32I指令集验证与随机指令流生成实践 1. 为什么我要从零搭一套RISC-V验证框架1.1 从一次流片返工说起三年前我参与过一款基于RV32I的小型嵌入式核项目当时团队觉得指令集简单验证环节就用了几个手写汇编测试凑合过去。结果流片回来发现JALR指令在特定对齐条件下跳转地址算错一个本该跑通的启动流程直接卡死。那次返工烧掉的钱和时间让我彻底明白一件事RISC-V的简洁是给硬件实现者的礼物但对验证工程师来说简洁不等于简单。RV32I只有47条指令可这47条指令之间的组合状态、流水线交互、异常触发路径展开之后是一个巨大的状态空间。后来我花了大概两个月时间从零搭了一套完整的RV32I验证框架核心思路就是用riscv-tests作为黄金参考配合自研的随机指令流生成器在指令级和流水线级两个维度同时做交叉验证。这套框架后来在我们三个不同规模的核上复用抓出了十几个手写测试根本覆盖不到的边界bug。这篇文章就把这套框架的搭建过程、关键决策点和踩过的坑完整拆一遍。1.2 这套框架到底解决什么问题说白了处理器验证要回答的核心问题就一个我设计的硬件在任意合法指令序列输入下行为是否和指令集规范完全一致。这个问题拆开来看有三层单指令语义正确性每条指令的运算结果、标志位、写回值是否符合规范定义指令间交互正确性前一条指令的副作用如寄存器写回、内存写入是否被后续指令正确感知异常与边界行为非法指令、对齐错误、溢出等场景下处理器是否进入正确的异常处理流程手写定向测试只能覆盖第一层的一部分而riscv-tests提供了标准化的参考测试集能覆盖大量单指令和基础交互场景。但riscv-tests本身也有覆盖盲区比如它不太会去测极端随机的指令交织序列。所以我的框架设计思路是三层验证叠加riscv-tests打底保证基础正确性随机指令流生成器做压力测试再加上定向的边界场景测试补齐异常路径。这套东西适合谁参考如果你正在做RV32I核的RTL设计或FPGA原型验证或者你是一个想深入理解处理器验证方法学的学生这套框架可以直接拿去改改就用。前提是你得懂基本的Verilog/SystemVerilog会用至少一种仿真器VCS、Verilator、Icarus都行对RISC-V汇编和链接脚本有基本概念。1.3 整体架构长什么样框架的顶层结构其实不复杂核心就四个模块模块职责关键产出测试激励层生成/加载测试程序驱动仿真指令流、初始化内存镜像参考模型层用软件模拟指令语义产生黄金结果寄存器/内存的期望终态比对引擎仿真结束后逐项比对DUT与参考模型差异报告、覆盖率统计覆盖率收集统计指令类型、边界条件、异常路径覆盖覆盖率数据库这里有个关键设计决策参考模型到底用现成的还是自己写。我一开始想直接用SpikeRISC-V官方ISS但Spike的集成成本不低而且它内部做了很多微架构层面的假设跟我的DUT不一定对齐。后来我选择自己写一个轻量级的RV32I解释器作为参考模型大概800行C代码只实现指令语义不涉及流水线时序。这样做的好处是完全可控出问题好定位坏处是参考模型本身也可能有bug所以我又用riscv-tests反过来验证参考模型的正确性——形成一个自洽的闭环。2. RV32I指令集验证的核心难点拆解2.1 RV32I的47条指令不是孤立的很多人看RV32I指令表觉得就是47条独立的操作验证起来应该很轻松。但实际做下来你会发现指令之间的耦合才是真正的难点。举几个我踩过的例子AUIPC指令把当前PC的高20位加上立即数写入目标寄存器这条指令单独测很简单。但当它后面紧跟一条JALR而JALR的基址寄存器正好是AUIPC写入的那个寄存器时就涉及到一个PC相关性的时序问题——如果流水线在AUIPC写回之前就取了JALR的基址值跳转地址就会错。这种场景riscv-tests里没有专门覆盖我是用随机指令流跑出来的。再比如LOAD和STORE之间的地址依赖。RV32I的load-store架构意味着所有运算都在寄存器间进行但内存访问的地址计算可能依赖前面指令的结果。如果处理器实现了store buffer或者write-back缓存就存在内存一致性的验证需求。我在一个带写缓冲的核上就遇到过连续两条store到同一地址第二条store在第一条还没提交时就覆盖了缓冲区导致最终内存里是第一条的值。这种bug用定向测试极难构造必须靠随机流。2.2 对齐与异常的边界条件RV32I规范里对内存访问的对齐要求是明确的LW/SW需要4字节对齐LH/SH需要2字节对齐LB/SB无对齐要求。但非对齐访问到底触发异常还是硬件自动处理这个在RV32I基础规范里其实是允许实现选择的。这就给验证带来了麻烦你的参考模型必须和DUT的实现选择一致否则比对结果全是误报。我的做法是在参考模型里加一个配置参数明确指定对齐策略。然后在测试激励层专门构造一批非对齐访问的用例分别验证两种策略下的行为。这里有个实操心得非对齐访问的异常触发点很微妙。有些实现是在地址计算阶段就检测对齐有些是在内存访问阶段才检测。如果你的DUT在地址计算阶段就抛异常那么异常发生时目标寄存器不应该被修改如果是在访问阶段才检测可能寄存器已经被部分写入了。这个差异在riscv-tests的ma_addr测试里有涉及但覆盖不够全面。2.3 控制流指令的验证陷阱控制流指令JAL、JALR、BEQ、BNE、BLT、BGE、BLTU、BGEU是验证的重灾区。原因在于分支预测和流水线冲刷的交互。即使你的核没有实现分支预测流水线在遇到分支指令时也需要决定是继续取指还是等待。这个决策点的时序如果不对就会出现取到错误指令或者丢失正确指令的情况。我遇到过一个经典bugJALR指令的目标地址计算用了旧PC值而不是更新后的PC值。在顺序执行模型里这不会出问题但在流水线里如果JALR前面有一条修改了基址寄存器的指令而流水线没有正确处理数据前递就会算错。riscv-tests里的jalr测试是单条指令独立测的覆盖不到这种依赖场景。还有一个容易被忽略的点分支指令的偏移量范围。RV32I的B型指令偏移量是13位有符号数范围是±4KB。JAL的偏移量是21位有符号数范围是±1MB。测试时如果只测小偏移量就可能漏掉偏移量边界值附近的编码/解码错误。我在随机生成器里专门加了偏移量边界值的定向注入。3. 用riscv-tests搭建基础验证流水线3.1 riscv-tests的目录结构和编译流程riscv-tests是RISC-V官方维护的一套测试集GitHub上直接能拉到。它的目录结构大致是这样的riscv-tests/ ├── isa/ │ ├── rv32ui/ # RV32I用户态测试 │ ├── rv32si/ # RV32I特权态测试 │ └── ... ├── benchmarks/ ├── env/ # 测试环境链接脚本、启动代码 └── Makefile编译流程的核心是链接脚本和启动代码。riscv-tests的每个测试用例都是一个独立的汇编文件编译时需要链接到特定的地址通常是0x80000000并且需要一个简单的启动代码来设置栈指针和跳转到测试入口。这个启动代码在env/目录下针对不同的测试环境p、v、u有不同的版本。我实际用的时候编译命令大概是这样# 设置工具链前缀假设你用的是标准riscv-gnu-toolchain export RISCV_PREFIXriscv64-unknown-elf- export RISCV_TESTS/path/to/riscv-tests # 编译RV32I用户态测试 cd $RISCV_TESTS/isa make XLEN32 RISCV_PREFIX$RISCV_PREFIX rv32ui编译完成后每个测试会生成一个.elf文件和一个.bin文件。.bin文件就是可以直接加载到仿真内存里的镜像。这里有个坑riscv-tests默认的链接地址是0x80000000如果你的DUT的指令内存起始地址不是这个需要改链接脚本或者做地址重映射。我一开始没注意这个仿真跑起来PC指向0x80000000但内存里全是0直接跑飞。3.2 测试结果的自检机制riscv-tests的每个测试用例内部都有一个自检逻辑测试通过时会向一个特定的内存地址通常是TESTNUM对应的地址写入特定的值然后执行一个ecall或者无限循环。仿真时你需要监控这个地址的写入值判断测试是否通过。具体来说测试用例的汇编代码里会有这样的模式# 测试通过 li a0, 0 li a7, 93 # exit syscall ecall # 测试失败 li a0, 1 li a7, 93 ecall在仿真环境里你需要拦截ecall指令检查a0寄存器的值。如果a0是0说明测试通过非0则失败a0的值通常对应失败的测试编号。我在Testbench里加了一个简单的监视器// 简化的ecall监视逻辑 always (posedge clk) begin if (dut.valid dut.instruction 32h00000073) begin // ecall编码 if (dut.regfile[10] 32d0) begin $display(TEST PASSED); $finish; end else begin $display(TEST FAILED at test %0d, dut.regfile[10]); $finish; end end end这个监视器虽然简单但非常有效。关键是要确保你拦截的是提交阶段的ecall而不是取指阶段的。如果流水线里有分支预测或者乱序执行取指阶段的ecall可能最终不会提交拦截错了就会误报。3.3 批量运行与结果汇总单个测试跑通之后下一步是批量运行所有rv32ui测试并汇总结果。我写了一个Python脚本来自动化这个过程import subprocess import os import re TEST_DIR riscv-tests/isa/rv32ui SIM_CMD vvp simv test{test_bin} results {} for test_file in os.listdir(TEST_DIR): if test_file.endswith(.bin): test_name test_file.replace(.bin, ) bin_path os.path.join(TEST_DIR, test_file) cmd SIM_CMD.format(test_binbin_path) output subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) if TEST PASSED in output.stdout: results[test_name] PASS else: results[test_name] FAIL # 提取失败信息 match re.search(rTEST FAILED at test (\d), output.stdout) if match: results[test_name] f (test {match.group(1)}) # 打印汇总 for name, result in sorted(results.items()): print(f{name:30s} {result})这个脚本跑一遍大概几分钟能快速定位哪些测试挂了。实操建议先跑通所有单指令测试如add、sub、and等再跑控制流和内存访问测试。因为单指令测试挂了说明基础数据通路有问题这时候去调控制流是浪费时间。4. 自研随机指令流生成器的设计与实现4.1 为什么riscv-tests不够用riscv-tests的测试用例是定向的、确定性的。每个测试文件针对一条或几条指令构造固定的输入检查固定的输出。这种测试的优点是结果可预测、调试方便缺点是覆盖不了指令间的随机交互。我统计过rv32ui的测试用例大概40多个文件每个文件平均测试3-5条指令。但RV32I有47条指令指令间的两两组合就有47×472209种三三组合超过10万种。定向测试根本覆盖不过来。而且很多bug只在特定的指令序列下才触发比如前面提到的AUIPCJALR依赖、连续store到同一地址等。所以我的思路是用随机生成器产生大量合法的指令序列每条指令的源寄存器、目标寄存器、立即数都随机化然后让DUT和参考模型同时执行比对最终状态。这种方法能覆盖到大量定向测试触及不到的角落。4.2 随机指令生成的核心约束随机生成不是瞎生成。RV32I的指令有严格的编码约束和语义约束生成器必须保证寄存器索引在0-31之间这个简单随机数取模就行立即数在合法范围内I型立即数12位有符号S型12位有符号B型13位有符号最低位隐含0U型20位J型21位有符号最低位隐含0内存访问地址对齐LW/SW地址必须是4的倍数LH/SH必须是2的倍数避免非法指令RV32I的指令编码空间里有很多未定义编码随机生成时不能产生这些编码我用的方法是基于指令模板的生成。为每条指令定义一个模板包含操作码、功能码、操作数类型。生成时先随机选一条指令模板再根据模板随机填充操作数。这样能保证生成的指令一定是合法的RV32I指令。# 简化的指令模板示例 INSTR_TEMPLATES [ # (name, opcode, funct3, funct7, operand_types) (ADD, 0b0110011, 0b000, 0b0000000, [rd, rs1, rs2]), (SUB, 0b0110011, 0b000, 0b0100000, [rd, rs1, rs2]), (ADDI, 0b0010011, 0b000, None, [rd, rs1, imm12]), (LW, 0b0000011, 0b010, None, [rd, rs1, imm12]), (SW, 0b0100011, 0b010, None, [rs1, rs2, imm12]), # ... 其他指令 ] def generate_instruction(): tmpl random.choice(INSTR_TEMPLATES) name, opcode, funct3, funct7, operands tmpl rd random.randint(0, 31) rs1 random.randint(0, 31) rs2 random.randint(0, 31) imm12 random.randint(-2048, 2047) # 根据模板组装机器码 # ... 编码逻辑 return encoded_instruction4.3 参考模型的实现要点参考模型是一个RV32I解释器用C写大概800行。核心是一个大switch-case根据操作码和功能码分发到不同的指令处理函数。每个处理函数更新一个模拟的寄存器堆和内存数组。实现时有几个关键点第一PC的更新逻辑要严格按规范来。RV32I的PC更新规则是默认PC4遇到分支/跳转指令时更新为目标地址。这里有个细节JAL和JALR的目标地址计算方式不同。JAL是PC立即数JALR是rs1立即数最低位清零。我在参考模型里专门写了单元测试来验证PC更新逻辑。第二内存模型要区分指令内存和数据内存。虽然RV32I是冯诺依曼架构指令和数据共享地址空间但验证时我建议分开建模。指令内存只读数据内存可读写。这样能避免自修改代码带来的复杂性——RV32I基础规范不要求支持自修改代码如果你的DUT不支持参考模型也不应该支持。第三异常处理要简化。参考模型不需要模拟完整的异常处理流程只需要在遇到非法指令或对齐错误时记录异常类型和异常PC然后停止执行。DUT那边则需要在异常发生时跳转到异常处理入口并把异常原因写入特定寄存器。比对时只比对异常类型和异常PC是否一致。4.4 比对引擎的设计比对引擎的工作是在仿真结束后把DUT的寄存器堆和内存内容读出来跟参考模型的终态逐项比对。听起来简单但实操中有几个坑坑一DUT的寄存器堆可能不是所有寄存器都能读。有些综合后的网表会把未使用的寄存器优化掉或者寄存器堆的读端口有限。我的做法是在Testbench里加一个后门访问接口直接通过层次化路径读取寄存器值。如果综合后层次化路径不可用就需要在RTL里预留调试端口。坑二内存比对的粒度。DUT的内存可能是分块的如指令RAM和数据RAM分开参考模型的内存是连续的。比对时需要按地址映射关系逐块比对。我一般只比对测试程序实际写入过的内存区域而不是全内存比对这样能减少误报。坑三浮点寄存器的处理。RV32I没有浮点指令但如果你的DUT扩展了F扩展就需要额外处理浮点寄存器。我的建议是RV32I验证阶段先不启用F扩展等基础整数指令验证通过后再单独验证浮点。比对引擎的输出是一份差异报告格式大概是Register mismatch: x5 expected0x0000000A actual0x0000000B Memory mismatch at 0x80001000: expected0xDEADBEEF actual0x00000000这份报告是调试的起点。实操心得先看PC是否一致再看寄存器最后看内存。如果PC都不一致说明控制流出了问题这时候比对寄存器和内存意义不大。5. 覆盖率驱动的验证收敛策略5.1 功能覆盖率的定义验证做到什么时候算够这个问题没有标准答案但功能覆盖率是一个可量化的指标。我为RV32I验证定义了以下几类覆盖点覆盖类型覆盖点示例目标指令覆盖每条RV32I指令至少执行一次47/47指令对覆盖每两条指令的组合至少出现一次重点组合全覆盖寄存器覆盖每个寄存器作为源/目标至少一次32×2立即数边界每条带立即数的指令测到最大/最小值边界值全覆盖异常覆盖每种异常类型至少触发一次非法指令、对齐错误等分支方向每种分支指令的taken/not-taken2×6指令覆盖是最基础的riscv-tests基本能保证。指令对覆盖是随机生成器的强项但要注意随机生成器的分布要均匀不能偏向某几条指令。我在生成器里加了权重控制确保每条指令被选中的概率大致相等。5.2 覆盖率收集的实现覆盖率收集有两种方式仿真器原生支持和自研监视器。商业仿真器如VCS自带覆盖率收集功能能自动统计行覆盖、条件覆盖、翻转覆盖等。但功能覆盖率需要自己定义covergroup。我用的是自研监视器的方式在Testbench里加一个覆盖率收集模块// 简化的指令覆盖率收集 reg [46:0] instr_coverage; // 每条指令一个bit reg [31:0] reg_src_coverage; // 每个寄存器作为源 reg [31:0] reg_dst_coverage; // 每个寄存器作为目标 always (posedge clk) begin if (dut.valid) begin // 标记指令覆盖 case (dut.opcode) 7b0110011: begin case ({dut.funct7, dut.funct3}) // ADD 10b0000000_000: instr_coverage[0] 1b1; // SUB 10b0100000_000: instr_coverage[1] 1b1; // ... endcase end // ... 其他opcode endcase // 标记寄存器覆盖 reg_src_coverage[dut.rs1] 1b1; reg_src_coverage[dut.rs2] 1b1; reg_dst_coverage[dut.rd] 1b1; end end这个模块在仿真过程中实时收集覆盖率仿真结束后dump出来分析。实操建议覆盖率收集模块本身要尽量简单不要引入额外的时序逻辑否则可能影响DUT的时序或者引入仿真伪影。5.3 覆盖率收敛的迭代流程覆盖率驱动的验证是一个迭代过程跑一轮随机测试收集覆盖率分析覆盖率报告找出未覆盖的点针对未覆盖点构造定向测试或者调整随机生成器的权重重复1-3直到覆盖率达标这个流程听起来机械但实操中最难的是判断哪些未覆盖点是真正需要覆盖的。比如某些指令对组合在语义上不可能同时出现如两条连续的ECALL强行覆盖没有意义。我的经验是优先覆盖控制流和数据流相关的组合异常路径的组合可以适当放宽。还有一个技巧用覆盖率反推随机生成器的质量。如果跑了几百万条随机指令某些指令的覆盖率还是上不去说明生成器的权重设置有问题。我一般会定期检查生成器的指令分布直方图确保没有明显的偏斜。6. 实操中踩过的坑与排查技巧6.1 仿真跑飞的第一反应仿真跑飞PC跳到非法地址或者无限循环是验证中最常见的问题。我的排查顺序是第一步看PC轨迹。在Testbench里加一个PC打印逻辑把最近N条指令的PC和指令码dump出来。如果PC突然跳到一个奇怪的地址往前看几条指令通常能找到问题指令。第二步看指令码。把问题指令的机器码和RV32I编码表对照确认编码是否正确。我遇到过好几次是汇编器生成的编码和预期不符比如LI伪指令展开成了多条指令导致PC偏移计算错误。第三步看寄存器值。如果PC跳转依赖某个寄存器的值检查这个寄存器是否被正确写入。这里要注意流水线的数据前递如果前一条指令刚写入寄存器后一条指令就读而流水线没有正确前递读到的就是旧值。第四步看内存内容。如果PC跳转依赖内存中的值如函数指针检查内存是否被正确初始化。riscv-tests的.bin文件加载到内存时要确保加载地址和链接地址一致。6.2 比对结果不一致的定位方法DUT和参考模型比对不一致时定位方法取决于不一致的类型寄存器不一致先看是哪个寄存器然后回溯这个寄存器最近被哪条指令写入。如果写入指令是LOAD检查内存地址和内存内容如果是算术指令检查源寄存器和立即数。内存不一致先看是哪个地址然后回溯这个地址最近被哪条STORE指令写入。检查STORE的源寄存器值和地址计算。PC不一致这个最麻烦因为PC不一致通常意味着控制流已经分叉了。我的做法是在参考模型里记录每条指令执行后的PC然后跟DUT的PC轨迹逐条比对找到第一个分叉点。这里有个实操技巧在参考模型里加一个单步模式每执行一条指令就暂停等待外部输入继续。这样可以在PC分叉点精确暂停然后逐条检查DUT和参考模型的状态差异。6.3 常见问题速查表现象可能原因排查方法仿真一开始就跑飞内存未初始化或加载地址错误检查.bin加载地址和链接地址单指令测试通过组合测试失败数据前递或流水线冒险检查前递逻辑和冒险检测分支指令结果随机分支条件计算错误或PC更新时序检查分支比较器和PC mux内存访问异常不触发对齐检测逻辑缺失或异常入口错误检查对齐检测和异常向量表覆盖率长时间不增长随机生成器权重偏斜检查指令分布直方图参考模型和DUT同时挂参考模型本身有bug用riscv-tests验证参考模型6.4 几个独家避坑技巧技巧一用NOP指令做流水线隔离。在构造定向测试时如果两条指令之间有依赖关系可以在中间插入几条NOPADDI x0, x0, 0观察依赖是否消失。如果插入NOP后测试通过说明是流水线冒险问题如果仍然失败说明是指令语义问题。技巧二用CSR指令做状态快照。虽然RV32I基础规范不包含CSR指令但如果你的DUT实现了Zicsr扩展可以用CSRR指令在测试过程中读取内部状态寄存器如周期计数、指令计数帮助定位问题发生的精确时刻。技巧三随机生成器的种子要记录。每次随机测试失败时把随机种子打印出来。这样可以用同一个种子复现失败场景方便调试。我一般会在Testbench里加一个$plusargs来传入种子initial begin if (!$value$plusargs(SEED%d, seed)) begin seed 12345; // 默认种子 end $display(Random seed: %0d, seed); end技巧四参考模型的日志要详细。参考模型每执行一条指令打印PC、指令码、源寄存器值、目标寄存器值。这样当DUT和参考模型分叉时可以直接看参考模型的日志知道正确行为应该是什么。技巧五不要迷信riscv-tests的通过。riscv-tests的测试用例本身也可能有bug或者它的预期行为跟你的DUT实现选择不一致。我遇到过ma_addr测试在某个DUT上失败查了半天发现是测试用例假设了某种对齐策略而DUT选择了另一种。这种情况下以规范为准而不是以测试为准。7. 框架的扩展与复用7.1 从RV32I扩展到RV32IMRV32I验证框架搭好之后扩展到RV32IM加上乘除法扩展其实很自然。M扩展增加了8条指令MUL、MULH、MULHSU、MULHU、DIV、DIVU、REM、REMU。扩展步骤在参考模型里增加这8条指令的处理函数在随机生成器的指令模板里增加这8条指令在覆盖率收集模块里增加对应的覆盖点用riscv-tests的rv32um测试集验证M扩展的验证难点在于乘除法的边界条件。比如DIV指令除以0的结果规范定义是-1所有位为1而不是异常。REM指令除以0的结果是被除数本身。这些边界条件在随机测试中不容易触发需要定向构造。7.2 从指令级验证到流水线级验证指令级验证关注的是指令执行的结果流水线级验证关注的是指令执行的时序。两者互补但流水线级验证更难做。我的做法是在指令级验证通过后增加时序断言。比如一条指令从取指到写回最多经过N个周期分支指令在提交之前后续指令不应该修改 architectural state异常指令在提交之前不应该产生副作用这些断言用SystemVerilog AssertionSVA写在仿真过程中实时检查。SVA的优点是能在问题发生的精确时刻报错而不是等到仿真结束比对时才发现。7.3 框架复用到不同DUT的注意事项这套框架我在三个不同规模的核上复用每次复用的适配工作量大概几天到一周。主要适配点内存映射不同DUT的指令内存和数据内存起始地址可能不同需要改链接脚本和Testbench的内存加载逻辑。寄存器堆接口不同DUT的寄存器堆读端口数量不同后门访问的层次化路径也不同。如果DUT没有预留调试端口可能需要在RTL里临时加一个。异常处理入口不同DUT的异常向量表地址不同异常原因寄存器的编码也可能不同。参考模型需要根据DUT的实现调整异常处理逻辑。仿真器接口如果从VCS换到VerilatorTestbench的接口需要重写。Verilator不支持SystemVerilog的某些特性如$finish的某些用法需要做适配。我的经验是框架的核心逻辑参考模型、比对引擎、覆盖率收集尽量用C/Python写跟仿真器解耦。Testbench只负责驱动仿真和dump数据数据处理全部在外部脚本里做。这样换仿真器时只需要改Testbench核心逻辑不用动。7.4 后续可以继续深挖的方向这套框架目前覆盖了RV32I的基础验证但还有几个方向可以继续深挖形式化验证用形式化工具如SymbiYosys对关键模块如ALU、分支比较器做等价性检查。形式化验证能覆盖所有可能的输入组合是对仿真的有力补充。故障注入在RTL里注入故障如位翻转验证处理器的容错能力。这个方向对安全关键应用很重要。性能验证除了功能正确性处理器的性能如CPI、分支预测准确率也需要验证。这需要在Testbench里增加性能计数器。多核一致性如果DUT是多核的还需要验证缓存一致性协议。这个复杂度比单核验证高一个数量级。我个人在实际操作中的体会是验证框架的价值不在于一次性能抓多少bug而在于能不能持续、可重复地跑。一套好的框架应该能集成到CI流程里每次RTL变更后自动跑一遍回归测试。我现在的做法是用Jenkins做持续集成每次代码提交触发一轮riscv-tests加随机测试覆盖率报告自动生成。这样虽然前期投入大但长期来看省下的调试时间远超投入。最后分享一个小技巧随机测试的种子要定期更换但失败的种子要永久保留。我维护了一个失败种子库每次发现新bug就把种子加进去回归测试时优先跑这些种子。这样能确保已修复的bug不会重新引入。

相关新闻