UVM Architecture
See the Data Flow

A UVM testbench has: uvm_test (top-level controller), uvm_env (container for agents and checkers), uvm_agent (contains sequencer + driver + monitor), uvm_sequencer (routes transactions to the driver), uvm_driver (drives DUT signals), uvm_monitor (passively observes the DUT), uvm_scoreboard (checks correctness), and coverage collectors. All communicate through TLM ports and analysis ports.

A sequence generates items and starts them on the sequencer via seq.start(sequencer). The sequencer routes each item to the driver's seq_item_port.get_next_item(). The driver drives DUT signals through a virtual interface, then calls item_done(). The monitor independently observes DUT signals and reconstructs transactions, then broadcasts them via analysis_port.write() to the scoreboard and coverage collector simultaneously.

build_phase → create child components (bottom-up). connect_phase → wire TLM ports. run_phase → main simulation (time-consuming, parallel across all components). check_phase → report errors. report_phase → print final coverage and stats. The run_phase uses time-consuming tasks; all other phases use functions.

uvm_config_db is a global hierarchical database for passing configuration between UVM components. The testbench top module calls set() to store a virtual interface (or integer, string, object), and each driver or monitor calls get() in build_phase to retrieve it. The path argument ("uvm_test_top.*") determines which components can see the value.