简介这份资源是面向IC验证初学者与转岗工程师的UVM验证入门Demo代码包围绕SystemVerilog与UVM方法论帮助读者理解验证环境从零搭建到跑通仿真的完整流程。压缩包共31个文件约54KB以18个sv源文件为核心辅以f文件列表、v与svh头文件、Makefile与do脚本、C/C及dll库文件覆盖编译、仿真与结果记录等环节目录中可见src、dut、uvm、tb等模块划分。资源重点演示transaction、sequence、sequencer、driver、monitor、agent与scoreboard等组件的定义与连接方式并配有视频教程辅助理解代码背后的运行逻辑。目前已有6093人学习下载适合希望结合实例掌握UVM组件协作机制、提升验证工程实践能力的读者参考。1. 从一份 UVM 验证 demo 说起它到底能帮你省下多少重复造轮子的时间如果你正在做 IC 验证大概率经历过这样的场景拿到一个新模块的验证任务明明 DUT 逻辑不复杂却要花两三天搭 UVM 环境——driver、monitor、sequencer、agent、env、test 一层层写下来光是 factory 注册和 config_db 的路径就够调半天。这份 UVM 验证 demo 代码就是冲着这个痛点来的它把一套可运行的最小验证环境完整打包包含典型的 sequence、driver、monitor、scoreboard 和覆盖率收集骨架拿来就能跑仿真改改就能套到自己的 DUT 上。它适合三类人刚接触 UVM 但看文档看不进去、需要一份能跑通的代码来建立直觉的新手需要快速搭环境原型、不想每次从零写 agent 的熟手以及想对照检查自己环境结构是否规范、config_db 用法是否正确的验证工程师。核心价值不在于代码多复杂而在于它把 UVM 的“最小可运行闭环”讲清楚了——从 sequence 产生激励到 driver 驱动接口再到 monitor 采样、scoreboard 比对整条链路是通的。2. UVM 环境的骨架拆解从 component 树到 phase 执行顺序2.1 为什么 demo 的结构值得先看懂再动手改很多人拿到 demo 代码第一反应是直接改 DUT 接口然后跑结果发现仿真起不来或者起来了但 scoreboard 收不到数据。根本原因是对 UVM 的 component 树和 phase 机制没有建立清晰的心智模型。UVM 环境的本质是一棵树uvm_test 是根下面挂 envenv 下面挂 agent、scoreboard、coverage collectoragent 下面再挂 sequencer、driver、monitor。这棵树在 build_phase 阶段自顶向下构建在 connect_phase 阶段自底向上连接在 run_phase 阶段并行执行。demo 里通常会把这一层结构写得非常直白没有多余的封装。比如 agent 里 active 模式和 passive 模式的区别在 demo 中往往通过一个is_active变量控制而不是藏在多层继承里。这种写法对新手友好因为你可以在代码里直接看到条件分支知道 monitor 永远存在、driver 和 sequencer 只在 active 模式下创建。理解这棵树之后你才能回答一个关键问题为什么 config_db 的 set 要在 build_phase 里做而 get 可以在 build_phase 或 connect_phase 里做因为 build_phase 是自顶向下的父节点先于子节点执行set 操作必须发生在对应 get 之前。demo 代码里如果用了 config_db 传递 virtual interface你去看它的 set 和 get 位置基本就能验证这个顺序。2.2 一个最小可运行环境的代码骨架下面这段代码是从 demo 中提炼的典型结构去掉了具体 DUT 信号保留 UVM 环境的通用骨架。你可以直接对照自己手头的 demo 文件看对应关系。// agent.sv - 以 active 模式为例 class my_agent extends uvm_agent; uvm_component_utils(my_agent) my_sequencer sqr; my_driver drv; my_monitor mon; function new(string name, uvm_component parent); super.new(name, parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); mon my_monitor::type_id::create(mon, this); // 只有 active 模式才创建 driver 和 sequencer if (get_is_active() UVM_ACTIVE) begin sqr my_sequencer::type_id::create(sqr, this); drv my_driver::type_id::create(drv, this); end endfunction virtual function void connect_phase(uvm_phase phase); super.connect_phase(phase); if (get_is_active() UVM_ACTIVE) begin // driver 的 seq_item_port 连到 sequencer 的 seq_item_export drv.seq_item_port.connect(sqr.seq_item_export); end endfunction endclass这段代码的逻辑说明build_phase中先创建 monitor因为 monitor 在 active 和 passive 模式下都需要然后根据get_is_active()的返回值决定是否创建 driver 和 sequencer。connect_phase中完成 driver 和 sequencer 的连接这是 UVM 规定的标准连接点。参数说明get_is_active()返回UVM_ACTIVE或UVM_PASSIVE这个值通常由外层 env 通过 config_db 设置或者在 agent 的 build_phase 中直接读取。// env.sv - 环境容器 class my_env extends uvm_env; uvm_component_utils(my_env) my_agent agent; my_scoreboard scb; function new(string name, uvm_component parent); super.new(name, parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); agent my_agent::type_id::create(agent, this); scb my_scoreboard::type_id::create(scb, this); // 通过 config_db 设置 agent 为 active 模式 uvm_config_db#(uvm_active_passive_enum)::set( this, agent, is_active, UVM_ACTIVE); endfunction virtual function void connect_phase(uvm_phase phase); super.connect_phase(phase); // 把 monitor 的 analysis_port 连到 scoreboard 的 export agent.mon.item_collected_port.connect(scb.item_export); endfunction endclass这段 env 代码展示了两个关键点一是通过 config_db 的set方法控制 agent 的工作模式路径字符串agent是相对路径表示当前层次下的 agent 实例二是 connect_phase 中把 monitor 的 analysis_port 连接到 scoreboard 的 export这是 UVM 中典型的 TLM 连接方式。注意item_collected_port是 monitor 中定义的uvm_analysis_port#(my_transaction)类型scoreboard 中对应的item_export通常是uvm_analysis_imp#(my_transaction, my_scoreboard)类型。2.3 phase 执行顺序对调试的实际影响UVM 的 phase 分为三类build 类build_phase、connect_phase、end_of_elaboration_phase 等、run 类run_phase、reset_phase、configure_phase、main_phase 等、cleanup 类extract_phase、check_phase、report_phase 等。demo 代码通常只实现 build、connect、run 和 report 这几个最常用的 phase但理解完整的 phase 列表对排查问题很有帮助。一个常见的调试场景你在 scoreboard 的check_phase里做最终比对但发现check_phase根本没执行。原因可能是仿真在run_phase结束后被$finish直接终止了没有进入 cleanup 阶段。解决办法是在 test 的run_phase中调用phase.raise_objection和phase.drop_objection来控制仿真时长确保所有 phase 都能走完。demo 代码里通常会在 test 的run_phase中 raise objection然后在 sequence 发送完毕后 drop这样 UVM 会自动推进到后续 phase。另一个容易翻车的点是connect_phase的执行顺序。它是自底向上的也就是说子组件的connect_phase先于父组件执行。如果你在 env 的connect_phase中访问 agent 内部某个组件的端口而那个端口的连接是在 agent 的connect_phase中完成的那么 env 中看到的连接状态是已经就绪的。但如果你在 env 的build_phase中就去访问 agent 内部的组件实例可能会拿到 null因为 agent 的build_phase还没执行完。3. 把 demo 跑起来仿真命令、波形调试与 sequence 启动方式3.1 仿真器选择与编译脚本的适配demo 代码本身是纯 SystemVerilog UVM不依赖特定仿真器。但不同仿真器的编译选项和 UVM 库路径不一样直接拿 demo 里的脚本跑大概率会在第一步就报错。常见做法是先确认你用的仿真器版本和 UVM 库版本是否匹配然后修改编译脚本中的库路径和宏定义。以常见的三类仿真器为例编译选项的差异主要体现在 UVM 库的引入方式和宏定义上。demo 代码中通常会用\include uvm_macros.svh和import uvm_pkg::*;这两个语句要求仿真器能正确找到 UVM 库。如果你用的是集成 UVM 的仿真器可能需要加-ntb_opts uvm-1.2之类的选项如果是独立 UVM 库则需要用-incdir 指定路径。# 以某仿真器为例的编译命令模板需根据实际环境替换路径 vcs -full64 -sverilog \ -ntb_opts uvm-1.2 \ incdir./tb \ incdir./tests \ -f filelist.f \ -l compile.log # filelist.f 内容示例 # ./tb/my_agent.sv # ./tb/my_driver.sv # ./tb/my_monitor.sv # ./tb/my_scoreboard.sv # ./tb/my_env.sv # ./tests/my_test.sv # ./tb/top.sv这段编译命令的关键参数说明-full64表示 64 位编译-sverilog启用 SystemVerilog 支持-ntb_opts uvm-1.2指定使用 UVM 1.2 库如果你的 demo 基于 UVM 1.1d需要改成对应版本incdir添加 include 搜索路径-f filelist.f指定源文件列表-l compile.log输出编译日志。编译完成后用./simv启动仿真加UVM_TESTNAMEmy_test指定要运行的 test。3.2 用 waveform 定位 monitor 采样时机错误Monitor 的采样时机是 UVM 验证中最容易出问题的地方之一。demo 代码里 monitor 通常会在run_phase中用一个 forever 循环在时钟边沿采样接口信号然后通过 analysis_port 发送 transaction。但如果你发现 scoreboard 收到的数据比预期少或者数据内容对不上第一件事就是看波形。具体操作在仿真命令中加-gui或defineDUMP_WAVE之类的选项打开波形记录然后在 monitor 采样时刻附近观察接口信号。常见问题是 monitor 在时钟上升沿采样但 DUT 的输出信号在上升沿之后才稳定导致采到旧值。解决办法是把采样点改到下降沿或者在采样前加一个小的延时。demo 代码中如果用了(posedge clk)直接采样你可以试着改成(posedge clk); #1;看看数据是否变正确。另一个波形调试技巧在 monitor 的采样代码附近加$display打印采样到的 transaction 内容和波形对照。如果$display打印的值和波形上看到的不一致说明采样时机确实有问题如果一致但 scoreboard 比对失败问题就出在 scoreboard 的参考模型或比对逻辑上。3.3 sequence 的三种启动方式与适用场景demo 代码中通常会展示至少一种 sequence 启动方式但实际项目中你可能需要根据场景选择不同的启动方法。常见的有三种第一种是uvm_config_db配置默认 sequence。在 test 的build_phase中通过uvm_config_db#(uvm_object_wrapper)::set把某个 sequence 类型设置为 sequencer 的default_sequence仿真启动后 sequencer 会自动执行这个 sequence。这种方式适合固定的、每次仿真都要跑的激励。第二种是在 test 的run_phase中手动创建并启动 sequence。用seq.start(env.agent.sqr)的方式显式启动可以在启动前后加控制逻辑比如先等复位完成再启动。这种方式灵活适合需要条件判断的场景。第三种是在 virtual sequence 中协调多个 sequencer。当 DUT 有多个接口需要协同激励时virtual sequence 可以在不同 sequencer 上并行启动子 sequence实现复杂的激励场景。demo 代码如果只涉及单个接口可能不会展示这种方式但这是实际项目中最常用的。// 在 test 的 run_phase 中手动启动 sequence virtual task run_phase(uvm_phase phase); my_sequence seq; phase.raise_objection(this); seq my_sequence::type_id::create(seq); // 等待复位释放 (posedge vif.rst_n); // 在指定 sequencer 上启动 sequence seq.start(env.agent.sqr); phase.drop_objection(this); endtask这段代码的逻辑说明raise_objection告诉 UVM 当前 phase 还有事情没做完不要结束仿真(posedge vif.rst_n)等待复位信号释放确保 DUT 处于可工作状态seq.start()在指定的 sequencer 上启动 sequencesequencer 会自动把 sequence 产生的 transaction 交给 driver最后drop_objection表示当前 phase 的工作完成。参数说明vif是通过 config_db 传递到 test 中的 virtual interfaceenv.agent.sqr是 agent 内部 sequencer 的层次化路径。4. 避坑与排查UVM demo 跑不通时先查这五件事4.1 现象仿真启动后立刻结束没有任何 transaction 产生原因test 的run_phase中没有 raise objection或者 objection 在 sequence 启动前就被 drop 了。UVM 的 run_phase 是并行执行的如果没有任何组件 raise objection仿真会在所有组件的 run_phase 执行完毕后立即进入 cleanup 阶段并结束。解决在 test 的run_phase中确保raise_objection在启动 sequence 之前调用drop_objection在 sequence 执行完毕之后调用。如果 sequence 内部有耗时的循环objection 的 drop 应该放在 sequence 的body()任务返回之后。检查 demo 代码中 test 的run_phase实现确认 objection 的 raise 和 drop 成对出现。4.2 现象scoreboard 报错说收到了 null transaction原因monitor 的 analysis_port 连接到了 scoreboard 的 export但 monitor 在采样时没有正确创建 transaction 对象或者 transaction 的字段没有赋值就发送了。另一种可能是 monitor 在复位期间就开始采样采到了无效数据。解决在 monitor 的采样逻辑中先判断复位是否释放再创建 transaction 并赋值。demo 代码中如果 monitor 的run_phase是forever begin (posedge clk); ... end的结构需要在循环开头加复位判断。另外检查 transaction 的创建方式确保用的是my_transaction::type_id::create(trans)而不是new()否则 factory 机制不生效可能影响后续的覆盖率和调试。4.3 现象config_db 的 get 返回 nullvirtual interface 传递失败原因config_db 的 set 和 get 路径不匹配或者 set 发生在 get 之后。UVM 的 config_db 是层次化的set 时的路径字符串必须和 get 时的路径字符串在层次上对应。常见错误是在 top 模块中 set 时用了绝对路径uvm_test_top.env.agent.drv但在 driver 中 get 时用了相对路径*或。解决统一使用相对路径。在 top 模块中 set 时第一个参数用null或uvm_root::get()第二个参数用uvm_test_top.*或*表示对所有层次生效。在 driver 中 get 时第一个参数用this第二个参数用表示从当前层次向上查找。demo 代码中通常会在 top 模块的initial块中 set virtual interface你对照它的路径写法改就行。4.4 现象编译报错说找不到 uvm_pkg 或 uvm_macros.svh原因仿真器的 UVM 库路径没有正确配置或者 UVM 版本和 demo 代码不兼容。demo 代码如果是基于 UVM 1.2 写的而你用的仿真器默认加载的是 UVM 1.1d就会报找不到某些宏或类。解决先确认 demo 代码的 UVM 版本。看代码中是否有uvm_analysis_imp还是uvm_analysis_imp_decl的用法或者看uvm_config_db的参数类型。UVM 1.2 中uvm_config_db#(virtual my_if)::set的写法在 1.1d 中可能不支持。然后在编译选项中显式指定 UVM 版本比如-ntb_opts uvm-1.2或defineUVM_1_2。如果仿真器不支持指定版本可能需要手动下载对应版本的 UVM 库源码用incdir引入。4.5 现象覆盖率收集不到数据covergroup 的 sample 没触发原因covergroup 定义在 transaction 或 monitor 中但 sample 的调用时机不对。常见错误是在 monitor 中创建 transaction 后立即 sample但此时 transaction 的字段还没有从接口信号赋值导致 covergroup 采到的都是默认值。解决确保 sample 调用发生在 transaction 的所有字段赋值完成之后。如果 covergroup 定义在 transaction 类中可以在 transaction 的post_randomize或一个专门的sample()方法中调用cg.sample()。如果 covergroup 定义在 monitor 中在 monitor 完成采样并发送 transaction 之前调用 sample。demo 代码中如果覆盖率收集部分写得比较简略你可以参考这个原则自己补全。5. 从 demo 到项目把验证环境改造成可复用的进阶技巧5.1 用 factory override 替换组件而不改代码demo 代码跑通之后你可能会遇到这样的需求同一个环境在冒烟测试时用简化版的 driver在回归测试时用完整版的 driver。如果直接改代码来回切换很容易出错。UVM 的 factory override 机制就是为这种场景设计的。具体做法定义两个 driver 类比如my_driver_smoke和my_driver_full都继承自my_driver_base。在 test 的build_phase中用set_type_override_by_type或set_inst_override_by_type把基类替换成具体子类。这样 env 和 agent 的代码完全不用改只需要在 test 中加一行 override 语句。// 在 smoke_test 的 build_phase 中替换 driver virtual function void build_phase(uvm_phase phase); super.build_phase(phase); // 把 my_driver 类型替换为 my_driver_smoke my_driver::type_id::set_type_override( my_driver_smoke::get_type()); endfunction这段代码的逻辑说明set_type_override是 UVM factory 的静态方法它告诉 factory 在后续创建my_driver类型的实例时实际创建my_driver_smoke类型的对象。参数说明第一个参数是原始类型第二个参数是替换类型两个参数都是uvm_object_wrapper类型通过get_type()方法获取。注意 override 必须在build_phase中、在组件创建之前调用否则不生效。5.2 用 virtual sequence 协调多接口激励当 DUT 有多个接口时每个接口对应一个 agent每个 agent 有自己的 sequencer。如果激励需要跨接口同步比如接口 A 发送请求后接口 B 在若干周期后返回响应就需要用 virtual sequence 来协调。virtual sequence 本身不产生 transaction它持有一个或多个 sequencer 的句柄在body()任务中启动子 sequence。demo 代码如果只涉及单接口可能没有这部分内容但这是从 demo 走向实际项目的关键一步。// virtual sequence 示例 class my_virtual_seq extends uvm_sequence; uvm_object_utils(my_virtual_seq) my_sequencer_a sqr_a; my_sequencer_b sqr_b; function new(string name my_virtual_seq); super.new(name); endfunction virtual task body(); my_seq_a seq_a; my_seq_b seq_b; // 并行启动两个子 sequence fork begin seq_a my_seq_a::type_id::create(seq_a); seq_a.start(sqr_a); end begin seq_b my_seq_b::type_id::create(seq_b); seq_b.start(sqr_b); end join endtask endclass这段代码的逻辑说明virtual sequence 继承自uvm_sequence但它的body()中不调用start_item和finish_item而是启动其他 sequence。fork...join让两个子 sequence 并行执行如果需要同步可以用fork...join_any或fork...join_none配合 event 或 semaphore。参数说明sqr_a和sqr_b需要在 test 中通过 config_db 或直接赋值的方式传递给 virtual sequence通常用uvm_config_db#(my_sequencer)::set在 test 的build_phase中设置。5.3 用 report_phase 输出验证结果摘要仿真跑完后你需要的不是翻日志找错误而是一眼看到验证结果。UVM 的report_phase就是做这个的。在 scoreboard 或 test 的report_phase中统计比对次数、错误次数、覆盖率数值用uvm_info或uvm_report_info打印出来。一个实用的技巧在 scoreboard 中维护两个计数器match_count和mismatch_count每次比对后更新。在report_phase中根据mismatch_count的值决定打印UVM_INFO还是UVM_ERROR。如果mismatch_count大于零用UVM_ERROR打印这样仿真退出码会非零方便在回归脚本中判断通过与否。从那以后我每次拿到新的 UVM 环境都会先跑一遍 demo 确认工具链没问题再对照 phase 执行顺序检查 config_db 的 set/get 位置最后在 report_phase 里加一行结果摘要。这套流程走下来基本不会在环境搭建上翻车。希望帮到你。本文还有配套的精品资源点击获取