Every component, every connection, every transaction — animated live. Click any box to explore its role, code, and wiring.
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.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.The Universal Verification Methodology (UVM) is the industry-standard framework for building reusable, scalable testbenches in SystemVerilog. Rather than every team inventing its own structure, UVM provides a proven architecture of standard components and a base-class library, so verification environments look familiar and components can be shared between projects.
A UVM testbench is organised as a hierarchy of objects, each with a clear responsibility. Transactions (sequence items) flow from sequences, through a driver onto the interface, while a monitor observes activity and feeds checkers and coverage. This separation of stimulus generation, driving, monitoring and checking is what makes UVM environments maintainable as a design grows.
UVM also brings the factory, configuration database and phasing that let you override components and pass settings cleanly through the hierarchy. Mastering this architecture is essential for any verification role, and it builds directly on the SystemVerilog OOP and constrained-random features covered elsewhere in this section.