刚接触UVM的时候很多人最先卡住的往往不是语法而是搞不清楚验证平台里这么多类到底谁负责干什么。我第一次搭平台时照着别人的模板把driver、monitor、scoreboard全都create了一遍编译也过了跑起来却连个波形都没有。后来才明白UVM的组件不是一堆类的拼盘而是一套按职责拆分、按层次装配、按协议协作的工程体系。这篇文章就把验证平台里的组件逐个拆开讲清楚它们在数据流里的位置、为什么这样划分、搭环境时最常踩的坑在哪。它更适合两类人刚学UVM想系统理清组件关系的人以及能跑通简单testbench、但一写复杂验证环境就不知道该往哪个类里塞代码的人。1. 验证平台到底在验证什么为什么组件必须分层生长1.1 从“写波形的initial块”到“搭组件架构”验证的最终目的不是把仿真跑通而是发现问题。早期的testbench通常很简单一个initial块里赋值、拉高、等待、判断再加几个$display。对付一个小模块够用但一旦项目变大问题就来了——几百条测试用例怎么组织随机约束怎么加回归失败怎么定位换一个协议版本要改多少代码UVM对这些问题给出的答案是把验证平台拆成一套有标准接口、有明确职责的组件。组件的本质是“分工”谁负责产生激励谁负责把激励推到接口上谁负责看信号谁负责对答案。只有分工清楚才能做到激励的生产和发送分离、数据的采集和比较分离、场景的编写和平台的结构分离。这四种分离是我觉得UVM组件设计里最核心的骨架比记住某个类的继承关系重要得多。1.2 组件不是平等的object和component是两种人正式写UVM之前先要分清楚uvm_object和uvm_component这两个概念否则后面很容易在编译阶段栽跟头。uvm_object是UVM里所有数据和命令类的基础比如transaction、sequence、config对象。它们的特点是生命周期短、有随机化能力、不参与phase机制。uvm_component则是所有常驻组件的基类比如driver、monitor、agent、env、test。组件有名字、有父节点、组成一棵组件树并且从build_phase开始按阶段执行。我见过有人给sequence传了parent参数结果new的signature对不上也有人把driver当object用导致build_phase压根没执行。简单的判断方法是如果它需要在仿真过程中持续存在、需要挂在层次树上、需要由phase机制驱动创建和连接那就是component如果它只是流经组件之间的一份数据或一组命令那就是object。transaction和sequence虽然也会被“new”但它们没有常驻节点也不该出现在组件树里。1.3 组件树的形状平台是对DUT周围世界的工程化镜像UVM的平台最终会长成一棵树典型的形状是这样my_test └── my_env ├── my_agent │ ├── my_sequencer │ ├── my_driver │ └── my_monitor ├── my_reference_model ├── my_scoreboard └── my_coverage_collector这棵树不是随便画的它决定了三件大事phase机制会沿着这棵树自动遍历config_db的路径依赖这棵树的节点路径factory的override也要绑定到某个节点类型。所以“组件放在哪一层”不是美观问题而是功能问题。下面先给一张速查表帮助建立整体印象后面再逐个展开。组件基类本质角色关键对外接口transactionuvm_sequence_item一份激励数据randomizesequenceuvm_sequence激励的生产者start, bodysequenceruvm_sequencer激励的仲裁者seq_item_exportdriveruvm_driver激励的发送者seq_item_portmonitoruvm_monitor信号的采样者analysis_portagentuvm_agent同接口三件套的包装analysis_portenvuvm_env平台的组装者无scoreboarduvm_scoreboard结果的检查者analysis_imp/fiforeference modeluvm_component预期值的产生者analysis fifocoverage collectoruvm_subscriber覆盖率采样者analysis_imp2. 先记住最硬的三个零件driver、sequencer、monitor是怎么分家的2.1 driver激励的“发送端”但激励不是它想出来的driver在UVM里的职责非常窄从sequencer拿到一个transaction按照接口时序把这些数据一个bit一个bit地驱动到DUT输入信号上。它不负责创建激励也不负责判断对错更不应该把业务场景条件写在driver里。为什么这么分因为driver要服务于所有sequence。如果你在driver里写死了“先写地址再写数据”的具体行为那换一个测试场景时要么重写driver要么用一堆if/else把它撑得没法维护。把随机约束和场景逻辑放进sequence把时序翻译放进driver这条边界才是稳定的。driver和sequencer之间不是简单的“调用关系”而是握手机制。简单代码如下class my_driver extends uvm_driver #(my_transaction); virtual my_if vif; uvm_component_utils(my_driver) function new(string name my_driver, uvm_component parent null); super.new(name, parent); endfunction virtual task run_phase(uvm_phase phase); forever begin seq_item_port.get_next_item(req); drive_transaction(req); seq_item_port.item_done(); end endtask virtual task drive_transaction(my_transaction tr); (posedge vif.clk); vif.addr tr.addr; vif.data tr.data; vif.valid 1b1; (posedge vif.clk); vif.valid 1b0; endtask endclass注意get_next_item和item_done的配对。sequence调用start_item/finish_itemdriver调用get_next_item/item_done这两对正好咬合。如果driver只拿不还sequence会一直傻等如果driver在拿到item时做了太多与协议无关的事整个验证环境的节奏就会变得很难控制。2.2 sequencer它不只是个队列而是仲裁和路由如果没有sequencerdriver直接从某个全局队列里取transaction也可以但一旦出现多个sequence同时启动、某个sequence带优先级、或者virtual sequence要控制多个接口这种简单队列就撑不住了。sequencer解决的问题是仲裁多个sequence都可以通过start(sequencer)在同一个sequencer上启动sequencer按照仲裁规则决定下一个item交给driver。UVM内置了几种仲裁策略比如UVM_SEQ_ARB_FIFO、UVM_SEQ_ARB_WEIGHTED、UVM_SEQ_ARB_RANDOM。默认情况下按请求到达顺序来看起来像透明的但它始终是那个“路由器”。真正体现sequencer价值的是virtual sequence。一个virtual sequence本身不产生物理信号而是在body里启动多个子sequence把它们分发给不同接口的sequencer。比如系统级场景需要“先配寄存器再等数据中断同时监控总线”没有sequencer的仲裁和父子关系这种跨agent协同会写得非常丑陋。新手常犯的错误是在driver里直接调用seq.start(sequencer)试图“从driver里发起激励”。这会造成循环依赖也让激励来源和发送混在一起。正确的做法是在test里或者virtual sequence里调用seq.start(env.agent.sequencer)让激励“自上而下”流到driver。2.3 monitor唯一能够合法“偷看”信号的角色monitor在UVM里是真正的观察者。它不驱动DUT的任何信号只从接口上采样transaction然后通过analysis_port广播出去。一个典型的monitor采样如下class my_monitor extends uvm_monitor; virtual my_if vif; uvm_analysis_port #(my_transaction) ap; uvm_component_utils(my_monitor) function new(string name my_monitor, uvm_component parent null); super.new(name, parent); ap new(ap, this); endfunction virtual task run_phase(uvm_phase phase); my_transaction tr; forever begin (posedge vif.clk iff vif.valid); tr my_transaction::type_id::create(tr); tr.addr vif.addr; tr.data vif.data; ap.write(tr); end endtask endclass这里有两个容易踩的细节。第一个是采样沿的选择driver在时钟上升沿驱动monitor应该在合适的窗口采样稳定值而不是和driver抢同一个瞬间。第二个是采样条件的过滤用iff vif.valid只关心真正有效的周期否则你会把一堆无效数据也收进scoreboard白白增加比对噪音。monitor只做“观察和广播”所以它天然可以被复用。一个agent如果配置成passive模式只保留monitor不发激励就可以放在参考环境里做总线的旁观者active模式则加上driver和sequencer用来驱动被测模块。如果没有monitor和driver的分离这种“只监听不发送”的复用几乎不可能做到。3. agent和env从散装零件到标准组件再到整机平台3.1 agent同一个协议接口的收发力量打包成一个黑盒driver、sequencer、monitor这三个组件通常是针对同一个协议接口服务的它们共享同一个virtual interface、同一类transaction、同一套时序定义。如果每次在env里分别创建它们不仅代码散落而且换到另一个验证环境时容易漏掉某个连接。agent就是用来打包的它把同一个接口的driver、sequencer、monitor收进一个容器里。除了创建子组件agent还做两件事。一是根据is_active决定是否创建driver和sequencer二是把driver的seq_item_port和sequencer的seq_item_export连起来。代码骨架如下class my_agent extends uvm_agent; uvm_component_utils(my_agent) my_driver drv; my_sequencer sqr; my_monitor mon; function new(string name my_agent, uvm_component parent null); 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); if (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 (is_active UVM_ACTIVE) drv.seq_item_port.connect(sqr.seq_item_export); endfunction endclassactive和passive的切换让agent具备两种身份。顶层验证环境里agent是主动的能发激励在参考模型或低功耗检查等场景里agent可以是passive的只监听真实总线活动。同一个agent类能适配两种场景这是UVM重用性的一个典型体现。3.2 env总装车间里最重要的动作是connect_phase把线接好env是验证平台里的总装车间。它不直接和DUT接口打交道而是把agent、reference model、scoreboard、coverage collector这些组件创建出来并在connect_phase里把它们连接成完整的数据通路。连接的目标很明确把monitor采样到的transaction送往所有需要它的地方。因为analysis_port是广播语义一个monitor可以同时连着reference model的输入、scoreboard的actual端、coverage collector的采样端。在env里通常会用到uvm_tlm_analysis_fifo作为缓冲把生产和消费解耦。连接代码大致是这样virtual function void connect_phase(uvm_phase phase); super.connect_phase(phase); agent.monitor.ap.connect(scb.actual_fifo.analysis_export); agent.monitor.ap.connect(ref_model.input_fifo.analysis_export); agent.monitor.ap.connect(cov.analysis_export); endfunction为什么要把连线放在env而不是test因为env描述的是“物理拓扑结构”相对稳定test描述的是“这次要验证什么场景”变化频繁。每个test只需要决定自己在env上跑哪条sequence、做什么override不需要每次重新连一遍数据通路。一个经常出现的问题是有人在connect_phase里create新组件。connect_phase开始时所有组件的build_phase已经执行完毕如果在connect里才去create组件这个新组件的build_phase不会再被调用它的子组件和配置都会出问题。所有组件的创建都应该尽量收敛在build_phase。3.3 test验证场景的“导演”但不要把剧本写在导演脑子里test是UVM平台的最顶层。一个test负责build整个env、设置必要的config、并在run_phase里启动合适的sequence。不同测试场景就是不同类型的test命令行里用UVM_TESTNAMEmy_test就能切换。class my_test extends uvm_test; uvm_component_utils(my_test) my_env env; function new(string name my_test, uvm_component parent null); super.new(name, parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); env my_env::type_id::create(env, this); endfunction virtual task run_phase(uvm_phase phase); my_sequence seq; phase.raise_objection(this); seq my_sequence::type_id::create(seq); seq.start(env.agent.sequencer); phase.drop_objection(this); endtask endclass在实际项目里我最怕看到test类里塞一大坨if/else业务逻辑。一个test只应该表达“我要验证什么场景”至于激励怎么随机、数据怎么组织全部交给sequence至于结果对不对全部交给scoreboard。如果test承担了太多不该承担的职责环境就失去了扩展性新场景来了只能继续往test里堆代码。4. scoreboard、reference model、coverage给平台装上质检和度量4.1 reference model把DUT的“标准答案”先算出来scoreboard要比较就必须知道“期望值是什么”。reference model就是专门做这件事的组件。它和DUT吃同一个输入激励内部用一个更抽象、更可读的模型算出期望输出再把期望结果送给scoreboard。有些简单环境会把reference model和scoreboard合在一起但这只在DUT非常简单时可行。只要DUT有流水线延迟、状态机、内部缓存的任意一个特征把“算预期”和“比结果”混在一个组件里就会迅速变得无法控制。reference model的实现方式很多SystemVerilog行为模型、C模型通过DPI接入、甚至外部参考模型。关键不在于用什么语言而在于它和真实DUT的输入必须同步。比如DUT固定有三级流水线延迟reference model算出的结果如果不做对齐scoreboard会把上一笔期望和下一笔实际匹配到一起后面全是误报。4.2 scoreboard比对结果更要会处理乱序和延迟scoreboard是验证平台的最终看门人。它一边收reference model传来的期望值一边收monitor采集到的实际输出然后一笔一笔比对。新手写scoreboard时最容易犯的错误是“收到一笔就比一笔”。实际芯片的输出往往有延迟、有乱序、甚至有个别被过滤掉的异常周期所以scoreboard一般要用两个uvm_tlm_analysis_fifo分别缓存期望值和实际值再按顺序取出比对。代码骨架如下class my_scoreboard extends uvm_scoreboard; uvm_component_utils(my_scoreboard) uvm_tlm_analysis_fifo #(my_transaction) exp_fifo; uvm_tlm_analysis_fifo #(my_transaction) act_fifo; function new(string name my_scoreboard, uvm_component parent null); super.new(name, parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); exp_fifo new(exp_fifo, this); act_fifo new(act_fifo, this); endfunction virtual task run_phase(uvm_phase phase); my_transaction exp_tr, act_tr; forever begin exp_fifo.get(exp_tr); act_fifo.get(act_tr); if (exp_tr.data ! act_tr.data) uvm_error(SCB, $sformatf(data mismatch! exp%0h act%0h, exp_tr.data, act_tr.data)) end endtask endclassscoreboard的报错信息一定要足够丰富。只说“mismatch”没有意义至少要把transaction的id、地址、数据、时间戳打出来。否则回归失败时你要花大量时间从海量波形里捞那一拍异常。4.3 coverage它不是一个“刷百分比”的零件覆盖率有两种代码覆盖率和功能覆盖率。代码覆盖率交给仿真工具统计组件层面上通常要写的是功能覆盖率收集器也就是coverage collector它通常继承uvm_subscriber通过write()接收agent广播的transaction然后更新covergroup。但我想提醒一件事功能覆盖率不是为了把数字刷高而存在的。高覆盖率背后如果没有关键场景支撑那只是“随机碰巧碰到的表面覆盖”。真正有效的coverage要从设计spec出发提取那些容易出问题的边界场景协议握手、背压、错误地址、位宽切换、中断嵌套等等然后在covergroup里明确采样它们。coverage collector在数据通路里的角色是一个旁路观察者。它只消费transaction的副本不应该阻塞数据流也不应该在write()里做大量打印。把coverage和scoreboard分开的目的就是让“正确性检查”和“质量度量”两个关注点各管各的互不污染。5. 让组件协作的隐形规则config_db、factory和phase5.1 config_db组件之间不是靠全局变量传话UVM组件之间传参数最忌讳的就是“全局变量”和“跨层次绝对路径引用”。一个组件如果直接写tb_top.vif它就和这个顶层模块绑死了拿到其他环境立刻失效。UVM给出的替代方案是config_db机制。顶层模块在run_test之前把virtual interface set进去组件在build_phase里通过get取出来。典型写法// 顶层模块里 uvm_config_db #(virtual my_if)::set(null, uvm_test_top.*, vif, vif); run_test(my_test); // 组件里 if (!uvm_config_db #(virtual my_if)::get(this, , vif, vif)) uvm_fatal(CFG, vif not found in config_db)config_db最大的坑是路径和时机。路径写错get就返回0set时机太晚get同样拿不到。常见经验是父组件build_phase里对子组件要用的配置写在create子组件之前顶层模块的set老老实实写在run_test之前。这样最稳妥。5.2 factory不用改组件树就能换组件UVM的factory机制是实现验证环境可配置性的关键。它的核心操作有两步一是组件类必须用uvm_component_utils注册二是创建实例时用type_id::create而不是直接new。factory机制允许你在不修改env代码的前提下把某个组件替换成它的子类。比如想验证DUT在驱动错误时序下的表现不需要重新写一个env只要定义一个继承自原driver的子类重写drive_transaction然后在test里overrideclass my_driver_with_err extends my_driver; uvm_component_utils(my_driver_with_err) virtual task drive_transaction(my_transaction tr); super.drive_transaction(tr); // 在正常时序之后再额外插入一个错误脉冲 endtask endclass // test 或 test 的 build_phase 里 my_driver::type_id::set_type_override_by_type(my_driver_with_err::get_type());这个机制非常强大但它有一个重要前提组件必须是type_id::create创建的。如果有人在env里写了new(drv, this)那override永远不会生效。排查“为什么我的替换没起作用”时第一件事就是检查所有组件创建是否走factory。5.3 phase组件不是各跑各的而是共享一张统一时间表组件之间的协作时序由phase机制统一管理。build_phase自上而下执行保证父组件先构建、子组件随后构建connect_phase自下而上执行保证子组件的内部连接完成后父组件再去连接它们的端口。这个顺序不是随便定的——如果父组件的connect先跑它可能连到一个还没有完成内部初始化的子组件。run_phase是所有组件并行运行的时间消耗阶段。driver、monitor、scoreboard都在自己的run_phase里跑forever循环。但这里有个很多人栽过的跟头run_phase什么时候结束UVM靠objection机制判断。如果没有任何组件raise objectionrun_phase会立刻结束平台就像“空转一秒就退出”。常见做法是在test里让sequence运行期间抬一个objectiontask run_phase(uvm_phase phase); phase.raise_objection(this); seq.start(env.agent.sequencer); phase.drop_objection(this); endtask注意driver的run_phase通常是一个forever循环它会在仿真结束前一直转。这类常驻组件不应该随便在run_phase里raise_objection否则没人drop整个仿真会一直拖到超时。关于objection的“谁抬、谁放”要心里有数否则平台动不动就提前结束或者跑不完。6. 从零搭一个最小UVM平台骨架代码和首批踩坑清单6.1 最小可运行平台需要哪些零件很多人以为最小平台只要有driver、monitor、env就够了其实完整跑通一次验证至少需要transaction、sequence、sequencer、driver、monitor、agent、env、scoreboard、test和顶层模块。其中sequencer在简单场景里通常是个空壳类只需要继承uvm_sequencer #(my_transaction)但它依然必须存在因为sequence要挂在它身上。搭建顺序我建议这样走先定义transaction和interface再写sequence然后写driver和monitor把三者包进agent写env和scoreboard写test最后写顶层模块把虚拟interface注入并调用run_test。这个顺序能保证每一步都有明显的验证手段先编译过了再仿真有数据流动最后才谈比对和覆盖。6.2 让零件转起来的组装代码关键片段sequence是激励的源头它至少要有一个body任务class my_sequence extends uvm_sequence #(my_transaction); uvm_object_utils(my_sequence) function new(string name my_sequence); super.new(name); endfunction virtual task body(); repeat(10) begin req my_transaction::type_id::create(req); start_item(req); if (!req.randomize()) uvm_fatal(SEQ, randomize failed) finish_item(req); end endtask endclass顶层模块负责生成时钟、连接DUT、注入虚拟接口module tb_top; logic clk, rst_n; my_if vif(clk, rst_n); my_dut dut( .clk (clk), .rst_n (rst_n), .addr (vif.addr), .data (vif.data), .valid (vif.valid) ); initial begin clk 1b0; forever #5 clk ~clk; end initial begin uvm_config_db #(virtual my_if)::set(null, uvm_test_top.*, vif, vif); run_test(my_test); end endmodule另外要注意仿真命令里一定要把UVM库编译进去。很多“平台代码没问题但编译不过”的报错本质都是UVM包没加进编译列表。6.3 跑起来之后最容易撞上的几个坑以及排查路径我把自己调试UVM平台时最常遇到的四类问题整理成一张排查表希望对刚上路的人有帮助。现象可能原因排查路径仿真一跑就结束几乎没东西发生objection没抬起来或sequence没启动先看test的run_phase里有没有raise_objection再看seq.start是否真的执行了driver报空指针vif一直是nullconfig_db路径写错或者set时机太晚在组件里检查get返回值get不到就打印顶层实际存在的组件树路径sequence卡死仿真挂着不动driver没调item_done或者agent没连接seq_item_port用波形看driver是否进入run_phase再看是否卡在first dram求偶 uslscoreboard大量误报monitor采样沿不对或fifo没有对齐打印每一笔transaction的id和时间戳比对前先确认采样窗口我自己的一个习惯是遇到问题先打印组件树把整个层次结构看一遍。很多连接错误一眼就能看出来。再配合在driver、monitor、scoreboard关键位置加uvm_info基本上能把UVM平台前期的问题归到“没建、没连、没采、没比”四类里。这个排查口径比对着波形猜省时间得多也适合在团队里统一使用。
刚接触UVM的时候很多人最先卡住的往往不是语法而是搞不清楚验证平台里这么多类到底谁负责干什么。我第一次搭平台时照着别人的模板把driver、monitor、scoreboard全都create了一遍编译也过了跑起来却连个波形都没有。后来才明白UVM的组件不是一堆类的拼盘而是一套按职责拆分、按层次装配、按协议协作的工程体系。这篇文章就把验证平台里的组件逐个拆开讲清楚它们在数据流里的位置、为什么这样划分、搭环境时最常踩的坑在哪。它更适合两类人刚学UVM想系统理清组件关系的人以及能跑通简单testbench、但一写复杂验证环境就不知道该往哪个类里塞代码的人。1. 验证平台到底在验证什么为什么组件必须分层生长1.1 从“写波形的initial块”到“搭组件架构”验证的最终目的不是把仿真跑通而是发现问题。早期的testbench通常很简单一个initial块里赋值、拉高、等待、判断再加几个$display。对付一个小模块够用但一旦项目变大问题就来了——几百条测试用例怎么组织随机约束怎么加回归失败怎么定位换一个协议版本要改多少代码UVM对这些问题给出的答案是把验证平台拆成一套有标准接口、有明确职责的组件。组件的本质是“分工”谁负责产生激励谁负责把激励推到接口上谁负责看信号谁负责对答案。只有分工清楚才能做到激励的生产和发送分离、数据的采集和比较分离、场景的编写和平台的结构分离。这四种分离是我觉得UVM组件设计里最核心的骨架比记住某个类的继承关系重要得多。1.2 组件不是平等的object和component是两种人正式写UVM之前先要分清楚uvm_object和uvm_component这两个概念否则后面很容易在编译阶段栽跟头。uvm_object是UVM里所有数据和命令类的基础比如transaction、sequence、config对象。它们的特点是生命周期短、有随机化能力、不参与phase机制。uvm_component则是所有常驻组件的基类比如driver、monitor、agent、env、test。组件有名字、有父节点、组成一棵组件树并且从build_phase开始按阶段执行。我见过有人给sequence传了parent参数结果new的signature对不上也有人把driver当object用导致build_phase压根没执行。简单的判断方法是如果它需要在仿真过程中持续存在、需要挂在层次树上、需要由phase机制驱动创建和连接那就是component如果它只是流经组件之间的一份数据或一组命令那就是object。transaction和sequence虽然也会被“new”但它们没有常驻节点也不该出现在组件树里。1.3 组件树的形状平台是对DUT周围世界的工程化镜像UVM的平台最终会长成一棵树典型的形状是这样my_test └── my_env ├── my_agent │ ├── my_sequencer │ ├── my_driver │ └── my_monitor ├── my_reference_model ├── my_scoreboard └── my_coverage_collector这棵树不是随便画的它决定了三件大事phase机制会沿着这棵树自动遍历config_db的路径依赖这棵树的节点路径factory的override也要绑定到某个节点类型。所以“组件放在哪一层”不是美观问题而是功能问题。下面先给一张速查表帮助建立整体印象后面再逐个展开。组件基类本质角色关键对外接口transactionuvm_sequence_item一份激励数据randomizesequenceuvm_sequence激励的生产者start, bodysequenceruvm_sequencer激励的仲裁者seq_item_exportdriveruvm_driver激励的发送者seq_item_portmonitoruvm_monitor信号的采样者analysis_portagentuvm_agent同接口三件套的包装analysis_portenvuvm_env平台的组装者无scoreboarduvm_scoreboard结果的检查者analysis_imp/fiforeference modeluvm_component预期值的产生者analysis fifocoverage collectoruvm_subscriber覆盖率采样者analysis_imp2. 先记住最硬的三个零件driver、sequencer、monitor是怎么分家的2.1 driver激励的“发送端”但激励不是它想出来的driver在UVM里的职责非常窄从sequencer拿到一个transaction按照接口时序把这些数据一个bit一个bit地驱动到DUT输入信号上。它不负责创建激励也不负责判断对错更不应该把业务场景条件写在driver里。为什么这么分因为driver要服务于所有sequence。如果你在driver里写死了“先写地址再写数据”的具体行为那换一个测试场景时要么重写driver要么用一堆if/else把它撑得没法维护。把随机约束和场景逻辑放进sequence把时序翻译放进driver这条边界才是稳定的。driver和sequencer之间不是简单的“调用关系”而是握手机制。简单代码如下class my_driver extends uvm_driver #(my_transaction); virtual my_if vif; uvm_component_utils(my_driver) function new(string name my_driver, uvm_component parent null); super.new(name, parent); endfunction virtual task run_phase(uvm_phase phase); forever begin seq_item_port.get_next_item(req); drive_transaction(req); seq_item_port.item_done(); end endtask virtual task drive_transaction(my_transaction tr); (posedge vif.clk); vif.addr tr.addr; vif.data tr.data; vif.valid 1b1; (posedge vif.clk); vif.valid 1b0; endtask endclass注意get_next_item和item_done的配对。sequence调用start_item/finish_itemdriver调用get_next_item/item_done这两对正好咬合。如果driver只拿不还sequence会一直傻等如果driver在拿到item时做了太多与协议无关的事整个验证环境的节奏就会变得很难控制。2.2 sequencer它不只是个队列而是仲裁和路由如果没有sequencerdriver直接从某个全局队列里取transaction也可以但一旦出现多个sequence同时启动、某个sequence带优先级、或者virtual sequence要控制多个接口这种简单队列就撑不住了。sequencer解决的问题是仲裁多个sequence都可以通过start(sequencer)在同一个sequencer上启动sequencer按照仲裁规则决定下一个item交给driver。UVM内置了几种仲裁策略比如UVM_SEQ_ARB_FIFO、UVM_SEQ_ARB_WEIGHTED、UVM_SEQ_ARB_RANDOM。默认情况下按请求到达顺序来看起来像透明的但它始终是那个“路由器”。真正体现sequencer价值的是virtual sequence。一个virtual sequence本身不产生物理信号而是在body里启动多个子sequence把它们分发给不同接口的sequencer。比如系统级场景需要“先配寄存器再等数据中断同时监控总线”没有sequencer的仲裁和父子关系这种跨agent协同会写得非常丑陋。新手常犯的错误是在driver里直接调用seq.start(sequencer)试图“从driver里发起激励”。这会造成循环依赖也让激励来源和发送混在一起。正确的做法是在test里或者virtual sequence里调用seq.start(env.agent.sequencer)让激励“自上而下”流到driver。2.3 monitor唯一能够合法“偷看”信号的角色monitor在UVM里是真正的观察者。它不驱动DUT的任何信号只从接口上采样transaction然后通过analysis_port广播出去。一个典型的monitor采样如下class my_monitor extends uvm_monitor; virtual my_if vif; uvm_analysis_port #(my_transaction) ap; uvm_component_utils(my_monitor) function new(string name my_monitor, uvm_component parent null); super.new(name, parent); ap new(ap, this); endfunction virtual task run_phase(uvm_phase phase); my_transaction tr; forever begin (posedge vif.clk iff vif.valid); tr my_transaction::type_id::create(tr); tr.addr vif.addr; tr.data vif.data; ap.write(tr); end endtask endclass这里有两个容易踩的细节。第一个是采样沿的选择driver在时钟上升沿驱动monitor应该在合适的窗口采样稳定值而不是和driver抢同一个瞬间。第二个是采样条件的过滤用iff vif.valid只关心真正有效的周期否则你会把一堆无效数据也收进scoreboard白白增加比对噪音。monitor只做“观察和广播”所以它天然可以被复用。一个agent如果配置成passive模式只保留monitor不发激励就可以放在参考环境里做总线的旁观者active模式则加上driver和sequencer用来驱动被测模块。如果没有monitor和driver的分离这种“只监听不发送”的复用几乎不可能做到。3. agent和env从散装零件到标准组件再到整机平台3.1 agent同一个协议接口的收发力量打包成一个黑盒driver、sequencer、monitor这三个组件通常是针对同一个协议接口服务的它们共享同一个virtual interface、同一类transaction、同一套时序定义。如果每次在env里分别创建它们不仅代码散落而且换到另一个验证环境时容易漏掉某个连接。agent就是用来打包的它把同一个接口的driver、sequencer、monitor收进一个容器里。除了创建子组件agent还做两件事。一是根据is_active决定是否创建driver和sequencer二是把driver的seq_item_port和sequencer的seq_item_export连起来。代码骨架如下class my_agent extends uvm_agent; uvm_component_utils(my_agent) my_driver drv; my_sequencer sqr; my_monitor mon; function new(string name my_agent, uvm_component parent null); 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); if (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 (is_active UVM_ACTIVE) drv.seq_item_port.connect(sqr.seq_item_export); endfunction endclassactive和passive的切换让agent具备两种身份。顶层验证环境里agent是主动的能发激励在参考模型或低功耗检查等场景里agent可以是passive的只监听真实总线活动。同一个agent类能适配两种场景这是UVM重用性的一个典型体现。3.2 env总装车间里最重要的动作是connect_phase把线接好env是验证平台里的总装车间。它不直接和DUT接口打交道而是把agent、reference model、scoreboard、coverage collector这些组件创建出来并在connect_phase里把它们连接成完整的数据通路。连接的目标很明确把monitor采样到的transaction送往所有需要它的地方。因为analysis_port是广播语义一个monitor可以同时连着reference model的输入、scoreboard的actual端、coverage collector的采样端。在env里通常会用到uvm_tlm_analysis_fifo作为缓冲把生产和消费解耦。连接代码大致是这样virtual function void connect_phase(uvm_phase phase); super.connect_phase(phase); agent.monitor.ap.connect(scb.actual_fifo.analysis_export); agent.monitor.ap.connect(ref_model.input_fifo.analysis_export); agent.monitor.ap.connect(cov.analysis_export); endfunction为什么要把连线放在env而不是test因为env描述的是“物理拓扑结构”相对稳定test描述的是“这次要验证什么场景”变化频繁。每个test只需要决定自己在env上跑哪条sequence、做什么override不需要每次重新连一遍数据通路。一个经常出现的问题是有人在connect_phase里create新组件。connect_phase开始时所有组件的build_phase已经执行完毕如果在connect里才去create组件这个新组件的build_phase不会再被调用它的子组件和配置都会出问题。所有组件的创建都应该尽量收敛在build_phase。3.3 test验证场景的“导演”但不要把剧本写在导演脑子里test是UVM平台的最顶层。一个test负责build整个env、设置必要的config、并在run_phase里启动合适的sequence。不同测试场景就是不同类型的test命令行里用UVM_TESTNAMEmy_test就能切换。class my_test extends uvm_test; uvm_component_utils(my_test) my_env env; function new(string name my_test, uvm_component parent null); super.new(name, parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); env my_env::type_id::create(env, this); endfunction virtual task run_phase(uvm_phase phase); my_sequence seq; phase.raise_objection(this); seq my_sequence::type_id::create(seq); seq.start(env.agent.sequencer); phase.drop_objection(this); endtask endclass在实际项目里我最怕看到test类里塞一大坨if/else业务逻辑。一个test只应该表达“我要验证什么场景”至于激励怎么随机、数据怎么组织全部交给sequence至于结果对不对全部交给scoreboard。如果test承担了太多不该承担的职责环境就失去了扩展性新场景来了只能继续往test里堆代码。4. scoreboard、reference model、coverage给平台装上质检和度量4.1 reference model把DUT的“标准答案”先算出来scoreboard要比较就必须知道“期望值是什么”。reference model就是专门做这件事的组件。它和DUT吃同一个输入激励内部用一个更抽象、更可读的模型算出期望输出再把期望结果送给scoreboard。有些简单环境会把reference model和scoreboard合在一起但这只在DUT非常简单时可行。只要DUT有流水线延迟、状态机、内部缓存的任意一个特征把“算预期”和“比结果”混在一个组件里就会迅速变得无法控制。reference model的实现方式很多SystemVerilog行为模型、C模型通过DPI接入、甚至外部参考模型。关键不在于用什么语言而在于它和真实DUT的输入必须同步。比如DUT固定有三级流水线延迟reference model算出的结果如果不做对齐scoreboard会把上一笔期望和下一笔实际匹配到一起后面全是误报。4.2 scoreboard比对结果更要会处理乱序和延迟scoreboard是验证平台的最终看门人。它一边收reference model传来的期望值一边收monitor采集到的实际输出然后一笔一笔比对。新手写scoreboard时最容易犯的错误是“收到一笔就比一笔”。实际芯片的输出往往有延迟、有乱序、甚至有个别被过滤掉的异常周期所以scoreboard一般要用两个uvm_tlm_analysis_fifo分别缓存期望值和实际值再按顺序取出比对。代码骨架如下class my_scoreboard extends uvm_scoreboard; uvm_component_utils(my_scoreboard) uvm_tlm_analysis_fifo #(my_transaction) exp_fifo; uvm_tlm_analysis_fifo #(my_transaction) act_fifo; function new(string name my_scoreboard, uvm_component parent null); super.new(name, parent); endfunction virtual function void build_phase(uvm_phase phase); super.build_phase(phase); exp_fifo new(exp_fifo, this); act_fifo new(act_fifo, this); endfunction virtual task run_phase(uvm_phase phase); my_transaction exp_tr, act_tr; forever begin exp_fifo.get(exp_tr); act_fifo.get(act_tr); if (exp_tr.data ! act_tr.data) uvm_error(SCB, $sformatf(data mismatch! exp%0h act%0h, exp_tr.data, act_tr.data)) end endtask endclassscoreboard的报错信息一定要足够丰富。只说“mismatch”没有意义至少要把transaction的id、地址、数据、时间戳打出来。否则回归失败时你要花大量时间从海量波形里捞那一拍异常。4.3 coverage它不是一个“刷百分比”的零件覆盖率有两种代码覆盖率和功能覆盖率。代码覆盖率交给仿真工具统计组件层面上通常要写的是功能覆盖率收集器也就是coverage collector它通常继承uvm_subscriber通过write()接收agent广播的transaction然后更新covergroup。但我想提醒一件事功能覆盖率不是为了把数字刷高而存在的。高覆盖率背后如果没有关键场景支撑那只是“随机碰巧碰到的表面覆盖”。真正有效的coverage要从设计spec出发提取那些容易出问题的边界场景协议握手、背压、错误地址、位宽切换、中断嵌套等等然后在covergroup里明确采样它们。coverage collector在数据通路里的角色是一个旁路观察者。它只消费transaction的副本不应该阻塞数据流也不应该在write()里做大量打印。把coverage和scoreboard分开的目的就是让“正确性检查”和“质量度量”两个关注点各管各的互不污染。5. 让组件协作的隐形规则config_db、factory和phase5.1 config_db组件之间不是靠全局变量传话UVM组件之间传参数最忌讳的就是“全局变量”和“跨层次绝对路径引用”。一个组件如果直接写tb_top.vif它就和这个顶层模块绑死了拿到其他环境立刻失效。UVM给出的替代方案是config_db机制。顶层模块在run_test之前把virtual interface set进去组件在build_phase里通过get取出来。典型写法// 顶层模块里 uvm_config_db #(virtual my_if)::set(null, uvm_test_top.*, vif, vif); run_test(my_test); // 组件里 if (!uvm_config_db #(virtual my_if)::get(this, , vif, vif)) uvm_fatal(CFG, vif not found in config_db)config_db最大的坑是路径和时机。路径写错get就返回0set时机太晚get同样拿不到。常见经验是父组件build_phase里对子组件要用的配置写在create子组件之前顶层模块的set老老实实写在run_test之前。这样最稳妥。5.2 factory不用改组件树就能换组件UVM的factory机制是实现验证环境可配置性的关键。它的核心操作有两步一是组件类必须用uvm_component_utils注册二是创建实例时用type_id::create而不是直接new。factory机制允许你在不修改env代码的前提下把某个组件替换成它的子类。比如想验证DUT在驱动错误时序下的表现不需要重新写一个env只要定义一个继承自原driver的子类重写drive_transaction然后在test里overrideclass my_driver_with_err extends my_driver; uvm_component_utils(my_driver_with_err) virtual task drive_transaction(my_transaction tr); super.drive_transaction(tr); // 在正常时序之后再额外插入一个错误脉冲 endtask endclass // test 或 test 的 build_phase 里 my_driver::type_id::set_type_override_by_type(my_driver_with_err::get_type());这个机制非常强大但它有一个重要前提组件必须是type_id::create创建的。如果有人在env里写了new(drv, this)那override永远不会生效。排查“为什么我的替换没起作用”时第一件事就是检查所有组件创建是否走factory。5.3 phase组件不是各跑各的而是共享一张统一时间表组件之间的协作时序由phase机制统一管理。build_phase自上而下执行保证父组件先构建、子组件随后构建connect_phase自下而上执行保证子组件的内部连接完成后父组件再去连接它们的端口。这个顺序不是随便定的——如果父组件的connect先跑它可能连到一个还没有完成内部初始化的子组件。run_phase是所有组件并行运行的时间消耗阶段。driver、monitor、scoreboard都在自己的run_phase里跑forever循环。但这里有个很多人栽过的跟头run_phase什么时候结束UVM靠objection机制判断。如果没有任何组件raise objectionrun_phase会立刻结束平台就像“空转一秒就退出”。常见做法是在test里让sequence运行期间抬一个objectiontask run_phase(uvm_phase phase); phase.raise_objection(this); seq.start(env.agent.sequencer); phase.drop_objection(this); endtask注意driver的run_phase通常是一个forever循环它会在仿真结束前一直转。这类常驻组件不应该随便在run_phase里raise_objection否则没人drop整个仿真会一直拖到超时。关于objection的“谁抬、谁放”要心里有数否则平台动不动就提前结束或者跑不完。6. 从零搭一个最小UVM平台骨架代码和首批踩坑清单6.1 最小可运行平台需要哪些零件很多人以为最小平台只要有driver、monitor、env就够了其实完整跑通一次验证至少需要transaction、sequence、sequencer、driver、monitor、agent、env、scoreboard、test和顶层模块。其中sequencer在简单场景里通常是个空壳类只需要继承uvm_sequencer #(my_transaction)但它依然必须存在因为sequence要挂在它身上。搭建顺序我建议这样走先定义transaction和interface再写sequence然后写driver和monitor把三者包进agent写env和scoreboard写test最后写顶层模块把虚拟interface注入并调用run_test。这个顺序能保证每一步都有明显的验证手段先编译过了再仿真有数据流动最后才谈比对和覆盖。6.2 让零件转起来的组装代码关键片段sequence是激励的源头它至少要有一个body任务class my_sequence extends uvm_sequence #(my_transaction); uvm_object_utils(my_sequence) function new(string name my_sequence); super.new(name); endfunction virtual task body(); repeat(10) begin req my_transaction::type_id::create(req); start_item(req); if (!req.randomize()) uvm_fatal(SEQ, randomize failed) finish_item(req); end endtask endclass顶层模块负责生成时钟、连接DUT、注入虚拟接口module tb_top; logic clk, rst_n; my_if vif(clk, rst_n); my_dut dut( .clk (clk), .rst_n (rst_n), .addr (vif.addr), .data (vif.data), .valid (vif.valid) ); initial begin clk 1b0; forever #5 clk ~clk; end initial begin uvm_config_db #(virtual my_if)::set(null, uvm_test_top.*, vif, vif); run_test(my_test); end endmodule另外要注意仿真命令里一定要把UVM库编译进去。很多“平台代码没问题但编译不过”的报错本质都是UVM包没加进编译列表。6.3 跑起来之后最容易撞上的几个坑以及排查路径我把自己调试UVM平台时最常遇到的四类问题整理成一张排查表希望对刚上路的人有帮助。现象可能原因排查路径仿真一跑就结束几乎没东西发生objection没抬起来或sequence没启动先看test的run_phase里有没有raise_objection再看seq.start是否真的执行了driver报空指针vif一直是nullconfig_db路径写错或者set时机太晚在组件里检查get返回值get不到就打印顶层实际存在的组件树路径sequence卡死仿真挂着不动driver没调item_done或者agent没连接seq_item_port用波形看driver是否进入run_phase再看是否卡在first dram求偶 uslscoreboard大量误报monitor采样沿不对或fifo没有对齐打印每一笔transaction的id和时间戳比对前先确认采样窗口我自己的一个习惯是遇到问题先打印组件树把整个层次结构看一遍。很多连接错误一眼就能看出来。再配合在driver、monitor、scoreboard关键位置加uvm_info基本上能把UVM平台前期的问题归到“没建、没连、没采、没比”四类里。这个排查口径比对着波形猜省时间得多也适合在团队里统一使用。
