UVM验证平台搭建与仿真调试全流程实战解析-平芜编程栈

做数字IC验证的，没有一个能绕开uvm验证平台搭建和仿真这道坎。芯片规模越大，验证平台的结构就越复杂，想在几天内从零搭出能跑、能查、能回归的平台，光靠拼组件是不行的。我自己的经验是，UVM这东西刚开始看文档会觉得玄，但一旦你亲手把driver、monitor、scoreboard这些组件挂起来，把时序和比对接通，就通了。这篇不写流水账，把UVM验证平台从架构设计到仿真调试的完整流程拆开讲，把那些文档里不会写明白的坑也一并列出来，给后来的人省点时间。

1. UVM验证平台搭建前的思路：先想清楚架构，再动手写代码

1.1 为什么验证平台需要UVM，而不是直接写testbench

很多人刚学验证时都是从纯SystemVerilog的testbench起步：在module里例化DUT，用initial块给信号赋值，再用$monitor看结果。这种写法在小模块上完全够用，但一旦DUT接口有几十个、测试用例有几十种，就会发现每个testbench都是独立的“死代码”——信号怎么写死在里面，断言和计分板全耦合在一起，要加一个新case往往需要改动整个testbench。

UVM解决的核心问题是可复用和可扩展。它把验证环境拆成标准化的组件，每个组件只负责一类事：driver发激励，monitor采样，scoreboard比对，sequence管理用例。对于同一个接口，你只需要写一套driver和monitor，不同的测试用例通过sequence来注入不同数据，而不是复制一整份testbench来改。

我在实际项目中的体会是，UVM平台搭建的难点不在SystemVerilog语法，而在组件之间的通信方式。你写的driver要能接收sequence发来的数据，monitor要能把采集到的数据主动推给scoreboard，这套握手机制靠的是uvm_analysis_port、uvm_seq_item_pull_port这些基础通信端口。刚开始你会觉得这些端口很绕，但用熟了之后，它们是整个平台能灵活运行的基石。

1.2 最小可用的UVM验证平台需要哪些组件

一个真正能跑起来的最小UVM验证平台，至少需要这几样东西：

组件	类型	职责
interface	SV接口	连接DUT和driver/monitor，定义信号时序
transaction	uvm_sequence_item	定义激励数据的结构
driver	uvm_driver	把transaction转成接口时序信号
monitor	uvm_monitor	从接口采样数据，转成transaction
scoreboard	uvm_scoreboard	比对期望数据和实际数据
sequence	uvm_sequence	生成一组transaction序列
agent	uvm_agent	封装driver、monitor、sequencer
env	uvm_env	组织agent、scoreboard、reference model
test	uvm_test	启动验证环境，配置sequence

有的教程会再加reference model、coverage collector、reg model，但那是完备平台的事。如果你只是想把UVM平台跑通，上面这些组件缺一不可，缺了任何一个，环境就没法闭环。我在搭建第一个UVM平台时，最常犯的错误是skip掉monitor和scoreboard，想着直接driver拉着DUT跑几个case，信号都对了就算完。但少了scoreboard的数据比对，后面的回归测试完全没有判断手段，出了问题根本不知道是DUT功能错了还是激励没给对。

1.3 先列功能点清单，再写transaction结构

很多新手在搭建UVM验证平台时是“拍脑袋式搭建”——想到什么写什么，最后代码堆了几百行，功能覆盖率却低得可怜。我个人的习惯是，在动手写任何UVM组件之前，先写一份功能点清单，把模块的输入输出端口、寄存器配置、关键时序、特殊模式都列出来。

比如一个简单的UART接收模块，我至少会列出这些功能点：

波特率配置：9600、115200，是否支持动态切换
数据帧格式：8N1、7E1，校验位和停止位如何配置
奇偶校验错误、帧错误、溢出错误的标志位行为
接收FIFO的满阈值和水位信号
背靠背数据连续接收是否会丢数据

这些功能点清单直接影响transaction的字段设计。如果有波特率配置，那transaction里就得有baud_rate字段；如果需要产生帧错误，那么transaction里就得允许故意发错校验位。我记得有一次项目里，功能点清单里写了“支持长帧超时”，我却在transaction里忘了加timeout相关字段，结果driver里要为此专门写死逻辑，后来的回归测试也一直没法覆盖这个场景，白白返工。

2. 核心组件怎么搭：driver、monitor、scoreboard实操要点

2.1 driver从sequence拿数据，再转成时序波形

