UVM Phase本质：run_phase是硬件时序执行基座，main_phase是全局协调锚点-平芜编程栈

1. 这个“Phase分工”说法，从根上就混淆了UVM的执行模型

你是不是也见过这样的代码片段：在某个UVM Testbench里，driver类的run_phase任务里写满了seq_item_port.get_next_item()和drv_bus_if.drive_item()；monitor类的run_phase里堆着@(posedge vif.clk)采样信号、打包事务、再mon_item_port.write()；而顶层test类却把所有激励生成逻辑——比如seq.start()、env.cfg.enable_feature_x = 1、甚至uvm_config_db#(int)::set()——一股脑塞进main_phase里？然后团队里有人拍板：“Driver/Monitor用run_phase，Test用main_phase，这是UVM最佳实践！”

这个说法，不是“不严谨”，而是根本性错误。它把UVM Phase机制的底层设计意图完全颠倒了。

UVM Phase不是按“组件类型”划分职责的容器，而是按“执行时序”定义的同步点。run_phase是UVM中唯一一个并行执行、持续运行、无固定时长的phase——它像一条永不停歇的流水线，所有组件的run_phase任务在同一时间窗口内并发启动，并一直跑到底（直到仿真结束或被显式终止）。而main_phase只是run_phase内部的一个子阶段（sub-phase），它本身没有独立的调度器，它的存在意义只有一个：为需要严格时序对齐的验证活动提供一个可预测的、全局同步的“时间锚点”。

提示：UVM 1.2标准文档Section 3.3.2明确指出：“The run_phase is the primary phase for functional simulation. All components that need to actively participate in simulation must implement a run_phase task.” —— 注意关键词是“actively participate”，不是“only driver/monitor can”。而main_phase在UVM Phase图谱中被定义为run_phase的子phase，其执行依赖于run_phase的启动，且默认时长为0（除非用户显式设置phase.raise_objection()并drop_objection()）。

为什么这个错误如此普遍？因为很多初学者看到run_phase里写了驱动/采样逻辑，就误以为“只有驱动和监控能在这里干活”；看到main_phase里常用来启动sequence，就以为“test就该在这里发包”。这就像看到厨房里厨师在灶台前炒菜，就断定“只有厨师能站在灶台边”，却忽略了灶台本身是整个厨房的能源中心，切菜工、配菜员、传菜员都在同一片热源区域协同作业——他们只是分工不同，但共享同一套时间基准。

真正决定“谁在哪个phase做什么”的，不是组件类型，而是行为性质：

需要持续响应硬件信号、实时驱动总线、不间断采样波形的行为 → 必须放在run_phase（因为只有它能提供连续的时钟域感知能力）；
需要与其它组件精确对齐、在特定仿真时刻统一触发、有明确起止边界的行为 → 应放在main_phase（例如：所有agent同时开始接收配置、所有sequencer在第1000ns统一启动sequence、DUT reset释放后等待5个周期再发第一个包）；
需要跨多个phase协调、依赖前期准备结果、或需人工干预时机的行为 → 可能落在configure_phase、reset_phase、shutdown_phase等更早或更晚的phase。

所以，当你把test的main_phase当作“发包主战场”，而把driver的run_phase当作“唯一干活区”，你实际上是在强行割裂一个本应紧密耦合的执行流：test在main_phase里调用seq.start()，但sequencer必须在run_phase里才能真正分发item；driver在run_phase里等着拿item，可item的生成节奏却被test的main_phase时序所绑架——这导致仿真中出现大量get_next_item()阻塞、sequence timeout、或者更隐蔽的时序错位：比如monitor在run_phase里采到的transaction，其timestamp与test在main_phase里记录的expected值存在1个cycle偏差，debug时翻遍波形都找不到原因。

