Great question—this is a common point of confusion when deep diving into UVM, and your observation of the consistent bottom-up connect_phase() execution is exactly how the framework is designed to work. Let’s break this down step by step.

UVM Phase Mechanism: High-Level Overview #

UVM organizes the entire simulation lifecycle into a structured sequence of phases, managed by the UVM core phase controller. Each phase has a clear, single responsibility, ensuring that verification environments are built, configured, run, and cleaned up in a predictable, consistent order. Key phase categories include:

• Build Phases: Focused on creating component instances and applying configurations. This uses a top-down execution order.
• Common Phases: Cover post-build setup, simulation execution, and post-simulation analysis. Most of these (including connect_phase()) use a bottom-up execution order.
• Run-Time Phases: Sub-phases within the run_phase() (like reset_phase, main_phase) that handle time-sensitive simulation logic, executed in sequence but parallel to the run_phase() itself.

The phase controller automatically traverses the UVM component hierarchy to trigger each phase’s method for every component—you never need to manually call these methods. The order of execution is strictly enforced to avoid race conditions or dependency errors.

Why connect_phase() (and Most Post-Build Phases) Use Bottom-Up Execution #

To understand this, let’s contrast it with the top-down build_phase() first:

• build_phase() runs top-down because parent components must create their child instances before the children can do anything. For example, an environment (env) must first create its agent instances, which then create their drivers/monitors/sequencers. If we ran build bottom-up, parent components would try to reference child instances that don’t exist yet.

For connect_phase() and other post-build phases, the reverse (bottom-up) makes perfect sense, and here’s why:

1. Child components need to complete internal connections first
   A child component (like a driver or monitor) might have its own internal connections or setup logic in connect_phase(). For example, a driver might initialize its seq_item_port or bind to a DUT interface. Running the child’s connect_phase() first ensures these internal elements are ready before the parent tries to use them.
   Your simulation log confirms this: the lowest-level components (gc1, gc2) run their connect phase first, then their parent components (c1, c2), then the top-level e2 environment.

2. Parent components depend on child component state
   Parent components often need to connect child components to each other (e.g., connecting an agent’s monitor to a scoreboard’s analysis port). If the parent ran connect_phase() first, it would be trying to reference ports or interfaces that the child hasn’t fully initialized yet. Bottom-up execution guarantees that all child components have finished their setup, so parent components can safely make cross-component connections.

3. Consistency across post-build phases
   Phases like end_of_elaboration_phase() and start_of_simulation_phase() also use bottom-up execution for similar reasons. For example, end_of_elaboration lets components adjust their hierarchy or configurations—children might modify their settings first, then parents can adapt based on those changes. This ensures dependencies are respected throughout the post-build workflow.

Key Takeaway #

UVM’s phase order is intentionally designed to match component dependency relationships:

• Top-down build: Parents create children first, ensuring all instances exist.
• Bottom-up post-build: Children prepare themselves first, so parents can safely build on their setup without missing dependencies.

This design eliminates race conditions, reduces bugs from uninitialized components, and makes verification environments more predictable and maintainable.

内容的提问来源于stack exchange，提问作者Monica