driver是验证平台里最“累”的组件，它要做的事是：从sequencer那里拿到sequence发来的transaction，然后按照接口时序，把数据一个bit一个bit地打给DUT。

一个典型的driver代码长这样：

class my_driver extends uvm_driver #(my_transaction); `uvm_component_utils(my_driver) virtual my_if vif; function void build_phase(uvm_phase phase); super.build_phase(phase); if (!uvm_config_db#(virtual my_if)::get(this, "", "vif", vif)) `uvm_fatal("NOVIF", "virtual interface not found") endfunction task run_phase(uvm_phase phase); my_transaction req; // 先等复位释放 @(posedge vif.rst_n); // 复位拉低期间不发送数据 while (!vif.rst_n) @(posedge vif.rst_n); forever begin seq_item_port.get_next_item(req); // 等待总线空闲 while (vif.busy) @(posedge vif.clk); // 发送一个帧 for (int i = 0; i < req.data.size(); i++) begin @(posedge vif.clk); vif.tx_data <= req.data[i]; vif.tx_valid <= 1; end @(posedge vif.clk); vif.tx_valid <= 0; seq_item_port.item_done(); end endtask endclass

driver最容易出的问题是时序与DUT握手信号不同步。有些DUT有ready/valid握手，有些是固定周期延迟，你得在验证环境搭建时把接口时序完全吃透。还有一个常见错误是driver发完数据后忘了调用item_done()，result在sequence侧会一直等待，整个平台卡死。出现这种问题时，仿真日志里通常没有报错，只是时间无限往后走，task一直挂住。

我在验证一个SPI从机模块时，driver里没有处理DUT在burst期间插入wait state的情况，结果连续读操作时所有数据都偏了一位。当时查了很久才发现是driver对NCS拉低时序的理解不到位，直到把接口波形打出来才看出问题。所以driver的自检能力也很重要——如果driver在发完激励后能自己再回读一次接口上的数据并对比，很多时序问题可以早两个星期暴露。

2.2 monitor采集信号并推给scoreboard：别用时钟边沿采样踩坑

monitor做的事和driver正好相反，它从接口上采集数据和控制信号，整理成transaction，然后通过analysis port发送给scoreboard。它有两个常见的坑：采样边沿选错和数据多次采到。

拿SPI接口说，如果DUT在SCK上升沿输出数据，monitor就应该在SCK下降沿采样，否则你采到的信号刚好处在跳变边缘，读到的值极不稳定。这个事在真实项目里特别诡异——波形看起来挺好的，但scoreboard比对时总是间歇性不匹配，后来把采样沿改到另一个边沿就好了。

数据多次采到的坑也常见。比如一个持续多拍的valid信号，如果monitor只用if (vif.valid)去判断，会在同一个transaction上重复触发多次，导致同一个数据被发往scoreboard两次或者更多次。我处理这类问题时习惯写一个边沿检测逻辑：

always_ff @(posedge vif.clk or negedge vif.rst_n) begin if (!vif.rst_n) valid_d <= 0; else valid_d <= vif.valid; end wire valid_rise = vif.valid && !valid_d;

只在valid_rise拉到最高时，才去采集整包数据。另外推荐在monitor里加一个uvm_analysis_port #(my_transaction) ap;，这样monitor可以把采集到的数据发给任意多个订阅者，比如同时发给scoreboard和coverage collector。

2.3 scoreboard比对参考模型：建立清晰的期望数据来源

scoreboard是验证平台里判定“对错”的地方。它接收来自monitor的实际数据，也接收来自参考模型或预测逻辑的期望数据，然后把两者比对。

如果DUT是简单的组合逻辑或状态机，你可以在scoreboard里直接写个纯函数来生成期望数据。但如果是复杂的协议模块，比如以太网MAC，那就得专门写一个reference model，与DUT输入端对接，模拟DUT内部处理流程后产生期望结果。

一个典型的scoreboard片段长这样：