我去年帮一个存储控制器项目做UVM架构复审，发现他们正是这么干的。结果在压力测试下，DMA burst传输的最后一个beat总是被漏采，查了三天才发现：test在main_phase末尾调用seq.stop()，但driver的run_phase还在循环等待下一个item，sequencer的get_next_item()因无新item而超时返回null，driver误判为传输结束，提前拉高ready信号，导致DUT认为burst已完成，而monitor此时刚采到倒数第二个beat——整个数据链路的完整性校验因此失败。修复方案？把sequence启动逻辑从test::main_phase移到test::run_phase，并用phase.is_before(uvm_main_phase::get())做前置判断，确保所有组件在main_phase开始前已进入稳定驱动状态。一行代码没改，问题消失。

2. Driver/Monitor 的 run_phase：不是“只能用”，而是“必须用”的底层硬约束

如果你翻过UVM源码里的uvm_component.svh，会发现run_phase任务被声明为virtual task run_phase(uvm_phase phase)，且所有基础组件（uvm_driver、uvm_monitor、uvm_sequencer）都重写了它。这不是巧合，而是UVM框架设计者埋下的执行铁律：任何需要与DUT硬件接口实时交互的组件，其核心逻辑必须扎根于run_phase。原因有三，且每一条都直指数字电路验证的本质。

2.1 时钟域同步：run_phase 是唯一能天然感知 clock edge 的 phase

想象一下你的DUT是一个PCIe控制器，工作在100MHz系统时钟下。driver要做的，是在每个clk上升沿将data、addr、valid信号准确置位；monitor则需在clk上升沿捕获rdy、ack信号变化，判断事务是否完成。这些操作不是“每隔10ns执行一次”，而是严格绑定在时钟边沿事件上。UVM的run_phase任务内部，编译器会自动插入@(posedge vif.clk)或forever @(posedge vif.clk)这类语句（取决于你是否显式编写），让任务挂起在时钟事件上，实现零延迟响应。而main_phase呢？它只是一个抽象的时间窗口标记，没有内置的时钟敏感机制。你若在main_phase里写@(posedge vif.clk)，会立刻报错：Illegal reference to non-blocking assignment or event control outside of always/initial block——因为main_phase本质是task，不是always块。

实测对比：我在一个AXI总线验证环境中做过对照实验。将driver的驱动逻辑从run_phase挪到main_phase，并手动加repeat(10) @(posedge vif.aclk)模拟10个周期。结果发现：

第1次仿真，driver在main_phase启动后，因vif.aclk尚未产生（reset_phase刚结束，时钟可能未稳定），@(posedge vif.aclk)永远等不到边沿，整个仿真卡死；
强制加initial begin #100; end延时后，driver终于开始驱动，但第3个@(posedge vif.aclk)时，monitor在run_phase里已采到awvalid为高，而driver的main_phase逻辑还在处理第2个周期，导致awaddr更新滞后1 cycle，DUT地址解码错误；
最终波形显示：driver输出的awaddr比monitor采到的awaddr晚整整1个aclk周期，时序违例（setup violation）直接触发DUT assertion fail。

注意：UVM Phase调度器本身不管理硬件时钟。run_phase的“时钟感知”能力，完全依赖于你在该task内编写的@(posedge xxx)语句。但正因如此，run_phase提供了最干净的语法糖——你只需专注写驱动/采样逻辑，框架保证它在正确的仿真时间点被调度。

2.2 并发执行模型：run_phase 是唯一支持 true parallelism 的 phase

UVM的run_phase采用协程（coroutine）模型调度。当你在driver、monitor、sequencer的run_phase里分别写forever begin ... end循环时，UVM Runtime在仿真器内部为每个组件创建独立的执行上下文，它们像多线程一样并发运行，互不阻塞。driver在等seq_item_port.get_next_item()返回时挂起，monitor仍在@(posedge vif.clk)采样，sequencer也在后台处理sequence queue——三者共享同一仿真时间轴，但各自独立推进。

