简介面向 IC 验证工程师的 UVM 验证示例代码包基于 SystemVerilog 实现聚焦 UVM 组件模型与验证环境搭建适合有一定 Verilog 基础、希望快速转向 UVM 的验证人员代码包共 31 个文件、54KB主体为 18 个 SystemVerilog.sv源文件搭配 .svh 头文件、.v 设计文件、.f 编译列表、.do 仿真脚本、Makefile 及少量 C/C 与 DLL 辅助文件并分别提供 Windows 与 Linux 两套运行配置便于在常见 EDA 环境中直接编译仿真当前已有 6049 人学习下载。示例覆盖 transaction 类封装、sequence 激励生成与调度、sequencer 管理、driver 驱动 DUT、monitor 采样以及 scoreboard 对预期和实际结果进行比对等完整流程agent 内整合 driver、monitor、sequencersequence 可产生带约束的随机激励driver 将 transaction 翻译为 DUT 接口时序monitor 采集 DUT 输出scoreboard 利用参考模型完成自动比对。工程内按 src、dut、uvm、tb 等目录组织dut 为被测设计uvm 与 tb 划分验证环境和测试台log 与 transcript 记录仿真输出结构清晰适合按模块拆解学习也可作为后续验证项目的基础模板帮助使用者快速建立可复用、可扩展的 UVM 验证思路。 我入行做数字IC验证这两年多被问得最多的问题就是“UVM到底怎么上手”。很多朋友拿到一本《UVM实战》翻了几章发现全是概念sequence、driver、monitor、phase这些名词背得滚瓜烂熟真到要写一个能跑起来的IC验证环境时反而不知道怎么下手。这篇博文我就结合自己整理的一份uvm验证demo代码把一套最小可用的验证平台从头拆到尾讲清楚每个组件干什么、寄存器模型这个重头戏怎么玩、镜像值是什么以及面试里UVM方法学的高频考点都在哪。内容偏实操适合刚学UVM的验证新手也适合准备验证面试的同学做提纲式回顾。1. 为什么每个UVM学习者都需要一份能跑通的demo1.1 一个demo的定位它不是玩具是骨架很多初学者有个误区——觉得demo代码太简单跟真实项目差距太大不如直接上项目。我的看法恰恰相反UVM这种框架型的方法学非常依赖“先跑通再理解”。一份设计良好的demo代码本质上是一套完整的验证环境骨架它把UVM的各种机制——factory、phase、sequence、TLM端口、寄存器模型——全部“点亮”了。你先把骨架跑起来再往里面填充业务逻辑学习曲线会平缓很多。我这份demo的选择是一个小型APB接口的寄存器模块作为待测设计DUT。APB协议足够简单总线信号就那么几个——PSEL、PENABLE、PWRITE、PADDR、PWDATA、PRDATA——一个晚上就能看懂时序。DUT内部挂了几个寄存器用来演示寄存器模型的前门访问、后门访问、镜像值预测和自动比对。这个组合是我认为最适合入门的组合协议简单但验证环境的复杂度一点不少该有的组件全都有。1.2 环境结构选型UVM验证平台该怎么搭在动手写代码之前我建议先花半小时把环境的结构图画出来。UVM环境的基本套路其实很固定testcase是入口env里面放agent和参考模型agent里面放sequencer、driver、monitor最下面挂着scoreboard做数据比对。层级关系如下test测试用例负责配置环境、启动sequence、控制仿真结束env环境组织所有的验证组件是环境的“集装箱”agent代理封装一组针对同一种协议的操作对上层暴露统一接口sequencer序列器负责sequence与driver之间的数据流转driver驱动器把sequence产生的transaction驱动到DUT接口上monitor监视器从接口上采集信号还原成transaction送给参考模型和scoreboardscoreboard计分板比对DUT实际输出与参考模型期望输出reg model寄存器模型对DUT内部寄存器进行建模支持前门/后门读写与镜像管理这个结构是UVM最好的实践模板几乎适用于所有协议验证。它的好处在于职责分离——每个组件只干一件事代码复用性高遇到问题时也好定位。我的demo里就是按这个结构来的一字不差。2. 验证平台组件拆解从test到driver每一层都在干什么2.1 组件职责与连接逻辑先看顶层test。这个demo里最核心的test是base_test它负责创建env、配置虚拟接口然后在run_phase里启动寄存器读写sequence。test创建env用的是uvm_component_utils宏注册只有注册过的组件才能被UVM的factory机制创建。再看agent。agent我把driver和monitor封装在一起。apb_agent内部创建了一个sequencer、一个driver、一个monitor。driver和sequencer之间通过TLM端口连接sequencer有个seq_item_exportdriver有个seq_item_port两者在connect_phase里用driver.seq_item_port.connect(sequencer.seq_item_export)连起来。这样sequence产生的transaction就可以从sequencer流向driver了。driver本身做的事情很单纯从seq_item_port里拿到一个transaction然后按APB协议时序把PADDR、PWDATA、PWRITE、PSEL、PENABLE这些信号一个个拉高拉低。这个过程就是一个典型的“数据到引脚”的转换。我习惯在driver里加一个get_next_item()空转等待然后调用drive_transaction()来真正驱动信号这样逻辑拆分后方便单步调试。2.2 平台启动与顶层运行机制UVM的仿真起始点是run_test()这个函数通常写在initial begin里。它做的事情可以理解为“按命令行参数中的test名字自动创建一个对应的testcase实例然后带着整个环境跑起来”。UVM的phase机制理解起来稍微有点绕但核心只需要记住几点build_phase是自顶向下执行的每个组件在build里创建自己的子组件所以父组件必须在build里uvm_component_utils注册后create出子组件connect_phase是自底向上执行的用来连接TLM端口、传递虚拟接口run_phase以及它的12个小phase是并行或者依次执行的主要做驱动、采样、比对等耗时操作report_phase在结束时统一汇总打印UVM_ERROR、UVM_WARNING的数量我这份demo在base_test里还把虚拟接口通过uvm_config_db传到driver和monitor中。这里有个细节uvm_config_db设置是在test的build_phase里用set获取是在driver的build_phase里用get。别小看这个步骤很多新手build能过一到run就报空指针异常十有八九就是接口没配进去。3. 寄存器模型镜像值到底怎么来的怎么用来做check3.1 寄存器模型的前门与后门访问寄存器模型是UVM验证里最容易被轻视、实际项目里却最关键的部分。很多IC验证面试官喜欢追问“镜像值”我在demo里专门把这块做了彻底演示。先解释前门访问。前门访问就是“走正常协议通道”的读写当sequence调用reg_block.reg_a.write(status, value)时寄存器模型会生成一个uvm_reg_bus_op的transaction经过adapter转换后交给APB的driver去DUT接口上实际发起一次总线读写。这个过程时序上是真实的能同时检验DUT的寄存器功能和总线协议代价是仿真时间较长。后门访问则完全绕开总线协议直接用uvm_hdl_read/uvm_hdl_write一类systemverilog接口直接修改/读取DUT内部信号。它的速度极快适合用来做初始化和快速配置。不过要注意后门访问不检测协议时序所以不能代替前门测试来验证总线接口。我的demo里初始化场景用的就是后门写把DUT的寄存器直接设置成预设值然后再用前门读回来比对这样既验证了寄存器模型的行为又把两种访问方式都覆盖到了。3.2 镜像值的更新机制与compare镜像值mirror value是寄存器模型内部维护的一份“期望值”缓存。你可以把它理解成软件里的一份“影子变量”真实寄存器里的值我们称硬件值模型里这份缓存就是镜像值。UVM的predict预测机制负责在每次读写后更新镜像值。关键点在两个步骤前门写写入成功后寄存器模型默认会自动更新镜像值如果不关predict的话前门读读回来的值会跟镜像值做对比如果不一样报UVM_ERROR后门写/读可以通过mirror()或read()等操作同步更新镜像值demo里我专门做了一个check流程先用后门写一个固定值到DUT寄存器再调用寄存器模型的前门read然后调用reg_block.mirror_check()。这里有个坑mirror_check默认会遍历所有寄存器比对镜像值如果中途某个寄存器有非预期的改动会直接报error。刚开始跑这个demo时我由于忘记在sequence里调用update()同步镜像值导致mirror_check永远报错。排查了很久才意识到是镜像值过期不是DUT的真实功能出了问题。3.3 寄存器模型在demo里的落地方式寄存器模型在UVM里的类继承关系是uvm_reg是单个寄存器的类uvm_reg_block是寄存器的集合容器uvm_reg_map负责地址映射。在demo中我定义了一个apb_reg_block它内部创建了两个uvm_reg子类一个控制寄存器ctrl_reg和一个状态寄存器status_reg。每个寄存器创建后必须调用configure()来配置位宽、访问属性、复位值然后通过default_map.add_reg()把地址映射关系挂上去。这里有个实用的建议如果项目里寄存器很多建议用脚本从寄存器描述文件自动生成这些UVM寄存器类手工写既容易出错又浪费时间。我的这份demo里是手工写的但是保持了一个可用作脚本模板的规整格式。4. 从零搭一个UVM demo的实操流程4.1 工程目录与文件清单搭UVM环境的第一步是规划目录。我个人的习惯是一个根目录下分rtl、tb、sim三个子目录rtl放DUT的verilog代码tb放UVM验证代码sim放编译脚本和仿真运行目录。一个完整可跑的demo至少需要以下这些文件文件作用rtl/apb_reg_dut.sv待测设计APB接口的寄存器模块tb/tb_top.sv顶层模块负责连接DUT与验证环境调用run_test()tb/reg_model/apb_reg_block.sv寄存器模型类定义tb/reg_model/apb_reg_adapter.sv前门访问的桥接适配器tb/pkt/apb_transaction.sv总线事务定义tb/agent/apb_agent.svagent封装tb/agent/apb_driver.svdriver实现tb/agent/apb_monitor.svmonitor实现tb/agent/apb_sequencer.svsequencer实现tb/seq/apb_base_seq.sv基础sequencetb/seq/reg_read_write_seq.sv寄存器读写sequencetb/env/apb_env.sv环境封装tb/test/base_test.sv基础testcasesim/run.sh编译运行脚本4.2 关键代码骨架分析篇幅所限没法贴全量代码但最关键的几个骨架必须放出来。首先是最底层的事务定义一个transaction最基本的结构class apb_transaction extends uvm_sequence_item; rand bit [31:0] addr; rand bit [31:0] data; rand bit write; bit [31:0] read_data; uvm_object_utils_begin(apb_transaction) uvm_field_int(addr, UVM_ALL_ON) uvm_field_int(data, UVM_ALL_ON) uvm_field_int(write, UVM_ALL_ON) uvm_object_utils_end function new(string name apb_transaction); super.new(name); endfunction : new endclass注意transaction继承的是uvm_sequence_item而不是uvm_component。很多人容易搞混这两者的区别uvm_component是有生命周期的一直存在build_phase创建后直到仿真结束才会销毁uvm_sequence_item是数据对象可以随时创建、拷贝、销毁然后是driver的核心驱动逻辑。APB的写时序要2个状态SETUP和ACCESS。我习惯用一个简单的状态机来驱动task apb_driver::drive_transaction(apb_transaction tr); // SETUP phase psel 1b1; penable 1b0; paddr tr.addr; pwrite tr.write; pwdata tr.data; (posedge vif.clk); // ACCESS phase penable 1b1; (posedge vif.clk); // capture read data if (!tr.write) tr.read_data prdata; // IDLE psel 1b0; penable 1b0; endtask这是一个最典型的APB驱动时序。注意最后的IDLE状态非常重要——如果驱动完成之后没有拉低PSEL和PENABLE下一次transaction进来时序就乱了。4.3 编译仿真与跑通要点跑通UVM demo最核心的动作是正确编译。我用的是VCS的命令行如果你用的是Questasim或者其他的仿真器基本动作类似vcs -sverilog -debug_all -ntb_opts uvm \ -f filelist.f \ -o simv \ -l compile.log ./simv UVM_TESTNAMEbase_test -l run.log这里有一个容易被坑的点UVM_TESTNAMEbase_test参数必须和test名字完全一致且这个test类必须是通过uvm_component_utils注册过的。如果名字不匹配UVM会报“Factory override not found”之类的问题你的环境就会卡在run_test()这一步。跑通过之后建议在脚本里加一行-assert disable_cover来关掉某些不必要的断言编译能有效避免仿真器版本差异带来的编译告警。这不是必须的但对于想快速验证UVM框架是否正常工作的场景可以省掉很多不相关的报错。5. 常见问题排查与面试高频考点5.1 仿真跑不起来的几类典型问题我把自己调试这份demo时踩过的坑都整理成了表格新手照着对号入座就能省不少时间现象可能原因解决方法编译报无法识别uvm_xxx没有指定UVM库路径加-ntb_opts uvm或incdir$UVM_HOME/srcrun_test()后什么也不发生UVM_TESTNAME名字不匹配检查test类名和注册名必须完全一致空指针异常在driver虚拟接口没有通过config_db传进来检查set/get两端路径是否严格一致transaction发不出去sequencer和driver没有正确连接检查connect_phase是否connect了seq_item_export寄存器模型读写超时adapter没有正确配置检查reg_map的set_sequencer和set_adaptermirror_check报错镜像值过期在sequence里显式调用update()仿真不自动结束缺少objection机制在sequence的body里raise/drop objection第三条关于空指针的问题想再强调一下UVM的config_db机制是靠路径匹配的test里set的第一参数如果是null默认就是当前组件全路径。driver里get的时候必须保证这个路径和set时完全匹配差一级目录都可能拿到的是null。5.2 UVM方法学面试常见问题盘点结合我自己的面试经历UVM方法学的面试问题翻来覆去就是考的几类。第一个高频考点就是“UVM的phase机制和作用”。回答思路要说清楚两点一是phase保证了不同组件之间有固定的执行顺序避免出现“我还没创建完你就开始用了”的竞争问题二是run_phase和12个小phase之间是并行关系小phase则是依次执行用于处理复位、配置、主运行等不同阶段。第二个高频考点“factory机制和override机制的原理”。这道题考察对UVM核心“工厂模式”的理解。回答时强调只有经过uvm_component_utils或uvm_object_utils注册的类才能用type_id::create()创建override是工厂机制最大的优势之一可以在不改代码的情况下替换组件例如用子类替换父类。第三个特别爱考的就是寄存器模型的镜像值问题基本上考官会顺着往下问“前门读和镜像值有差异时UVM怎么处理的”“close_loop prediction和auto prediction的区别”。回答核心是auto prediction由寄存器模型在每次操作后自动预测镜像值简单但容易被不预期的bus操作弄脏implicit/close_loop prediction依赖predictor从monitor采集到的bus操作来预测镜像值更接近真实硬件行为。我在demo里用的是auto prediction因为足够简单直观但真实项目环境复杂时更推荐用close_loop prediction。第四个题目是“sequence和driver之间是怎么握手的”。回答要点sequence通过start_item和finish_item来申请资源并完成transaction发送driver通过get_next_item拿到transaction处理完之后item_done通知sequence如果需要复用事务sequence可以对同一个item多次执行start_item/finish_item。第五个问题“怎么保证UVM验证环境没有memory leak或者复现性”。这个问题比较开放建议从objection机制、phase执行结束、report阶段进行了哪些检查三个角度回答。另外还有一个几乎每次都会被带的尾巴UVM验证环境里怎么实现随机化和约束。参考答案是说transaction定义中的rand变量配合constraint块实现随机激励然后通过uvm_sequencer和sequence的randomize来控制每一笔transaction的生成范围。我在demo里也写了一个很小的约束给addr限定在0到3之间方便仿真时更好地命中有限的几个寄存器地址。写在最后的一点体验做这份uvm验证demo代码的过程中我最深的体会是UVM难的不是某个组件怎么写而是整条数据链路怎么串起来。第一次跑通的时候那种“从driver发出一个transaction经过scoreboard比对最后在log里看到PASSED”的感觉确实是只能靠亲手写代码才能获得的。如果你现在正卡在某个报错里怎么都过不去别急着怀疑自己先检查config_db路径、再检查connect_phase、最后看objection有没有raise——这三板斧能解决大半新手的共性问题。这份demo还可以往两个方向扩展一个方向是把APB换成一个更有挑战的协议比如AXI或者PCIe另一个方向是加入覆盖率模型把功能覆盖率点补齐让UVM环境从“能跑”进化到“能报告验证进度”。这两个方向够你继续折腾一阵了。本文还有配套的精品资源点击获取