散落的 objection，是团队协作的噩梦在 UVM 验证环境中，objection 是控制仿真何时结束的机制。任何一个组件都可以通过phase.raise_objection(this)来阻止仿真结束，直到它drop_objection(this)。听起来简单，但在多人协作的复杂项目中，如果 objection 散落在各个 driver、monitor、scoreboard、sequence 中，问题就来了：某个工程师在他的 driver 里 raise 了 objection，但忘记在某个错误路径下 drop，导致仿真一直挂住。另一个工程师在 monitor 中条件性 raise/drop，结果条件判断错误，提前 drop 了 objection，导致其他组件还在运行，仿真却提前结束。调试时，谁持有 objection、何时 drop，完全不清楚，只能靠猜测和打印。最终，整个团队的仿真稳定性变得极差，经常出现“莫名挂死”或“提前结束”的灵异现象。根本原因：objection 缺乏统一管理。objection 的最佳实践原则谁可以持有 objection？在标准 UVM 中，任何uvm_component或uvm_object都可以 raise/drop objection。但最佳实践建议：只有 sequence 层（尤其是顶层 virtual sequence）可以 raise/drop objection。原因如下：Driver、monitor 等组件是被动执行者，它们的工作是持续不断的（如 driver 永远在等待事务），如果它们持有 objection，很难判断何时该结束。Sequence 代表一个测试场景，它有明确的开始和结束。一个 sequence 执行完毕，意味着该场景结束，objection 应该随之 drop。将 objection 集中在 sequence 层，便于追踪和调试：你只需查看当前运行的 sequence 是否还在运行，就能知道 objection 状态。重点：driver 不应该 raise/drop objection，它只负责驱动事务；monitor 更不应涉及 objection。所有的 objection 管理应由 test 顶层或 virtual sequence 统一负责。集中管理的优势可预测性：仿真结束条件清晰——所有顶层 sequence 结束后，objection 全部 drop，仿真自然结束。易于调试：当仿真挂起时，你可以查看哪个 sequence 还没有结束，从而定位问题。