而main_phase是串行化执行的。UVM规定：所有组件的main_phase任务，必须按build_phase构建的层次顺序依次执行。即：先执行top_test::main_phase，再执行env::main_phase，再执行agent::main_phase……直到最底层的driver::main_phase。这意味着，如果你把driver的驱动逻辑放进main_phase，它必须等到test、env、agent的main_phase全部执行完才能开始——而此时DUT可能早已复位完成、时钟跑了几千个周期，driver一上来就要面对一个“已经运行中”的DUT，无法从初始状态开始同步。

我曾调试过一个USB PHY验证项目，客户坚持把driver的run_phase逻辑全搬到main_phase。结果现象很诡异：每次仿真，driver发出的第一个SOP（Start of Packet）信号，其line_state总是错误地处于J-state（应为K-state），导致DUT拒绝接收。查波形发现，main_phase启动时，vif.line_state信号已被DUT内部逻辑初始化为J，而driver的main_phase代码还没来得及将其置为K。根源在于：main_phase执行时，DUT的reset release和clock enable已在reset_phase和configure_phase完成，硬件状态已演进，driver失去了对初始电平的控制权。解决方案？回归run_phase，在第一个@(posedge vif.clk)前，用force vif.line_state = 2'b10;强制初始化——run_phase的并发特性允许你在DUT状态稳定前就抢占控制权。

2.3 Objection 机制：run_phase 是唯一能自主管理仿真生命周期的 phase

UVM的objection机制是控制仿真启停的核心。run_phase默认启用raise_objection()，意味着只要有一个组件在run_phase里没drop_objection()，仿真就不会结束。driver和monitor正是靠这个机制，确保自己“活”到DUT事务全部完成。例如，driver在run_phase里每发完一个item，就phase.raise_objection(this)；monitor每采到一个item，也raise_objection()；当sequencer的queue空了，driver检测到get_next_item()返回null，主动drop_objection()；monitor在DUT idle后不再采到新item，也drop_objection()——最终所有objection被drop，run_phase自然结束。

main_phase没有这种内置objection管理。它默认时长为0，执行完立即退出。你若把驱动逻辑放进去，它执行完就没了，不管DUT是否还在处理数据。更糟的是，main_phase的objection需要手动管理，且极易出错：test::main_phase里raise_objection()，但忘了在driver::main_phase里drop_objection()，仿真永远卡住；或者driver::main_phase里drop_objection()太早，monitor还没采完数据，仿真就结束了。

表格对比run_phase与main_phase在 Driver/Monitor 场景下的关键差异：

特性	`run_phase`	`main_phase`
时钟同步能力	原生支持`@(posedge clk)`，无缝对接硬件时序	无内置时钟感知，`@(posedge clk)`语法非法
执行模型	组件间并发执行，各自独立推进	组件间串行执行，严格按层次顺序
生命周期管理	内置 objection 机制，自动关联仿真启停	无默认 objection，需手动管理，易出错
DUT状态控制	可在 DUT reset 后、clock 稳定前抢占初始化	执行时 DUT 状态已演进，失去初始控制权
调试可见性	波形中清晰对应每个 clock cycle 的驱动/采样动作	逻辑被压缩在单一时间点，时序关系模糊

所以，说“Driver/Monitor 用 run_phase”不是一种风格选择，而是由数字电路验证的物理约束决定的工程必然。它不是UVM的“推荐做法”，而是UVM框架为适配硬件仿真本质而设计的底层契约。违背它，等于在水泥地上种水稻——土壤根本不支持。

3. Test 的 main_phase：被严重误用的“伪主战场”

如果说把driver/monitor塞进main_phase是技术硬伤，那么把test的全部逻辑塞进main_phase，就是一种典型的认知懒惰——用一个看似“整齐划一”的phase，掩盖了验证流程中本应精细拆解的多个关键阶段。main_phase在UVM中真正的定位，是“协调中枢”，而非“执行引擎”。

3.1 main_phase 的真实使命：做 phase 间的“交通警察”，而非“搬运工”

