很多 UVM 环境第一次出现“仿真提前结束”时，波形里往往已经能看到最后一笔激励，但 scoreboard 没有收到最终响应，覆盖率也没有采完，日志却突然进入后续 phase。排查 driver、monitor 和 scoreboard 都看不出明显错误，最后才发现问题并不在数据路径，而在 objection：整个 main_phase 根本没有足够的活跃异议，UVM 认为当前阶段已经没有事情需要等待，于是直接关闭 phase 并终止仍在运行的进程。
另一种现象正好相反。某个无限循环忘记 drop objection，仿真一直不结束，回归只能靠超时被杀掉。两种问题的表象不同，根因却相同：团队把 objection 当成了简单的延时开关，而没有把它理解为 phase 之间的结束契约。objection 不负责制造时间，也不负责启动仿真，它回答的是一个更基础的问题：当前这个 task phase 里，是否还有尚未完成的工作需要整棵组件树继续等待。
一、phase 结束不是由最后一行代码决定
UVM 的 function phase 不消耗仿真时间，build、connect、end_of_elaboration 等阶段按照调用关系执行完毕后自然进入下一阶段。run-time phase 则不同，它包含需要消耗时间的 task 代码，可能存在无限循环、握手等待、队列阻塞和跨组件并发。UVM 无法靠代码行号判断这些工作何时完成，因此用 objection 充当统一的活动计数。
进入一个 run-time phase 后，UVM 会观察组件树中是否有人 raise objection。只要当前 phase 仍存在未撤销的 objection，整个 phase 继续运行；当最后一个 objection 被 drop 后，phase 才可以结束并进入下一个阶段。如果从进入该 phase 到结束都没有任何 objection，UVM 不会因为某个 component 写了一百行代码或等待一百个时间单位就停下来等它，而是把这一阶段直接推进过去。
这个机制最容易产生误解的地方在于，objection 是 phase 级的，不是 component 级的。只要任一组件在该 phase 提起了 objection，其他组件的 task 代码也会获得运行机会。反过来，如果没有任何组件提起 objection，即使 monitor 里存在无限采样循环，或者 driver 里存在固定延时，这些代码也可能刚启动就被阶段结束所终止。
因此，判断一段 task 代码能否完整运行，不能只看它有没有放在正确的 component 里，还要看它所在的 phase 是否存在活跃 objection。UVM 不会替设计者猜测“这段循环应该跑多久”，只会遵守当前 phase 的活动计数。
二、run_phase 为什么需要单独理解
默认的 run-time phase 包括从 reset 到 shutdown 的一组动态阶段，run_phase 则与这些动态阶段并行运行。两者共享仿真时间，但结束条件并不完全相同。动态 phase 中的 objection 可以间接维持 run_phase 的生存时间，因为 run_phase 与它们并行；如果全部动态 phase 都没有 objection，run_phase 又自己不提 objection，其中的 task 代码同样可能没有机会真正展开。
比较稳妥的规则是，不要把 run_phase 当成默认自动延长的后台线程。只要 run_phase 中存在必须完成的长期任务，就应由责任组件明确管理它的 objection，或者确认动态 phase 的活动周期一定覆盖这些任务。否则，仿真可能在动态 phase 结束后立即推进，run_phase 中的采样、监控或收尾逻辑还没有完成。
反过来，如果 run_phase 只是辅助性日志或非关键观察，也不应该为了让它执行而盲目 raise 一个长期 objection。那样虽然代码会运行，却会把整个仿真的结束时间绑在 run_phase 上，掩盖动态 phase 中的完成条件。run_phase 和动态 phase 之间的 objection 关系，本质上是在处理两套并行生命周期，不能用一个“总是 raise”的经验规则粗暴解决。
三、raise 和 drop 必须成对，而且必须属于同一个责任对象
objection 不是布尔值，而是支持计数的对象。一次 raise_objection 可以附带名称和数量，drop_objection 必须按同一对象、同一责任关系撤销。代码中可以通过增加 objection 数量表达多个并行活动，也可以在调试信息里保留业务名称，但 raise 两次、drop 一次，或者 raise 一次、drop 两次，都会破坏计数平衡。
在实际环境中，最常见的计数错误不是故意写成多个，而是异常路径和分支路径没有对称处理。例如 fork 出多个进程，其中一个负责激励、另一个负责超时监控，结束条件出现后只撤销了激励进程的 objection，监控进程的 objection 仍然活跃；又或者 sequence 在中途 return、被 kill 或提前结束时，没有走到 drop 语句，导致 phase 永远等不到归零。
sequence 中还需要处理 starting_phase 为空的情况。由标准 test 启动的 sequence 通常能够通过 starting_phase 关联到当前阶段，但如果同一个 sequence 被手动调用、嵌套在其他对象中，或者脱离 phase 控制单独执行，starting_phase 可能为空。直接访问它而不做判断，会造成空对象错误。更稳妥的做法是只在 starting_phase 存在时 raise 和 drop，并把 sequence 的独立运行接口与标准 phase 运行接口明确分开。
四、责任不应该放在 driver 和 monitor 里
很多入门环境会把 raise_objection 写在 driver 中，因为 driver 看起来负责发激励，似乎也应该负责结束。但 driver 通常是一个无限循环，事务从 sequencer 不断取走，只有在复位、关闭或异常条件出现时才可能退出。如果在 while 循环之前 raise，在循环之后 drop，而循环本身没有退出路径，drop 永远执行不到；如果把 raise 放进循环内部，第一次 get_next_item 又可能在 objection 尚未提起时就被 phase 结束掉，形成另一个时序陷阱。
monitor、reference model 和长期覆盖率收集器也有类似问题。它们本质上都是被动观察者，生命周期通常由系统决定，而不是由自身决定。让这些组件控制 phase 结束，会让环境难以判断“观察多久才够”，也会把基础采样逻辑和测试完成条件耦合在一起。
objection 更适合放在测试场景的调度层。UVM 推荐由 sequence 通过 starting_phase 控制 objection：sequence 开始发送场景时提起，最后一笔激励及其必要等待完成后撤销。这样 objection 对应的是一个完整测试意图，而不是某个具体驱动循环。不同 sequence 负责不同场景时，每个场景可以独立管理自己的生命周期，test 负责组合和监控总体结果。
另一种常见做法是由 scoreboard 控制。scoreboard 知道预期事务数量时，可以先 raise objection，再分别收集期望结果和实际结果，收到约定数量后结束等待并 drop。无论采用哪种方式，objection 的所有者都应该是“最清楚工作何时全部完成”的对象。driver 和 monitor 知道如何工作，却通常不知道整场测试何时应该结束。
五、drop 之后还要给 DUT 留下响应时间
一笔输入事务发送完成后，DUT 可能还需要若干周期才能产生输出。如果 sequence 在最后一笔激励驱动的同一时刻立即 drop objection，phase 会很快结束，最终响应可能还没有到达 scoreboard，覆盖率也没有机会采样。此时波形里往往能看到输入全部发出，日志却缺少最后一个检查结果。
UVM 为这种情况提供了 drain_time。它不是一个新的激励阶段，而是在所有 objection 已经归零后，再给当前 phase 保留一段收尾时间。只有 drain_time 结束，UVM 才进入下一个 phase。它可以用来等待已知的固定处理延迟，也可以为最后一批事务的采样和队列排空提供余量。
但 drain_time 不能替代正确的完成判定。设置一个远大于设计延迟的固定值，看似能解决所有问题，实际上只是把问题隐藏起来。真实设计中的延迟可能随配置、反压和异常路径变化，过大的 drain_time 会拖慢每个测试，过小又无法覆盖慢路径。更可靠的方式是先用 scoreboard 或 monitor 掌握未完成事务数量，让 objection 一直保持到关键响应、检查项和覆盖采样都完成，再用合理的 drain_time 覆盖已知残余延迟。
drain_time 通常通过 phase_done 设置。phase_done 是 phase 内部管理完成状态的对象，raise_objection 和 drop_objection 最终都会作用到它的计数上。理解这一层关系之后，就能明白 drain_time 不是在延长激励发送时间，而是在最后一个活动结束后，为 phase 提供一个受控的收尾窗口。
六、用 UVM_OBJECTION_TRACE 定位提前结束和无法结束
objection 问题往往很难只靠日志猜出来，因为一个 phase 可能同时有多个对象在 raise 和 drop。UVM 提供命令行调试参数 UVM_OBJECTION_TRACE，可以打印 objection 的提起对象、撤销对象、计数和总数。它能够快速回答三类问题：是谁在什么时候提起，计数为什么没有归零，最后一个 objection 又是在哪个时间点被撤销。
如果仿真提前进入下一阶段，通常说明关键组件没有在正确 phase 提起 objection，或者错误地使用了 run_phase。如果仿真一直不结束，trace 中往往会表现为某个对象始终没有 drop，或者 raise 数量大于 drop 数量。对于复杂回归，还可以给不同业务活动设置 objection 名称，让日志能够区分激励、监控和收尾任务。
调试时不要只盯着最终总数，还要看对象路径。UVM 按照组件树逐级汇总 objection，一个 sequence 在 sequencer 下提起活动后，相关计数会沿父节点向上传播。理解这条路径，有助于区分是 sequence 自身没有释放，还是父节点上存在另外一项未完成活动。
七、常见工程陷阱
第一，把 objection 当成固定延时代替品。正确的做法是让它代表未完成工作，而不是用任意长的时间掩盖完成条件不清楚的问题。
第二，在 driver 或 monitor 的无限循环外部 raise，却在循环结束后 drop。循环不退出，objection 自然不会释放。
第三，把 raise 写在 get_next_item 之后，寄希望于 driver 自己启动。如果当前 phase 没有其他 objection，driver 可能连第一次取事务都执行不到。
第四，多个 fork 分支共享计数，但只维护一个 drop 路径。异常结束、超时结束和正常结束必须覆盖同一套释放逻辑。
第五，sequence 复用后没有处理 starting_phase 为空。同一个 sequence 既能在 test 中启动，也能被手动调用时，要明确哪些运行方式负责 objection。
第六，依赖过大的 drain_time 保证通过的测试。它可能让回归表面上稳定，却掩盖 scoreboard 尚未收齐、monitor 尚未采样或 DUT 响应超时的问题。
第七，动态 phase 和 run_phase 都随意 raise，导致责任边界模糊。应当先明确每个长期任务由谁负责，再决定哪个层次控制 phase 结束。
八、推荐落地的检查顺序
建立环境时，先确认每个 run-time phase 中的长期代码是否确实获得了执行窗口，再决定 objection 放在哪一层。激励完成条件应由 sequence 负责，结果收齐条件应由 scoreboard 负责，monitor 和 reference model 保持被动生命周期。只要存在必须等待的响应或采样，就不要让最后一个激励事务一发送完就无条件 drop。
随后检查 raise 和 drop 是否严格配对，尤其是 reset、timeout、sequence 异常退出和 fork 分支收敛路径。再把 drain_time 设置为能够覆盖已知残余延迟的合理值，并在回归中加入 objection 跟踪。最后，用超时和提前结束两类失败分别验证机制：没有 objection 时不能误以为仿真会等待，有 objection 未释放时也不能让回归无限挂起。
objection 真正管理的不是仿真时间，而是 phase 的责任边界。它让 UVM 知道哪些工作还没完成，也让测试环境有机会回答“什么时候可以进入下一阶段”。一个可靠的 objection 设计，应当能够清楚说明谁在等待、等待什么、什么时候释放，以及释放之后是否还需要为 DUT 响应保留收尾窗口。只有这套关系稳定，phase 才会在正确时刻结束，而不是过早跳过关键检查，也不是被一个失控计数无限拖住。
如果你也在梳理 UVM 验证环境中的 技术文档 和 调试排查 经验，不妨去 云栈社区 看看更多验证工程师的实战讨论。
发表于 2 小时前
|
查看: 7|
回复: 0