class my_scoreboard extends uvm_scoreboard; `uvm_component_utils(my_scoreboard) uvm_analysis_imp #(my_transaction, my_scoreboard) analysis_imp; my_transaction expected_q[$]; function void write(my_transaction t); if (t.direction == TX) expected_q.push_back(t); else begin if (expected_q.size() == 0) `uvm_error("SCB", "receive RX data but no expected data") else begin my_transaction exp = expected_q.pop_front(); if (exp.data != t.data) `uvm_error("SCB", $sformatf("data mismatch: exp %0h, got %0h", exp.data, t.data)) end end endfunction endclass

scoreboard最痛苦的是比对时机问题。如果你只是按数据到达顺序比对，而DUT有乱序或缓冲能力，期望队列的顺序就会错乱，比对结果全是假的Error。这种情况下，你得给每条transaction加唯一标识符（seq_id、packet_id），在比对时按标识符匹配，而不是简单地把队首数据弹出。

我自己写scoreboard时还有一个习惯：权威比对之前，先打印关键字段，比如数据长度、校验和、包号。因为一旦比对出错，你总得知道是哪个包的哪个字段对不上，光靠几个error没法定位。

2.4 agent与env的封装：层次化环境的组织思路

agent的作用是把driver、monitor、sequencer打包成一个可复用的单元。比如一个验证平台同时有AXI从机接口、APB主机接口和中断信号，你可以创建三个agent：axi_slave_agent、apb_master_agent、interrupt_agent。之后在env里例化这些agent，并通过config_db设置虚拟接口。

这里的核心原则是高内聚、低耦合：一个agent只管一种协议，不需要知道其他agent内部实现。在env里再搭一个router，负责把不同agent的数据转发给scoreboard。这样做的好处是，如果某个接口协议在项目中复用了，直接把这个agent copy过去，环境搭建时间能从两周压缩到两天。

env的build_phase里要格外注意创建顺序。uvm_env的build_phase有一个特点：子组件是在super.build_phase(phase)之后创建的，但如果你在agent的build_phase里要读取config_db中由env设置的参数，要注意设置时机，否则会拿到默认值而不是期望值。我常踩的坑是在env的build_phase里先创建agent，再给agent的路径设置config_db，结果agent在build_phase中读不到配置，导致driver里的virtual interface没有正确获取到，运行时报uvm_fatal。

3. 仿真跑起来：编译选项、Makefile与波形调试一条龙

3.1 仿真器编译选项的差异：VCS、Questasim与irun

UVM验证平台写完之后，跑仿真这一步的坑一点不比写代码少。不同仿真器对UVM的支持方式差异很大，UVM版本不匹配是最常见的问题。

VCS需要指定-ntb_opts uvm，Questasim/Modelsim需要在编译时-L uvm，irun则是默认嵌入UVM库。如果用的UVM库版本和仿真器内置版本不同，建议直接用+UVM_NO_DPI关掉DPI相关特性，省去一堆麻烦。我在VCS上跑UVM时，最常用的编译命令是：

vcs -sverilog +v2k -timescale=1ns/1ps \ -ntb_opts uvm \ -f filelist.f \ -debug_access+all \ -l compile.log

这里-debug_access+all很关键，不带它，你dump出来的VPD波形里看不到内部信号，debug会非常困难。filelist.f里要包含所有UVM源码文件、DUT的RTL文件，以及UVM环境代码。

QuestaSim/ModelSim跑UVM时，有些老的教程会让用户手动把UVM库的.sv文件添加到工程里，这就容易把UVM库编译多次，导致类型不匹配。在新版本Questasim上，直接vlib work后vlog -L uvm就够了。

3.2 Makefile与回归脚本：一个能自动跑完所有用例的仿真流程

仿真自动化这一环节特别能体现验证工程师的工程能力。我见过有同事手动在图形界面里一个一个跑case，跑完了再去翻波形日志，效率低得离谱。我在项目里默认用Makefile + 脚本组织仿真流程，核心要素是：

compile目标：编译DUT和UVM环境
sim目标：运行一个具体的testcase，传递seed和testname
regress目标：批量跑所有case，汇总pass/fail结果
clean目标：清理中间文件和日志

Makefile的关键部分我一般这样写：

UVM_TEST ?= base_test SEED ?= 1 TOP ?= tb_top compile: vcs -sverilog +v2k -timescale=1ns/1ps \ -ntb_opts uvm \ -f filelist.f \ -debug_access+all \ -l compile.log sim: ./simv +UVM_TESTNAME=$(UVM_TEST) \ +ntb_random_seed=$(SEED) \ +UVM_VERBOSITY=UVM_MEDIUM \ -l sim_$(UVM_TEST)_$(SEED).log regress: for test in base_test apb_read_test apb_write_test intr_test; do \ make sim UVM_TEST=$$test SEED=$$(od -An -N2 -tu2 /dev/urandom); \ done grep -E "UVM_ERROR|UVM_FATAL" sim_*.log || echo "ALL PASS"

这种流程跑一次回归，几百个log文件可以短时间内汇总出结果。我一般会用脚本提取每个测试的UVM_ERROR和UVM_FATAL数量，再把fail的list汇总到一行，这样CI系统也能解析出验证结果。

一个很容易被忽略的细节是：每次跑仿真都要换seed。UVM的sequence随机化依赖seed，如果所有case都用固定seed，很多边界条件永远不会被触发。我见过有人为了debug方便，把一个固定seed跑了好几个月，结果后来把seed换掉，第一天就崩了十几个case。

3.3 波形dump与debug：不是所有仿真器都能直接看UVM内部信号

现代验证里，UVM平台的报错信息已经能定位到component了，但真正难的问题还是得看波形。VCS用fsdb或vpd，Questasim用wlf或vcd，大多数EDA环境还支持fsdb由Novas的Verdi查看。

在UVM环境中dump波形，一般是在test或env里使用UVM自带的uvm_trace机制跟踪transaction，也可以用仿真器命令直接dump：

initial begin $fsdbDumpfile("dump.fsdb"); $fsdbDumpvars(0, tb_top); $fsdbDumpMDA(0, tb_top); end

dump内部信号时注意$fsdbDumpvars(0, tb_top)的层级表示dump所有嵌套信号，但会显著拖慢仿真速度。在debug阶段可以全dump，在回归阶段一般建议反正只看log，不dump或只dump出错case的波形。

还有个调试技巧：+UVM_TR_RECORD选项可以把transaction记录到UVM的日志文件里，方便追踪sequence从生成到被driver消费的整个过程。在遇到“driver没收到预期数据”这类问题时，用这个选项比盲猜快得多。

4. 仿真问题排查与Debug实录：高频坑汇总

4.1 波形全红、全X态：绝不是“DUT坏了”这么简单

Modelsim/Questasim仿真时经常会遇到波形线全是红色的情况。很多人的第一反应是“DUT有问题”，但根据我经验，这个问题大概率出在验证平台上。

常见原因有三种：

原因	排查方法	解决方法
复位信号没拉起来或过早释放	看rst_n波形、确认复位释放时间晚于所有时钟稳定	延长复位时间或等initial时刻后若干周期再释放
virtual interface没有正确连接	检查是否在test中config_db设置了vif，driver是否成功get到	打印build_phase中get到的vif句柄，确认非null
DUT的输入时钟未生成	确认tb_top中是否产生clock信号	在tb_top里initial块用forever #5 clk=~clk;

我遇到过最坑的一次是：所有波形都是红X，但代码看起来完全正常，后来发现是testbench里定义信号的默认类型是wire，而driver赋值时用的是<=，初始时刻wire没有任何驱动，DUT所有输入都是高阻态，仿真器给出X。改成logic并把驱动从continuous assignment改到always块里就正常了。

排X态问题时，我建议先在波形里检查时钟和复位，再看DUT输入端口的信号有没有真正连上。不要一味盯着DUT内部信号看，很多时候问题出在输入端根本没被正确驱动。

4.2 仿真卡住不死不活：挂死、超时与阻塞

UVM平台仿真卡死是仅次于全X的第二大问题。现象是log一直停在某一行，波形时间不再前进，CPU占用率却非常高或卡住不动。

常见原因写出来供排查：

sequence的item_done()没执行——driver发出数据后sequence侧没有收到done，导致sequence槽位一直被占用。
forever循环里没有等待事件——driver或monitor的run_phase里写了空转的forever，且在某个分支内缺少@(posedge clk)等事件，形成忙等。
TLM端口连接错误——scoreboard需要从两个analysis port接收数据，只连了一端，导致另一端永不触发。
phase_ready_to_end挂起——某个sequence还在等数据，但test想结束，平台的raise_objection机制导致end_of_test始终不能到达。

我查挂死问题时有一个习惯性操作：按暂停，看栈。图形界面下暂停仿真，查看当前执行到哪个task里，这样能直接看到是哪只task卡住了。如果是跑命令行的回归，可以在仿真脚本里加+UVM_MAX_QUIT_COUNT和timeout机制，case跑超过一定时间就自动杀掉，并标记为timeout。

另外在test里加一个总超时检查器很有用：

task automatic timeout_guard(); fork begin #1ms; `uvm_error("TIMEOUT", "simulation timeout") $finish; end join_none endtask