翻开UVM Phase图谱（UVM 1.2 Spec Figure 3-1），main_phase被明确定义为run_phase的子phase，其设计初衷是解决一个经典问题：在复杂的多agent验证环境中，如何确保所有组件在同一个仿真时刻，同步进入“正式业务模式”？例如，在一个SoC级验证中，CPU agent、DMA agent、PCIe agent需要在DUT reset release后的第100个sys_clk周期，同时开始发送配置请求；或者，在启动一个burst传输前，必须确保memory controller的init_done信号为高，且所有slave agent的cfg_valid已置位。main_phase就是为此而生的“全局同步点”。

它的正确用法，是在 test 中发起跨组件的协调指令，而不是执行具体业务逻辑。典型场景包括：

统一配置下发：uvm_config_db#(int)::set(null, "*.env.agent*.cfg", "enable_debug_mode", 1);—— 此处*.env.agent*.cfg通配符确保所有agent的config对象在main_phase开始前已通过build_phase创建，set()操作在main_phase执行，保证所有agent在run_phase启动时读取到一致的配置值；
多agent协同启动：env.cpu_agent.sequencer.start(cpu_seq); env.dma_agent.sequencer.start(dma_seq);—— 这些start()调用本身不发包，只是向sequencer提交sequence handle；真正的item分发，发生在sequencer的run_phase里，由main_phase的调用触发同步点；
环境状态检查：if (!env.mem_ctrl.is_init_done()) begin $fatal("Memory controller init failed!"); end—— 在main_phase开头检查关键DUT模块是否ready，避免run_phase启动后才发现致命错误，浪费仿真时间。

我参与过一个AI加速器验证项目，其test类曾把所有sequence启动、寄存器配置、中断使能全堆在main_phase。结果在回归测试中频繁出现“timeout waiting for interrupt”错误。Debug发现：main_phase里env.intc.enable_irq(0x1)执行后，DUT的中断控制器需要3个sys_clk周期才能真正生效；但main_phase执行完立即进入run_phase，driver在第一个@(posedge sys_clk)就尝试触发中断源，此时intc尚未ready，中断被丢弃。修复方案？将enable_irq()移至configure_phase（确保在run_phase前完成），并在main_phase开头加@(posedge sys_clk); @(posedge sys_clk); @(posedge sys_clk);等待3周期——但这违背了main_phase的设计本意。更优雅的解法：在test::run_phase里，用fork...join_none启动一个check_intc_ready()任务，它循环检查intc.status直到ready==1，再raise_objection()；driver的run_phase只在收到objection后才开始驱动。这样，main_phase回归其本职：做协调，不做执行。

3.2 把 test 逻辑全塞 main_phase 的三大陷阱

陷阱一：时序错位（Timing Misalignment）
main_phase的执行时间点，由UVM Phase调度器决定，但具体到微秒级，它受build_phase耗时、reset_phase中DUT reset duration、甚至仿真器优化策略影响。你无法精确预知main_phase在仿真时间轴上的绝对位置。而driver/monitor的run_phase，其第一个@(posedge clk)必然发生在reset_phase结束后第一个时钟边沿。两者之间存在不可控的gap。把sequence启动放在main_phase，等于把“发包时刻”交给一个不确定的黑箱。

陷阱二：资源竞争（Resource Contention）
main_phase是串行执行的。如果test::main_phase里调用env.cfg.set_all_params()，而env::main_phase里又调用agent.cfg.update_from_db()，两者都试图修改同一块config memory，极易引发race condition。UVM的uvm_config_db虽是线程安全的，但set()和get()之间的时序窗口，仍可能导致agent读到旧值。run_phase的并发模型则天然规避此问题：test在run_phase里set()，agent在自己的run_phase里get()，两者在不同协程中，无共享内存冲突。

陷阱三：调试失焦（Debugging Obscurity）
当仿真失败时，你打开波形，看到driver在run_phase里驱动了100个包，monitor采到了99个，第100个丢失。你自然聚焦于driver和monitor的run_phase逻辑。但如果test的main_phase里有一行seq.randomize() with {len == 100;}，而randomize()失败导致实际只生成了99个item，这个bug却隐藏在main_phase的代码里，与波形中的驱动/采样行为完全脱节，debug路径被人为拉长。

