UVM Interview Questions and Answers

Reuse and standardisation. UVM provides a common component architecture (agents, drivers, monitors, scoreboards), a factory for type substitution without editing code, a config database for passing settings/interfaces down the hierarchy, phasing for synchronised build/connect/run, and TLM for decoupled communication — so verification IP and environments are portable across projects and teams.

They run in order: build_phase (top-down) constructs components; connect_phase (bottom-up) wires TLM ports; end_of_elaboration/start_of_simulation finalise; the time-consuming run_phase (and the 12 run sub-phases reset→main→shutdown) drive stimulus; then extract/check/report/final collect results. Build is top-down so parents create children before configuring them; connect is bottom-up so children’s ports exist before being wired.

A registry that creates objects by type lookup (type_id::create()) rather than direct new(). Because creation is indirected, you can override a type globally or by instance path (set_type_override/set_inst_override) — swapping in an error-injecting driver or an extended transaction — without touching the environment code. This is what makes tests reconfigure the environment.

A hierarchical database to pass configuration down the component tree without wiring it through every constructor — most importantly the virtual interface from the top module to the driver/monitor, plus config objects and knobs. set() stores by scope/field name; get() retrieves in build_phase. It decouples what configures from what is configured.

A sequence runs on a sequencer and calls start_item/finish_item (or `uvm_do) for each transaction. The driver calls seq_item_port.get_next_item(req), drives it on the pins, then calls item_done(). This TLM handshake decouples stimulus generation (sequence) from pin-level protocol (driver) and provides back-pressure.

Sequence items and transactions are data objects (uvm_object) — created and destroyed dynamically, flowing through the testbench. Components (uvm_component) are the static structural hierarchy (agents, drivers, monitors) built once in build_phase and persisting for the whole simulation. Items are the water; components are the pipes.

Objections track outstanding work. A component/sequence raises an objection (raise_objection) when it starts meaningful activity and drops it (drop_objection) when done. The run phase ends when all objections are dropped — this is how UVM knows the test is finished rather than ending at a fixed time. A forgotten drop hangs the test; a missing raise ends it prematurely.

Transaction-Level Modelling: components communicate by passing transaction objects through typed ports instead of wiggling signals, which decouples them. A uvm_analysis_port broadcasts a transaction to any number of subscribers (monitor → scoreboard + coverage) with no return, which is why monitors use it. Put/get ports model point-to-point producer/consumer with blocking.

A model of the DUT’s registers and fields (uvm_reg/uvm_reg_block) that lets tests read/write registers by name through an adapter and predictor, independent of the bus protocol. It provides front-door (through the bus) and back-door (direct hdl) access, mirrors expected values, and enables automatic register tests.

`uvm_info(ID, MSG, VERBOSITY) prints only if the component’s verbosity threshold is at or above the message’s level (UVM_LOW/MEDIUM/HIGH/DEBUG). This lets you compile once and dial detail up or down per component/phase at runtime via +UVM_VERBOSITY or set_report_verbosity_level, keeping regressions quiet but debug runs detailed.