uvm中run_phase和run-time的区别

核心区别概览

所属与并行关系：run_phase 与 12 个 run-time task phase（如 reset_phase、configure_phase、main_phase、shutdown_phase 等）是并行执行的；其中 run_phase 属于 common_domain，其余 12 个 phase 属于 uvm_domain。同一组件内这 12 个 run-time phase 按顺序依次执行，但跨组件的同名 phase 会进行同步，整体平台不会在这些 task phase 之间留空档。run_phase 从仿真开始即随 12 个分支并行推进。
Objection 控制：在 12 个 run-time phase 中，若要执行耗时操作，至少需要在一个组件里对该 phase 显式 raise_objection 并在结束时 drop_objection；否则该 phase 会立即结束。run_phase 不需要显式 objection 也会随 run-time phase 的运行而执行，但其结束仍受平台级 objection 状态影响（见下文“协同关系”）。
使用风格与推荐：run-time phase 提供了更细粒度的阶段划分（复位/配置/主业务/收尾），便于多组件协同与阶段化控制；run_phase 适合“持续运行”的监控/采集类组件。实际工程中建议优先使用 reset/main/configure/shutdown 等 run-time phase，避免与 run_phase 混用导致控制逻辑复杂。

执行与同步机制

跨组件同名 phase 同步：所有组件的 main_phase 会彼此对齐，全部完成后才进入 post_main_phase；依此类推，保证平台级阶段推进的连续性与一致性。
run_phase 与 post_shutdown_phase 的同步：同一组件内，run_phase 与其 post_shutdown_phase 都完成后才会进入 extract_phase。这体现了 UVM 在同一组件内对 task phase 的“阶段屏障”约束。
run_phase 的启动与推进：run_phase 在 0 ns 启动，与 12 个 run-time phase 并行推进；task phase 的启动是“自下而上”地 fork 起来并行运行，但同一组件内的 12 个 run-time phase 仍是顺序执行。

如何选择与常见用法

适合用 run_phase 的场景

Monitor、Coverage Collector 等需要“全程在线”的组件，用 run_phase 持续采样/统计，无需阶段切分。

适合用 run-time phase（如 main_phase） 的场景

Driver/Sequencer 等需要明确阶段边界的组件：在 reset_phase 做复位时序，configure_phase 下发配置，main_phase 发送主业务流量，shutdown_phase 做清理。

sequence 与 phase 的绑定

sequence 可以在指定 phase 启动（如 starting_phase 在 main_phase 中），便于在对应阶段集中驱动/检查。

避免混用的实践

同一组件内尽量只采用一种风格（run_phase 或 run-time phase）。若确需混用，需自行加同步（例如事件/旗标）避免阶段竞争与死锁。

协同关系与常见误区

“谁起 objection 谁说了算”的误区：在 12 个 run-time phase 中，只要有任一组件对该 phase 提起 objection，仿真就会在该阶段保持运行；此时 run_phase 会随之一起运行，但其自身并不“单独”维持仿真。只有当所有 run-time phase 的 objection 都放下，平台才会推进到后续 phase。
run_phase 不放 objection 也会运行：因为与 12 个 run-time phase 并行，run_phase 的代码会随着 run-time phase 的运行而执行；但若没有任何 run-time phase 提起 objection，平台会很快结束，run_phase 中的耗时代码可能没有机会执行。
不要在 run-time phase 里等 run_phase：同一组件内 run-time phase 是顺序执行，不能指望在 main_phase 里“等 run_phase 做完再继续”；若确有跨阶段协作需求，使用事件、mailbox、或 UVM 的 phase_ready_to_end()/set_drain_time() 等机制进行同步与收尾。