提示：UVM官方示例（如uvm-1.2/examples/simple_test）中，test类的main_phase仅包含seq.start()调用，且注释明确写着“Start the sequence on the sequencer”。它从未把sequence定义、随机化约束、配置设置等逻辑放进来。

3.3 Test 的正确 phase 分工：让每个 phase 做它最擅长的事

一个健壮的test类，其phase布局应像一个精密的齿轮组：

build_phase：构建testbench骨架。实例化env、seq、cfg对象；设置uvm_config_db的初始值（如uvm_config_db#(int)::set(this, "env", "verbosity", UVM_HIGH)）；绝不在此处做任何DUT交互或随机化。
configure_phase：完成DUT软硬件配置。调用env.cfg.load_default_config()；通过APB bus sequence写DUT寄存器，设置工作模式、中断mask、buffer地址等；确保所有配置在run_phase开始前生效。
main_phase：执行全局协调。调用env.cpu_agent.sequencer.start(cpu_seq)、env.dma_agent.sequencer.start(dma_seq)；检查env.dut.is_ready()；只做“发令枪”，不做“跑步”。
run_phase：处理动态交互。启动一个fork...join，在子线程中监听DUT中断、响应back-pressure、根据monitor采到的status动态调整后续sequence参数；这才是test的“智能大脑”所在。

去年我帮一家FPGA公司重构他们的PCIe验证test，原test::main_phase有200行代码，涵盖从寄存器配置到sequence启动再到error injection。重构后，main_phase只剩8行：3行start()调用，2行is_ready()检查，3行$display日志。所有复杂逻辑移入run_phase的fork块。结果：回归测试通过率从82%提升至99.7%，debug平均耗时从4.2小时降至0.7小时——因为失败case的root cause，90%都集中在run_phase的动态决策逻辑里，波形和log能直接映射到代码行。

4. 那么，Test 到底该用哪个 phase？答案是：全都要，但各司其职

抛开“Test该用哪个phase”的伪命题，真正的问题是：一个完整的UVM test，其不同职责，天然适配不同的phase，强行归一化只会制造混乱。就像不能要求厨师、采购员、收银员都在收银台工作一样，UVM的phase体系，本质是一套为验证活动量身定制的“职能分工协议”。

4.1 Phase 选型决策树：基于行为本质的五维判断法

当你为一段test逻辑选择phase时，别问“它该放哪里”，而要问这五个问题：

是否需要与DUT硬件信号实时交互？
→ 是：必须run_phase（如：响应DUT interrupt、根据ready信号动态调整驱动节奏）；
→ 否：看下一步。
是否需要在DUT reset后、clock稳定前完成？
→ 是：configure_phase（如：通过JTAG写DUT fuse、设置PLL倍频系数）；
→ 否：看下一步。
是否需要作为全局同步点，协调多个组件？
→ 是：main_phase（如：统一启动所有agent的sequence、广播global config update）；
→ 否：看下一步。
是否涉及testbench结构的静态构建？
→ 是：build_phase（如：new一个env、create一个seq、set_config_int）；
→ 否：看下一步。
是否需要在仿真结束前做清理或报告？
→ 是：shutdown_phase（如：调用coverage.report()、uvm_report_server::get().print_summary()、关闭file handle）。

这套判断法，我在带新人时反复强调。它不依赖记忆，而是基于逻辑推演。例如，写一个“验证DUT在低功耗模式下唤醒功能”的test：

build_phase：构建env，创建lp_wakeup_seq；
configure_phase：通过APB sequence写PMU_CTRL寄存器，使能wakeup source；
main_phase：调用env.pmu_agent.sequencer.start(lp_wakeup_seq)，确保所有wakeup source在run_phase开始前已配置好；
run_phase：fork一个wait_for_wakeup()任务，它@(posedge vif.wakeup_irq)等待中断，成功后raise_objection()；另一个drive_sleep_cmd()任务，在@(posedge vif.sys_clk)后第1000 cycle，发sleep command；
shutdown_phase：检查coverage.get_coverage()是否达到95%，打印$sformatf("Wakeup coverage: %0.2f%%", cov_pct)。

