很多刚开始用Verilator的朋友第一次看到生成的C代码里满屏的vluint32_t、CData、eval_step这类东西都会有点懵。前面几篇我们把环境搭好、跑通了第一个模型这篇要聊的访问函数就是让你在C testbench里真正“摸到”DUT内部信号的那道桥。说白了Verilator把Verilog/SystemVerilog代码翻译成C类之后你需要在C侧给输入端口赋值、读取输出端口、推进仿真时间、检测结束条件这些操作全部依赖访问函数来完成。理解清楚这一层以后写Verilator的testbench就会顺手很多。这篇内容我按实际使用频率来组织先讲信号在C模型里是怎么表示的再讲读写信号的核心套路然后给一个可以直接跑的计数器例子最后说说数组、内部信号和踩过的坑。适合已经能跑通Verilator基础编译流程、想进一步提升仿真编写效率的读者。1. 访问函数到底在访问什么1.1 从Verilog到C模型信号变成了对象成员先明确一个基本概念Verilator不是像ModelSim那样维护一个事件驱动的仿真器它是把Verilog代码“翻译”成C代码。你的module counter会被编译成一个类名字通常是Vcounter这类带V前缀的形式顶层模块的所有端口会变成这个类的公有成员变量。所以你在testbench里做top-clk 1本质上是在给一个C对象的公有成员赋值做printf(%d, top-count)是在读取这个成员的当前值。这种设计的好处是访问开销极低仿真性能和C原生代码几乎一样这也是Verilator在大型SoC仿真里能跑得飞快的原因之一。用代码来说假设有这样一个RTLmodule counter( input logic clk, input logic rst_n, output logic [7:0] count ); always_ff (posedge clk or negedge rst_n) begin if (!rst_n) count 8h0; else count count 1; end endmodule用verilator --cc --exe --build编译生成C模型之后你会在生成的Vcounter.h里看到大概这样的声明class Vcounter { public: IData/*8*/ count; // 对应 output [7:0] count };这个count就是访问函数的基础形态。你在testbench里读它得到的就是仿真当前时刻该信号的逻辑值。需要特别注意的是端口信号对应成员变量的类型跟你在Verilog里写的位宽有关系这个下一小节细讲。1.2 信号类型系统CData到WData怎么选Verilator为了在C里表达不同位宽的Verilog信号定义了一套类型体系。这部分看起来琐碎但绕不过去因为你无论是读信号还是写信号赋值和比较都会涉及类型匹配。常用的几个类型对应关系如下C类型Verilog位宽说明CData[7:0]以内通常对应uint8_tSData[15:0]以内对应uint16_tIData[31:0]以内对应uint32_t最常见QData[63:0]以内对应uint64_tWData超过64位实际是个数组配合VlWideN使用加了vlu前缀的类型名在老版本和底层函数里很常见比如vluint32_t就是无符号32位整数和IData基本是一回事。实际使用中有几个很容易踩的点CData只有8位但你如果用printf(%d, top-count)打印一个CData类型会被默认整型提升一般没问题。可如果信号位宽超过8位比如[15:0]它对应SData你用printf(%d, top-count)也基本没问题因为SData会提升为int。读高阻和不定值时要小心四态值在Verilator里被映射成两态X和Z会被编码成特殊值或按0处理这一点跟事件驱动仿真器差别很大。写testbench时不要依赖对X的传播检测Verilator默认不做这种检查。位宽超过64位的信号访问方式不再是一个简单变量而是一个VlWide类型赋值要用VL_SET_W这类宏或者通过数组逐字操作。实际项目里80位、128位的数据总线不罕见遇到的时候先别慌查一下生成头文件里对应的类型再动手。1.3 找到你想访问的信号顶层端口、内部信号与--public端口信号是最好访问的直接top-信号名就行。但有时候你想看的不止顶层端口还想观察内部某个寄存器的中间值比如上面计数器里的count_next这类内部节点这就麻烦了。默认情况下Verilator只会把顶层模块的端口暴露成公有成员内部信号都是静态或私有状态C侧碰不到。想把内部信号也暴露出来编译时要加--public选项。加了之后内部信号会以__PVT__为前缀的方式出现在模型类里命名通常是vlSelf-__PVT__信号名这样的路径。举例来说verilator --cc --exe --build --public top.sv sim_main.cpp然后在C代码里就能通过类似top-rootp()-__PVT__counter__DOT__count_next的方式去访问内部节点。注意这里和Verilator版本有关系老版本路径前缀可能不一样我常用的做法是先打开生成的.h文件搜一下信号名确认实际符号名再写代码比背诵命名规则靠谱。如果你的目的是调试和看波形那其实用不到--public直接开--trace并调用trace()函数把所有信号都导进VCD文件然后在GTKWave里看就行。--public主要用于你确实需要在C侧实时读取某内部信号做校验比如进行软件和硬件协同时。2. 读写信号的核心操作套路2.1 驱动激励写信号后必须eval访问函数最基础的使用场景是给DUT灌激励。做法很直白top-rst_n 0; top-clk 0; top-eval();但这里有个新手必踩的坑赋值之后如果不调用eval()你赋的值不会立即影响DUT内部的逻辑。eval()的作用是让Verilator模型的组合逻辑重新计算、时序逻辑按当前状态更新相当于把C世界的信号变更“同步”到仿真模型内部。我见过很多刚开始用Verilator的人写testbench给端口赋完值就直接读输出结果发现结果完全不对然后怀疑是编译问题。大概率就是没调eval()或者调用的时机不对。更准确地说eval()应该在你“改变了任何输入信号之后、想要让组合逻辑和时序逻辑朝下推进时”调用。比如要给计数器一个上升沿至少要这么做top-clk 0; top-eval(); top-clk 1; top-eval();每次信号变化后都进行一次计算这样才能让DUT内部状态正确推进。2.2 采样输出读信号的最佳时机读信号相对简单直接读取就行但时机比语法更重要。同步时序电路里输出通常在时钟沿之后更新所以你的采样点要避开时钟沿前后那个“危险窗口”。比较稳妥的写法是先置好输入激励然后eval()让模型计算等时钟翻转并eval()之后、进入下一个阶段之前再读取输出。我平时习惯这样组织testbench主循环逻辑比较清晰top-rst_n 1; for (int i 0; i 100; i) { contextp-timeInc(10); top-clk 1; top-eval(); // 这里是时钟上升沿之后可以采样 printf(count %d\n, top-count); contextp-timeInc(10); top-clk 0; top-eval(); }这里稍微解释下timeInc(10)它让仿真时间推进10个时间单位。只调timeInc而不调eval时间戳变了但模型状态没变所以最好每次改时间或改信号后都跟着一次eval()这样模型状态和仿真时间才会对齐。关于读取输出还有个小细节如果信号是QData你直接printf(%ld, top-count)在某些平台上有格式警告建议用printf(% PRIu64, top-count)这种可移植写法避免踩到格式符的坑。2.3 时钟与复位访问函数配合时序控制时钟是同步仿真的核心而在Verilator里没有像$clocking那样内置的时钟对象需要你自己在C侧生成。比较常见的做法有几种第一种是裸翻转top-clk !top-clk; top-eval();第二种是配合循环时间控制for (int cycle 0; cycle 10; cycle) { contextp-timeInc(5); top-clk 1; top-eval(); contextp-timeInc(5); top-clk 0; top-eval(); }这是最典型的时钟生成方式。对于复位信号我习惯在一开始把所有输入都置为无效值再拉复位多跑几个周期确保DUT完全进入确定状态top-clk 0; top-rst_n 0; top-eval(); for (int i 0; i 3; i) { contextp-timeInc(10); top-clk 1; top-eval(); contextp-timeInc(10); top-clk 0; top-eval(); } top-rst_n 1; top-eval();注意复位释放的时机我一般放在某个时钟沿之后而不是之前不然容易在第一个上升沿时复位还没完全释放导致时序边界模糊。2.4 新版API变化eval_step与eval_end_step如果你用的是Verilator 5.x会发现生成的模型里eval()被拆成了eval_step()和eval_end_step()两个函数。这背后的原因是新版为了支持更精确的多相位仿真比如较复杂的时钟分频和异步逻辑eval_step负责计算当前步进的组合逻辑和主时钟逻辑eval_end_step负责收尾处理那些需要延迟一拍更新的信号。实际写testbench时直接用eval()在很多情况下也可以工作但官方推荐的方式是top-eval_step(); top-eval_end_step();两者要成对调用单独只调一个会导致部分更新逻辑没执行完输出可能不对。我一开始从旧版本切到新版时没注意这个区别浪费了不少时间排查一个看起来毫无规律的信号取值问题后来把eval()全部换成这一对函数之后问题就消失了。如果你自己写的是一个比较简单的组合逻辑或基础时序电路旧式eval()用起来问题不大但既然上了5.x建议一次到位直接适应新版写法省得以后迁移代码。3. 一个能直接跑的示例计数器验证3.1 RTL与testbench骨架刚才已经提到了counter这个RTL现在把它补全做一个稍微完整一点的可运行示例。RTL部分还是一个8位计数器带同步复位和使能端口module counter( input logic clk, input logic rst_n, input logic en, output logic [7:0] count ); always_ff (posedge clk) begin if (!rst_n) count 8h0; else if (en) count count 1; end endmoduletestbench这边用C写完整代码大概长这样#include cstdio #include verilated.h #include Vcounter.h vluint64_t sim_time 0; int main(int argc, char** argv) { VerilatedContext* contextp new VerilatedContext; contextp-commandArgs(argc, argv); Vcounter* top new Vcounter; top-clk 0; top-rst_n 0; top-en 1; top-eval(); // 先复位5个周期 for (int i 0; i 5; i) { contextp-timeInc(10); top-clk 1; top-eval(); contextp-timeInc(10); top-clk 0; top-eval(); } // 释放复位观察计数 top-rst_n 1; for (int cycle 0; cycle 20; cycle) { contextp-timeInc(10); top-clk 1; top-eval(); printf(cycle %02d, count %u\n, cycle, top-count); contextp-timeInc(10); top-clk 0; top-eval(); } top-final(); delete top; delete contextp; return 0; }编译命令用一行搞定verilator --cc --exe --build --trace -j 4 counter.sv sim_main.cpp--trace是为了顺便生成VCD波形调试的时候非常有用。如果你不需要波形把--trace去掉即可纯功能仿真速度会更快。3.2 编译仿真与波形查看编译过程正常的话会在obj_dir目录下生成可执行文件Vcounter直接运行./obj_dir/Vcounter就能看到20个周期的计数输出cycle 00, count 0 cycle 01, count 1 cycle 02, count 2 ...这里有个容易疑惑的点为什么cycle 00时count是0而不是1因为always_ff里的非阻塞赋值在时钟上升沿生效testbench里的printf是紧跟top-clk 1; top-eval();之后执行的此时计数器刚采样到使能信号还没完成加一所以读到的是加一前的旧值。等下一个周期count才变为1。如果开了--trace仿真目录下会生成counter.vcd用GTKWave打开就能看到clk、rst_n、en、count的完整波形。这一步对确认时序关系非常有帮助特别是你想验证en信号是否在正确的时间窗口内生效。3.3 从示例总结访问函数使用模板这个例子虽然简单但已经覆盖了访问函数最核心的知识点。我把它归纳成一个通用模板以后写更复杂的testbench时可以照着往上套创建上下文和顶层模型对象。给所有输入端口赋初始值包括时钟、复位、使能等然后eval()。生成时钟top-clk 1; eval(); top-clk 0; eval();每一拍之前用timeInc()推进仿真时间。在需要的时间点修改其他输入信号先赋值再eval()保证RTL看到的是新值。读取你关心的输出信号打印或做断言。仿真结束时调用top-final()释放对象。这个模板对大多数中小型模块都适用。我自己做模块级验证时基本就是这个套路只是会把时钟生成和复位序列封装成更易用的小函数让testbench阅读起来更接近行为级。4. 访问内部信号与复杂结构4.1 数组、存储器与Wide信号端口信号里如果带数组维度访问函数会变成类似C数组的形式。比如RTL里声明logic [7:0] mem [0:3];那么生成的模型里可能对应VlUnpackedIData, 4 mem访问方式是top-mem[0] 8hAA; uint8_t val top-mem[2];这种和一维数组很像区别在于VlUnpacked是个模板包装类型内部存储了多个元素你需要把它当数组用。对于超过64位的大位宽信号比如256位的哈希计算块访问方式就得用VlWide。实际使用中赋值往往通过VL_SET_W这类宏不过如果你用SystemVerilog的logic [255:0]端口并且testbench不关心精确每一位可以用top-数据信号配合小段打印或者干脆把大位宽信号分成多段来检查在验证时反而更直观。4.2 层次化内部信号怎么读有些场景需要读内部信号比如你想确认FIFO的空满状态寄存器是否按预期翻转而这些信号没有引到顶层。这时候用--public编译选项把内部信号暴露出来是标准做法。编译命令verilator --cc --exe --build --public counter.sv sim_main.cpp然后去生成的Vcounter.h里搜索信号名可以看到类似这样// 可能是这种形式 vlSelf-__PVT__train访问时通过top-rootp()拿到根节点指针再逐层往下uint9_t val top-rootp()-__PVT__train;不同的Verilator版本内部符号的命名和访问方式可能会有差异所以最稳妥的办法永远是先看一眼生成的头文件确认类型和名字再写访问代码。这一点和经验无关纯粹是因为Verilator的迭代节奏比较快依赖记忆容易翻车。需要说一句的是用--public会增加模型生成的复杂度和仿真开销尽量只对确实需要访问的内部信号所在的模块开启不要整个工程无脑加。4.3 通过trace回调走查信号变化另一种“访问”信号的方式是通过trace把信号变化记录下来。Verilator提供trace()接口你可以在testbench里这样启用#include verilated_vcd_c.h Verilated::traceEverOn(true); VerilatedVcdC* tfp new VerilatedVcdC; top-trace(tfp, 99); tfp-open(counter.vcd);然后在每个状态更新后调用tfp-dump(contextp-time());最后结束时tfp-close()。这种方式的好处是无需为每个信号写访问代码所有信号都进波形适合定位问题时先看整体波形再决定要不要深挖某个内部节点。对我来说trace更多是一种“全局视野”访问函数则是“定点狙击”两者配合使用效率最高。5. 常见问题与排查技巧5.1 现象与定位表格把我在实际使用中遇到最多的问题整理成一个表方便快速对照现象可能原因处理方式赋值后输出不变没调eval()或eval_step/end_step不配对修改信号后务必调用对应计算函数仿真时间一直为0调了eval()但没调timeInc()每个时钟周期前用timeInc()推进时间VCD波形为空没调Verilated::traceEverOn(true)或dump时机不对仿真开始时开启trace更新信号后调用tfp-dump()top-xx编译报错找不到成员该信号是内部信号或生成的符号名不同加--public查看头文件确认信号名printf打印出奇怪的大数类型匹配错误比如QData用了%d用PRIu64等可移植格式符读取输出总是慢一拍testbench采样时机过早在clk1并eval()之后再采样这些现象和原因之间并非一一对应遇到问题建议先对照这个表做一轮快速过滤再结合波形确认。5.2 几个我踩过的坑说几个比较有代表性的踩坑经历。第一次用Verilator做异步复位逻辑验证时我的testbench里给rst_n赋值后只调了一次eval()然后直接进入主循环。结果复位释放后计数器从不定值开始计数花了大半天排查最后发现是复位释放的瞬间和时钟上升沿刚好重合导致时序竞争。解决办法是确保复位释放发生在时钟低电平区间并且释放后先eval()一下让DUT完全稳定再继续跑。另一个坑是gotFinish()的使用。如果RTL里有$finishVerilator会设置上下文里的结束标志。testbench主循环如果没有检查contextp-gotFinish()就会一直跑下去看起来像是仿真卡死了。正确做法是在循环条件里加上对gotFinish()的判断while (!contextp-gotFinish() cycle MAX_CYCLE) { // 时钟与eval }还有一个非常隐蔽的问题在同一个eval()之前连续修改多个输入信号Verilator只会在调用eval()时统一计算所以中间某次赋值不会立即更新输出。这是正常的不是bug。你把testbench想象成一块电路板信号最终稳定后的值才是有效激励中间抖动不影响最终逻辑。5.3 调试建议最后给三条使用访问函数的建议都是实战换来的经验。第一条多用断言辅助。光靠printf打印输出在信号多的时候根本看不过来。我习惯在每个关键检查点写一个简单的assert宏封装把期望值和实际值对比一旦不匹配就直接退出并打印出错位置。用Verilator跑断言本质上和UVM里的scoreboard功能类似只是少了封装但胜在轻量直接。第二条波形永远是最快的定位手段。访问函数用来执行和检查结果波形用来确认中间时序。两者缺一不可在调试比较复杂的握手协议时尤其明显。我经常是先在VCD波形里看到异常信号再回到C代码里调整激励序列。第三条保持testbench结构清晰。访问函数写多了之后testbench容易变成一大坨赋值和eval()的堆砌。建议把时钟生成、复位序列、单周期激励这些动作封装成独立函数让主循环看起来像一份“测试用例清单”。这样不仅好维护出问题时也能快速定位是哪个环节写错了。Verilator的访问函数体系刚接触时确实有点绕但只要理解了信号成员类型、eval调用时机、时间推进这三件事后面基本就是熟能生巧。上面这些内容覆盖了我在模块级验证里90%以上的日常使用场景按这个思路去写testbench应该能少踩不少坑。
很多刚开始用Verilator的朋友第一次看到生成的C代码里满屏的vluint32_t、CData、eval_step这类东西都会有点懵。前面几篇我们把环境搭好、跑通了第一个模型这篇要聊的访问函数就是让你在C testbench里真正“摸到”DUT内部信号的那道桥。说白了Verilator把Verilog/SystemVerilog代码翻译成C类之后你需要在C侧给输入端口赋值、读取输出端口、推进仿真时间、检测结束条件这些操作全部依赖访问函数来完成。理解清楚这一层以后写Verilator的testbench就会顺手很多。这篇内容我按实际使用频率来组织先讲信号在C模型里是怎么表示的再讲读写信号的核心套路然后给一个可以直接跑的计数器例子最后说说数组、内部信号和踩过的坑。适合已经能跑通Verilator基础编译流程、想进一步提升仿真编写效率的读者。1. 访问函数到底在访问什么1.1 从Verilog到C模型信号变成了对象成员先明确一个基本概念Verilator不是像ModelSim那样维护一个事件驱动的仿真器它是把Verilog代码“翻译”成C代码。你的module counter会被编译成一个类名字通常是Vcounter这类带V前缀的形式顶层模块的所有端口会变成这个类的公有成员变量。所以你在testbench里做top-clk 1本质上是在给一个C对象的公有成员赋值做printf(%d, top-count)是在读取这个成员的当前值。这种设计的好处是访问开销极低仿真性能和C原生代码几乎一样这也是Verilator在大型SoC仿真里能跑得飞快的原因之一。用代码来说假设有这样一个RTLmodule counter( input logic clk, input logic rst_n, output logic [7:0] count ); always_ff (posedge clk or negedge rst_n) begin if (!rst_n) count 8h0; else count count 1; end endmodule用verilator --cc --exe --build编译生成C模型之后你会在生成的Vcounter.h里看到大概这样的声明class Vcounter { public: IData/*8*/ count; // 对应 output [7:0] count };这个count就是访问函数的基础形态。你在testbench里读它得到的就是仿真当前时刻该信号的逻辑值。需要特别注意的是端口信号对应成员变量的类型跟你在Verilog里写的位宽有关系这个下一小节细讲。1.2 信号类型系统CData到WData怎么选Verilator为了在C里表达不同位宽的Verilog信号定义了一套类型体系。这部分看起来琐碎但绕不过去因为你无论是读信号还是写信号赋值和比较都会涉及类型匹配。常用的几个类型对应关系如下C类型Verilog位宽说明CData[7:0]以内通常对应uint8_tSData[15:0]以内对应uint16_tIData[31:0]以内对应uint32_t最常见QData[63:0]以内对应uint64_tWData超过64位实际是个数组配合VlWideN使用加了vlu前缀的类型名在老版本和底层函数里很常见比如vluint32_t就是无符号32位整数和IData基本是一回事。实际使用中有几个很容易踩的点CData只有8位但你如果用printf(%d, top-count)打印一个CData类型会被默认整型提升一般没问题。可如果信号位宽超过8位比如[15:0]它对应SData你用printf(%d, top-count)也基本没问题因为SData会提升为int。读高阻和不定值时要小心四态值在Verilator里被映射成两态X和Z会被编码成特殊值或按0处理这一点跟事件驱动仿真器差别很大。写testbench时不要依赖对X的传播检测Verilator默认不做这种检查。位宽超过64位的信号访问方式不再是一个简单变量而是一个VlWide类型赋值要用VL_SET_W这类宏或者通过数组逐字操作。实际项目里80位、128位的数据总线不罕见遇到的时候先别慌查一下生成头文件里对应的类型再动手。1.3 找到你想访问的信号顶层端口、内部信号与--public端口信号是最好访问的直接top-信号名就行。但有时候你想看的不止顶层端口还想观察内部某个寄存器的中间值比如上面计数器里的count_next这类内部节点这就麻烦了。默认情况下Verilator只会把顶层模块的端口暴露成公有成员内部信号都是静态或私有状态C侧碰不到。想把内部信号也暴露出来编译时要加--public选项。加了之后内部信号会以__PVT__为前缀的方式出现在模型类里命名通常是vlSelf-__PVT__信号名这样的路径。举例来说verilator --cc --exe --build --public top.sv sim_main.cpp然后在C代码里就能通过类似top-rootp()-__PVT__counter__DOT__count_next的方式去访问内部节点。注意这里和Verilator版本有关系老版本路径前缀可能不一样我常用的做法是先打开生成的.h文件搜一下信号名确认实际符号名再写代码比背诵命名规则靠谱。如果你的目的是调试和看波形那其实用不到--public直接开--trace并调用trace()函数把所有信号都导进VCD文件然后在GTKWave里看就行。--public主要用于你确实需要在C侧实时读取某内部信号做校验比如进行软件和硬件协同时。2. 读写信号的核心操作套路2.1 驱动激励写信号后必须eval访问函数最基础的使用场景是给DUT灌激励。做法很直白top-rst_n 0; top-clk 0; top-eval();但这里有个新手必踩的坑赋值之后如果不调用eval()你赋的值不会立即影响DUT内部的逻辑。eval()的作用是让Verilator模型的组合逻辑重新计算、时序逻辑按当前状态更新相当于把C世界的信号变更“同步”到仿真模型内部。我见过很多刚开始用Verilator的人写testbench给端口赋完值就直接读输出结果发现结果完全不对然后怀疑是编译问题。大概率就是没调eval()或者调用的时机不对。更准确地说eval()应该在你“改变了任何输入信号之后、想要让组合逻辑和时序逻辑朝下推进时”调用。比如要给计数器一个上升沿至少要这么做top-clk 0; top-eval(); top-clk 1; top-eval();每次信号变化后都进行一次计算这样才能让DUT内部状态正确推进。2.2 采样输出读信号的最佳时机读信号相对简单直接读取就行但时机比语法更重要。同步时序电路里输出通常在时钟沿之后更新所以你的采样点要避开时钟沿前后那个“危险窗口”。比较稳妥的写法是先置好输入激励然后eval()让模型计算等时钟翻转并eval()之后、进入下一个阶段之前再读取输出。我平时习惯这样组织testbench主循环逻辑比较清晰top-rst_n 1; for (int i 0; i 100; i) { contextp-timeInc(10); top-clk 1; top-eval(); // 这里是时钟上升沿之后可以采样 printf(count %d\n, top-count); contextp-timeInc(10); top-clk 0; top-eval(); }这里稍微解释下timeInc(10)它让仿真时间推进10个时间单位。只调timeInc而不调eval时间戳变了但模型状态没变所以最好每次改时间或改信号后都跟着一次eval()这样模型状态和仿真时间才会对齐。关于读取输出还有个小细节如果信号是QData你直接printf(%ld, top-count)在某些平台上有格式警告建议用printf(% PRIu64, top-count)这种可移植写法避免踩到格式符的坑。2.3 时钟与复位访问函数配合时序控制时钟是同步仿真的核心而在Verilator里没有像$clocking那样内置的时钟对象需要你自己在C侧生成。比较常见的做法有几种第一种是裸翻转top-clk !top-clk; top-eval();第二种是配合循环时间控制for (int cycle 0; cycle 10; cycle) { contextp-timeInc(5); top-clk 1; top-eval(); contextp-timeInc(5); top-clk 0; top-eval(); }这是最典型的时钟生成方式。对于复位信号我习惯在一开始把所有输入都置为无效值再拉复位多跑几个周期确保DUT完全进入确定状态top-clk 0; top-rst_n 0; top-eval(); for (int i 0; i 3; i) { contextp-timeInc(10); top-clk 1; top-eval(); contextp-timeInc(10); top-clk 0; top-eval(); } top-rst_n 1; top-eval();注意复位释放的时机我一般放在某个时钟沿之后而不是之前不然容易在第一个上升沿时复位还没完全释放导致时序边界模糊。2.4 新版API变化eval_step与eval_end_step如果你用的是Verilator 5.x会发现生成的模型里eval()被拆成了eval_step()和eval_end_step()两个函数。这背后的原因是新版为了支持更精确的多相位仿真比如较复杂的时钟分频和异步逻辑eval_step负责计算当前步进的组合逻辑和主时钟逻辑eval_end_step负责收尾处理那些需要延迟一拍更新的信号。实际写testbench时直接用eval()在很多情况下也可以工作但官方推荐的方式是top-eval_step(); top-eval_end_step();两者要成对调用单独只调一个会导致部分更新逻辑没执行完输出可能不对。我一开始从旧版本切到新版时没注意这个区别浪费了不少时间排查一个看起来毫无规律的信号取值问题后来把eval()全部换成这一对函数之后问题就消失了。如果你自己写的是一个比较简单的组合逻辑或基础时序电路旧式eval()用起来问题不大但既然上了5.x建议一次到位直接适应新版写法省得以后迁移代码。3. 一个能直接跑的示例计数器验证3.1 RTL与testbench骨架刚才已经提到了counter这个RTL现在把它补全做一个稍微完整一点的可运行示例。RTL部分还是一个8位计数器带同步复位和使能端口module counter( input logic clk, input logic rst_n, input logic en, output logic [7:0] count ); always_ff (posedge clk) begin if (!rst_n) count 8h0; else if (en) count count 1; end endmoduletestbench这边用C写完整代码大概长这样#include cstdio #include verilated.h #include Vcounter.h vluint64_t sim_time 0; int main(int argc, char** argv) { VerilatedContext* contextp new VerilatedContext; contextp-commandArgs(argc, argv); Vcounter* top new Vcounter; top-clk 0; top-rst_n 0; top-en 1; top-eval(); // 先复位5个周期 for (int i 0; i 5; i) { contextp-timeInc(10); top-clk 1; top-eval(); contextp-timeInc(10); top-clk 0; top-eval(); } // 释放复位观察计数 top-rst_n 1; for (int cycle 0; cycle 20; cycle) { contextp-timeInc(10); top-clk 1; top-eval(); printf(cycle %02d, count %u\n, cycle, top-count); contextp-timeInc(10); top-clk 0; top-eval(); } top-final(); delete top; delete contextp; return 0; }编译命令用一行搞定verilator --cc --exe --build --trace -j 4 counter.sv sim_main.cpp--trace是为了顺便生成VCD波形调试的时候非常有用。如果你不需要波形把--trace去掉即可纯功能仿真速度会更快。3.2 编译仿真与波形查看编译过程正常的话会在obj_dir目录下生成可执行文件Vcounter直接运行./obj_dir/Vcounter就能看到20个周期的计数输出cycle 00, count 0 cycle 01, count 1 cycle 02, count 2 ...这里有个容易疑惑的点为什么cycle 00时count是0而不是1因为always_ff里的非阻塞赋值在时钟上升沿生效testbench里的printf是紧跟top-clk 1; top-eval();之后执行的此时计数器刚采样到使能信号还没完成加一所以读到的是加一前的旧值。等下一个周期count才变为1。如果开了--trace仿真目录下会生成counter.vcd用GTKWave打开就能看到clk、rst_n、en、count的完整波形。这一步对确认时序关系非常有帮助特别是你想验证en信号是否在正确的时间窗口内生效。3.3 从示例总结访问函数使用模板这个例子虽然简单但已经覆盖了访问函数最核心的知识点。我把它归纳成一个通用模板以后写更复杂的testbench时可以照着往上套创建上下文和顶层模型对象。给所有输入端口赋初始值包括时钟、复位、使能等然后eval()。生成时钟top-clk 1; eval(); top-clk 0; eval();每一拍之前用timeInc()推进仿真时间。在需要的时间点修改其他输入信号先赋值再eval()保证RTL看到的是新值。读取你关心的输出信号打印或做断言。仿真结束时调用top-final()释放对象。这个模板对大多数中小型模块都适用。我自己做模块级验证时基本就是这个套路只是会把时钟生成和复位序列封装成更易用的小函数让testbench阅读起来更接近行为级。4. 访问内部信号与复杂结构4.1 数组、存储器与Wide信号端口信号里如果带数组维度访问函数会变成类似C数组的形式。比如RTL里声明logic [7:0] mem [0:3];那么生成的模型里可能对应VlUnpackedIData, 4 mem访问方式是top-mem[0] 8hAA; uint8_t val top-mem[2];这种和一维数组很像区别在于VlUnpacked是个模板包装类型内部存储了多个元素你需要把它当数组用。对于超过64位的大位宽信号比如256位的哈希计算块访问方式就得用VlWide。实际使用中赋值往往通过VL_SET_W这类宏不过如果你用SystemVerilog的logic [255:0]端口并且testbench不关心精确每一位可以用top-数据信号配合小段打印或者干脆把大位宽信号分成多段来检查在验证时反而更直观。4.2 层次化内部信号怎么读有些场景需要读内部信号比如你想确认FIFO的空满状态寄存器是否按预期翻转而这些信号没有引到顶层。这时候用--public编译选项把内部信号暴露出来是标准做法。编译命令verilator --cc --exe --build --public counter.sv sim_main.cpp然后去生成的Vcounter.h里搜索信号名可以看到类似这样// 可能是这种形式 vlSelf-__PVT__train访问时通过top-rootp()拿到根节点指针再逐层往下uint9_t val top-rootp()-__PVT__train;不同的Verilator版本内部符号的命名和访问方式可能会有差异所以最稳妥的办法永远是先看一眼生成的头文件确认类型和名字再写访问代码。这一点和经验无关纯粹是因为Verilator的迭代节奏比较快依赖记忆容易翻车。需要说一句的是用--public会增加模型生成的复杂度和仿真开销尽量只对确实需要访问的内部信号所在的模块开启不要整个工程无脑加。4.3 通过trace回调走查信号变化另一种“访问”信号的方式是通过trace把信号变化记录下来。Verilator提供trace()接口你可以在testbench里这样启用#include verilated_vcd_c.h Verilated::traceEverOn(true); VerilatedVcdC* tfp new VerilatedVcdC; top-trace(tfp, 99); tfp-open(counter.vcd);然后在每个状态更新后调用tfp-dump(contextp-time());最后结束时tfp-close()。这种方式的好处是无需为每个信号写访问代码所有信号都进波形适合定位问题时先看整体波形再决定要不要深挖某个内部节点。对我来说trace更多是一种“全局视野”访问函数则是“定点狙击”两者配合使用效率最高。5. 常见问题与排查技巧5.1 现象与定位表格把我在实际使用中遇到最多的问题整理成一个表方便快速对照现象可能原因处理方式赋值后输出不变没调eval()或eval_step/end_step不配对修改信号后务必调用对应计算函数仿真时间一直为0调了eval()但没调timeInc()每个时钟周期前用timeInc()推进时间VCD波形为空没调Verilated::traceEverOn(true)或dump时机不对仿真开始时开启trace更新信号后调用tfp-dump()top-xx编译报错找不到成员该信号是内部信号或生成的符号名不同加--public查看头文件确认信号名printf打印出奇怪的大数类型匹配错误比如QData用了%d用PRIu64等可移植格式符读取输出总是慢一拍testbench采样时机过早在clk1并eval()之后再采样这些现象和原因之间并非一一对应遇到问题建议先对照这个表做一轮快速过滤再结合波形确认。5.2 几个我踩过的坑说几个比较有代表性的踩坑经历。第一次用Verilator做异步复位逻辑验证时我的testbench里给rst_n赋值后只调了一次eval()然后直接进入主循环。结果复位释放后计数器从不定值开始计数花了大半天排查最后发现是复位释放的瞬间和时钟上升沿刚好重合导致时序竞争。解决办法是确保复位释放发生在时钟低电平区间并且释放后先eval()一下让DUT完全稳定再继续跑。另一个坑是gotFinish()的使用。如果RTL里有$finishVerilator会设置上下文里的结束标志。testbench主循环如果没有检查contextp-gotFinish()就会一直跑下去看起来像是仿真卡死了。正确做法是在循环条件里加上对gotFinish()的判断while (!contextp-gotFinish() cycle MAX_CYCLE) { // 时钟与eval }还有一个非常隐蔽的问题在同一个eval()之前连续修改多个输入信号Verilator只会在调用eval()时统一计算所以中间某次赋值不会立即更新输出。这是正常的不是bug。你把testbench想象成一块电路板信号最终稳定后的值才是有效激励中间抖动不影响最终逻辑。5.3 调试建议最后给三条使用访问函数的建议都是实战换来的经验。第一条多用断言辅助。光靠printf打印输出在信号多的时候根本看不过来。我习惯在每个关键检查点写一个简单的assert宏封装把期望值和实际值对比一旦不匹配就直接退出并打印出错位置。用Verilator跑断言本质上和UVM里的scoreboard功能类似只是少了封装但胜在轻量直接。第二条波形永远是最快的定位手段。访问函数用来执行和检查结果波形用来确认中间时序。两者缺一不可在调试比较复杂的握手协议时尤其明显。我经常是先在VCD波形里看到异常信号再回到C代码里调整激励序列。第三条保持testbench结构清晰。访问函数写多了之后testbench容易变成一大坨赋值和eval()的堆砌。建议把时钟生成、复位序列、单周期激励这些动作封装成独立函数让主循环看起来像一份“测试用例清单”。这样不仅好维护出问题时也能快速定位是哪个环节写错了。Verilator的访问函数体系刚接触时确实有点绕但只要理解了信号成员类型、eval调用时机、时间推进这三件事后面基本就是熟能生巧。上面这些内容覆盖了我在模块级验证里90%以上的日常使用场景按这个思路去写testbench应该能少踩不少坑。