但注意这个timeout时间不能太短，否则排队的case全都被误杀。

4.3 UVM_ERROR与UVM_FATAL的利用：学会看log而不是瞎猜

UVM的报告机制非常强大。UVM_ERROR默认打印在log里，UVM_FATAL则会$finish或$fatal。所有报错消息中，信号名、时间戳、component路径都有明确信息。

排查问题前，先做三件事：

看有没有UVM_FATAL，有的话直接从uvm_fatal所在组件开始，因为它一般意味着环境配置失败而不是DUT错误。
看UVM_ERROR的数量，如果只有一两个案例，通常是某个transaction比对失败；如果一堆error，多半是环境本身的时序错乱。
UVM_WARNING不能全忽略，尤其是关于config_db没有get到、TLM连接不完整这类警告，很可能是环境没有按预期配置。

推荐开启+UVM_VERBOSITY=UVM_HIGH直接跑一遍最简case，把每个组件在build/connect/run阶段的日志都打出来，对照环境结构检查。这个方法通常比盯着波形盯半天更高效。

5. 寄存器模型与镜像值：寄存器验证最容易忽略的一块

5.1 为什么要用寄存器模型：前门访问和后门访问

很多UVM环境在验证寄存器模块时，还是用传统方式：在sequence里直接写driver接口的信号来对寄存器读写。这在初期能跑，但等到要验证寄存器复位值、不同访问粒度、保留位行为时，就很不方便了。