4.2 实战案例：一个“自适应流量控制”test的phase拆解

假设你要验证一个网络交换芯片的flow control功能：当output port buffer occupancy > 80%时，DUT应拉高pause信号，通知input port减速。test需动态调整注入速率，以触发并验证pause机制。

class flow_control_test extends uvm_test; // build_phase: 构建骨架 function void build_phase(uvm_phase phase); super.build_phase(phase); env = my_env::type_id::create("env", this); // 创建两个sequence：high_rate_seq 和 low_rate_seq high_rate_seq = high_rate_seq::type_id::create("high_rate_seq"); low_rate_seq = low_rate_seq::type_id::create("low_rate_seq"); endfunction // configure_phase: 配置DUT function void configure_phase(uvm_phase phase); super.configure_phase(phase); // 通过reg model写DUT flow control threshold register env.reg_model.flow_ctrl_thre.write(status, 80, .parent(this)); endfunction // main_phase: 全局协调启动 task main_phase(uvm_phase phase); super.main_phase(phase); // 启动高负载sequence，触发buffer满 env.input_agent.sequencer.start(high_rate_seq); // 启动monitor，监听pause信号 env.output_agent.monitor.start_pause_monitor(); endtask // run_phase: 智能决策核心 task run_phase(uvm_phase phase); super.run_phase(phase); fork // 任务1：监控buffer occupancy，动态调整rate begin int current_occupancy; forever begin // 从DUT寄存器读取当前occupancy env.reg_model.buffer_occupancy.read(status, current_occupancy, .parent(this)); if (current_occupancy > 80) begin `uvm_info("TEST", $sformatf("Buffer full: %0d%%, switching to low rate", current_occupancy), UVM_LOW) // 发送命令给sequencer切换sequence env.input_agent.sequencer.switch_to_seq(low_rate_seq); end else if (current_occupancy < 30) begin `uvm_info("TEST", $sformatf("Buffer low: %0d%%, switching to high rate", current_occupancy), UVM_LOW) env.input_agent.sequencer.switch_to_seq(high_rate_seq); end #1000; // 每1000ns检查一次 end end // 任务2：监听pause信号，验证时序 begin bit pause_asserted = 0; forever @(posedge env.vif.pause) begin pause_asserted = 1; `uvm_info("TEST", "Pause signal asserted", UVM_HIGH) // 记录assertion time pause_time = $time; end // 当pause deassert，检查deassertion time是否符合spec forever @(negedge env.vif.pause) begin if (pause_asserted) begin real duration = $time - pause_time; if (duration < 1000 || duration > 5000) begin `uvm_error("TEST", $sformatf("Pause duration %0.1f ns out of spec [1000, 5000] ns", duration)) end pause_asserted = 0; end end end join_none // 等待仿真结束 phase.raise_objection(this); wait (env.done_event.triggered()); phase.drop_objection(this); endtask // shutdown_phase: 收尾报告 function void shutdown_phase(uvm_phase phase); super.shutdown_phase(phase); $display("Flow Control Test Summary:"); $display(" - Pause assertion count: %0d", pause_count); $display(" - Duration compliance: %0d/%0d", pass_count, total_count); endfunction endclass

这个例子清晰展示了phase的合理分工：build_phase搭架子，configure_phase设参数，main_phase发号施令，run_phase做智能决策和实时响应，shutdown_phase交答卷。main_phase里只有两行start()，却为run_phase的复杂逻辑铺平了道路。

4.3 关于“Test用main_phase”的历史成因与破除路径

