UVM Basics

UVM components, TLM communication, sequences, and the factory mechanism.

1. 01Introduction to UVM: what problem does it actually solve?Understand from scratch why UVM exists, how a testbench is layered, and the basics of uvm_component.
2. 02The UVM Component Tree and Phasinguvm_component as a standardized class hierarchy on top of class/extends, the fixed order UVM runs build_phase/connect_phase/run_phase in, the objection mechanism that controls when a test ends, and UVM's reporting macros.
3. 03Build and Run Your First UVM TestReuse the SV Basics capstone's mux2 DUT, wrap it in a minimal UVM skeleton, and actually run it — a near-empty driver, a test, and the config_db handoff that gets a virtual interface from the module domain into the UVM domain.
4. 04uvm_object and TransactionsThe real relationship between uvm_object and uvm_component (not just their differences), the uvm_sequence_item base every transaction actually extends, and writing do_copy/do_compare/convert2string by hand instead of field macros.
5. 05config_db and Virtual Interface HandoffWhy uvm_component's fixed factory constructor signature rules out passing a virtual interface as a constructor argument, and the full mechanics of uvm_config_db::set()/get() that solve it -- context, instance path, wildcards, and why chapter 2's build-phase ordering is what makes it work.
6. 06The Factory: Registration, create(), and OverridesWhat `uvm_component_utils`/`uvm_object_utils` actually register, why type_id::create() looks up a type instead of just constructing one, and how set_type_override() swaps an implementation without touching structural code -- closing chapter 3's oldest forward reference.
7. 07Sequences and Sequencersuvm_sequence's body() task and the start_item/finish_item handshake with a sequencer, randomizing transactions the SV ch12 way, and turning the driver into the uvm_driver#(REQ)/seq_item_port shape chapter 1's very first example already used.
8. 08Driver and Monitor: TLM Ports in PracticeThe monitor's push-style analysis_port versus the sequencer's pull-style seq_item_port, why that replaces SV ch14's hand-rolled mailbox, giving mux_transaction an observed-output field, and packaging sequencer/driver/monitor into a configurable uvm_agent.
9. 09Scoreboard and Analysis PortsThe receiving side of an analysis_port -- uvm_analysis_imp and write() -- as a second, software-based checking strategy alongside SV ch15's assertions, plus packaging an agent and scoreboard into a uvm_env.
10. 10Capstone: Assembling a Complete UVM EnvironmentA second test proving chapter 1's fourth promise -- testing a new scenario needs one new class and one factory override, not a rewrite -- switching tests from the command line with +UVM_TESTNAME, organizing the whole environment into a package, and what's next for the uvm-advanced and dv-methodology tracks.