UVM的寄存器模型（RAL）通过uvm_reg_block、uvm_reg、uvm_reg_field来抽象寄存器，你可以用统一API来读写：

reg_model.ctrl_reg.write(status, 32'h1); reg_model.status_reg.read(status, data);

这套API可以在前门操作（通过bus agent实际发起读写时序），也可以后门操作（直接通过uvm_reg_backdoor访问DUT内部信号，不耗时）。后门访问的速度极快，非常适合初始化DUT状态或者检查某个寄存器的当前值。

要启用RAL，需要在验证平台里集成：

reg_model：uvm_reg_block的子类，定义所有寄存器和字段
adapter：把UVM的通用寄存器读写操作转换成特定总线协议的事务
predictor：通过观察总线操作结果来更新寄存器的预测值

5.2 镜像值是什么：为什么它总是和实际寄存器值对不上

寄存器模型里的镜像值（mirror value），是UVM寄存器模型中记录的“当前软件期望值”。它和实际DUT里的寄存器值不一定相同，因为DUT里可能被硬件自动改写、被其他master修改，或者有读清、写清等特殊行为。

镜像值的作用是让验证人员在不访问DUT的情况下，知道寄存器状态“应该是什么”。比如read()操作后，模型里的镜像值会更新为读到值；write()操作后，镜像值会更新为写入值。但如果你某个寄存器有硬件自动清除位，写入之后又被硬件拉低，镜像值和实际值就会不一致。

遇到镜像值和DUT实际值不一致时，具体排查思路是：

确认寄存器字段是否定义成了W1C、RC等特殊类型，这些位根本不能静态镜像。
确认没有在DUT内部又一组寄存器被硬件默认覆盖。
确认predictor是否正常工作——如果你的平台没有集成predictor，UVM寄存器模型根本不会自动更新镜像值。

我用后门方式调镜像值时常用的技巧是：

reg_model.ctrl_reg.mirror(status);

它会把DUT实际值读回来，与镜像值比对，如果不一致就报错。这在验证寄存器复位后状态时特别有用。

5.3 寄存器模型在仿真里的调试方法

我踩过这样一个坑：寄存器模型读回来的值一直不对，后来打印波形发现，模型监测的总线时钟域和DUT实际寄存器模块的时钟域不同，adapter里握手信号采样错位。在那个问题之后，我对寄存器模型调试形成了固定套路：

在适配器（adapter）的reg2bus()和bus2reg()函数里，打印读写地址、数据、使能信号，确认总线事务生成正确。
在DUT寄存器模块的接口上挂一个monitor，专门打印实际寄存器读写事务，比照模型是否追踪到。
若镜像值异常，优先确认predictor有没有挂在总线的monitor上——经常有人只做了前门读写，却没把monitor连到predictor，导致镜像值永远不变。

以前有个同事搭寄存器模型时图省事，没有挂predictor，直接在sequence里手动更新镜像值，测试模块内部逻辑时好像没问题，但等到验证team做回归，连续几十个case都报镜像不一致。最后查下来还是因为predictor缺失。所以说，寄存器模型的控制路径和数据路径至少得有完整的闭环，不然镜像值在复杂用例里完全不可信。

6. 仿真加速与回归管理：从单跑一个case到全量回归

6.1 仿真跑太慢怎么办：性能优化维度

验证平台搭好了，case也能跑了，等你开始跑回归就会撞上现实问题：一个case动辄几十分钟，1024个case怎么跑？

性能瓶颈通常不在UVM本身，而在于：

DUT规模大，门级仿真比RTL仿真慢10倍以上
UVM平台打印太多，配合UVM_HIGH会显著拖慢仿真
波形dump开启时，文件IO开销远大于仿真计算
sequence里数据量大，比如长包体循环，每次都是几千字节的数组操作

针对这些瓶颈，实践中的做法是：

回归时关掉波形dump，只有debug模式下开波形。
使用UVM_VERBOSITY控制打印等级，回归用UVM_NONE或UVM_LOW，只在失败case里再重跑UVM_HIGH。
关掉UVM的报告服务器自动匹配，避免每一条报告都做额外处理。
使用多线程仿真，在VCS上可以用-j选项，让不同test并行跑。
绿灯条件下，考虑用Verilator加速UVM仿真。Verilator原本更适合做纯SystemVerilog和C++联合仿真，但因为Verilator不原生支持UVM的所有验证特性，你需要做一些适配。我自己在验证一些比较偏RTL的模块时，会用Verilator做编译型仿真，跑回归比VCS快好几倍。但要小心：Verilator对UVM的DPI支持有限，sequence机制和analysis port都可能需要额外适配。如果你的平台高度依赖UVM的高级特性，就跑不了Verilator。

6.2 回归管理与seed策略：验证收敛的逻辑

回归管理听起来是流程问题，但实际上是效率和稳定的根本。我在管理UVM回归时，一般把case分成几类：

冒烟测试：每个case跑1个seed，确保平台能编译、能启动、无fatal。
确定性回归：固定case、固定seed，每天跑一遍，用于快速锁定回归失败。
随机回归：随机seed，大量随机case，用来探测设计边界，通常是夜里跑。

每次回归结束后，我会用脚本提取三类数据来评估：

指标	说明
PASS/FAIL/Timeout数量	判定整体健康度
UVM_ERROR总量	如果0就说明所有比对通过
覆盖率数据	有没有未覆盖的功能点

过程中最容易遇到的问题就是：“昨天还pass，今天加了一个case后全fail”。这种问题多半不是新case的问题，而是平台某个组件有全局状态残留，比如scoreboard里队列没在test结束前清空，下一个case接着跑时还带着旧数据。解决方式是在reset_phase或reset()方法里清理所有队列、清空计数。

这个经验很重要，尤其是做platform级别的并行回归时，case之间的隔离必须写进环境设计里。我一般在connect_phase之后调reset_phase，把所有组件恢复到初始状态，避免上次残留数据污染下一次运行。

6.3 我给新人的实操建议：从项目第1天就用正规打法

最后说我个人的体会。入行验证这几年，我最大的感受是：UVM平台搭建和仿真的天花板不是语法，而是设计环境结构的能力。

新人最容易犯的错是急着写代码，然后在代码里堆if-else和全局变量，最后平台乱成一团。正确做法是先用文字描述好验证目标和功能点，再搭出组件结构图，然后逐个实现组件、跑冒烟、加回归。

我自己的“标准起手式”是这样的：

先写一个空的uvm_test，只打印uvm_info，确认环境能编译、能跑起来。
加interface和driver，先造最简信号，让DUT能正常复位。
加monitor和scoreboard，先做“只输出不比对”，确认两边数据都能采集到。
加reference model和正式比对逻辑。
最后加寄存器模型、覆盖率收集、随机约束和回归脚本。

每一步都能在半天内跑通，出了问题能立刻定位到具体组件，而不是憋了一个月的代码后一次性面对所有问题。

还有一件值得提醒的事：保存每次调试时的编译log和仿真log，留着以后翻。UVM平台里很多问题都有极强的相似性，比如“昨天还好好的，今天突然fatal”，翻log时如果能找到半个月前的同一份报错，就能快速定位是哪次改动引起的回归。反过来，换新环境时也可以拿一份全量回归的基线log和当前对比，比在新环境里从头调要省力得多。

这些习惯看起来不起眼，但拉长到项目周期里，省下来的时间非常可观。验证工程师一天的产出，有一半都取决于debug和回归的顺畅程度，而这两个环节的顺畅程度，基本取决于你在平台搭建阶段埋下的设计规范。反正我后来再搭任何模块的UVM验证平台，都会把上面这些流程从头走一遍，一次到位。