为什么“Test用main_phase”会成为一种流传甚广的误解？根源在于早期UVM教程的简化教学。为了降低入门门槛，很多tutorial把test写成一个极简版本：build_phase创建env，main_phase里seq.start()，然后结束。学员记住了“test的main_phase发包”，却忽略了教程省略了configure_phase的寄存器配置、run_phase的错误恢复、shutdown_phase的覆盖率收集等真实项目必需环节。

破除这个迷思，需要两个行动：

重构你的test模板：新建一个base_test类，强制覆盖所有phase，哪怕内容为空。在main_phase里只写// Coordination point. Do not put business logic here.；
Code Review Checklist：在团队code review中，加入一条硬性规则：“任何test::main_phase中出现seq.randomize()、uvm_config_db::set()、$display以外的语句，必须附带phase选型依据说明”。

我在上一家公司推行此规则后，新入职工程师的test代码质量提升显著。一位实习生写的第一个test，main_phase里有seq.randomize() with {len == 100;}，他主动在commit message里写：“此处randomize放main_phase，因需确保所有agent在run_phase开始前获得一致的len值，避免sequencer间length mismatch。若放run_phase，则各agent可能拿到不同len，破坏测试一致性。”——这比盲目遵循“best practice”强百倍。

5. 踩坑实录：那些因phase误用而血泪交织的debug之夜

理论讲得再透，不如一个真实踩过的坑来得刻骨铭心。以下是我和团队在过去三年中，因phase误用导致的五个典型故障，每一个都耗费了至少8人时，每一个的root cause都直指对run_phase/main_phase本质的误解。

5.1 坑一：Monitor采不到第一个包——main_phase里的“幽灵延时”

现象：monitor在run_phase里@(posedge vif.clk)采样，但波形显示，DUT在reset释放后第1个clk上升沿就发出了valid=1，monitor却从第2个clk才开始采。第一个包永远丢失。

排查链路：

Step 1：检查monitor::run_phase代码，确认forever @(posedge vif.clk)写法无误；
Step 2：在monitor的run_phase开头加$display("Monitor run_phase start at %0t", $time);，发现输出时间为105ns；
Step 3：在DUT top module加$display("DUT reset done at %0t", $time);，输出为100ns；
Step 4：追踪UVM Phase log，发现run_phase启动时间为105ns，而reset_phase结束于100ns；
Step 5：深入UVM源码，发现reset_phase结束后，UVM调度器会执行uvm_phase::execute_phase()，其中包含m_run_phase.execute()调用，而execute()内部有#1的隐式延时（用于确保所有组件的reset_phase彻底完成）；
Step 6：最终定位：test::main_phase里有一行#5ns;的延时语句（开发者想“等DUT稳定”），导致main_phase执行完毕后，run_phase的调度被推迟了5ns，叠加UVM自身的#1，总延时6ns，正好错过第一个clk。

修复：删除test::main_phase里的所有#xxx延时，改用@(posedge vif.clk)或wait(vif.clk === 1)等事件驱动方式。main_phase里不该有时间概念。

5.2 坑二：Driver发包速率忽快忽慢——run_phase里的“objection雪崩”

现象：driver在run_phase里seq_item_port.get_next_item()后，驱动一个burst，但burst长度在16-64之间随机波动，且无规律。

排查链路：

Step 1：检查sequencer的get_next_item()逻辑，确认item的len字段在randomize()时被正确约束；
Step 2：在driver::run_phase里加$display("Got item len=%0d at %0t", item.len, $time);，发现len值正常；
Step 3：观察driver驱动波形，发现valid信号在len=16时，ready响应很快；len=64时，ready响应明显变慢；
Step 4：在driver::run_phase里加$display("Before get_next_item at %0t", $time);和$display("After get_next_item at %0t", $time);，发现get_next_item()调用耗时从10ns跳到500ns；
Step 5：检查sequencer的get_next_item()实现，发现它内部有while(!m_queue.size()) begin m_event.wait(); end，而m_event的trigger()被放在sequencer::run_phase的send_request()之后；
Step 6：最终定位：test::run_phase里，一个fork块中，driver的`get