28 UVM Interview Questions and Answers for Freshers

• Standard methodology so testbenches are reusable across projects and teams
• Gives base classes, phasing, factory, config DB, TLM, reporting, sequences and RAL
• Supports constrained random and coverage driven verification

• uvm_component: quasi-static, created once in build phase, part of hierarchy, has phases, constructor new(name, parent)
• uvm_object: dynamic data like transactions/sequences/configs, no phases, constructor new(name)

• Uvm_sequence_item extends uvm_transaction and adds the IDs and hooks needed to work with sequences and sequencers
• Always extend uvm_sequence_item for stimulus

• Build, connect, end_of_elaboration, start_of_simulation (functions, zero time)
• Run_phase (task) with parallel run-time sub-phases reset/configure/main/shutdown (and pre/post), all tasks
• Extract, check, report, final (functions)

Interviewer may ask next: Why is build_phase top-down and connect_phase bottom-up?

• A parent must exist and build its children
• Parent may set config or factory overrides that children read in their build
• Other function phases run bottom-up

• Factory creates objects via type_id::create() instead of new(), so a test can replace a class with a derived one (type or instance override) without editing the environment
• Registration with `uvm_component_utils / `uvm_object_utils is required for this

Interviewer may ask next: Write a type override from a test.

• Factory: replace the whole class with an extended one
• callback: add small pieces of behaviour at pre-defined hook points without replacing the class, and multiple callbacks can be stacked

• set(context, inst_path, field_name, value) stores the value with a scope
• get(context, inst_path, field_name, var) retrieves it and returns 1 if found
• Typical use: virtual interface from top to driver/monitor
• Higher-level set wins during build
• Can be set many times, the last matching set at the same level wins

Interviewer may ask next: How do you share one variable between a test and a sequence?

• Sequence: start_item(req), randomize, finish_item(req)
• Sequencer arbitrates and passes it on
• driver: seq_item_port.get_next_item(req), drive pins, item_done()
• Response can be sent back with put_response/rsp

• Get_next_item blocks until an item is available and must be followed by item_done()
• get() fetches the item and calls item_done internally, so the sequence is released immediately

• M_sequencer is the generic uvm_sequencer_base handle set automatically when the sequence starts
• P_sequencer is a typed handle declared with `uvm_declare_p_sequencer, used to reach fields of a specific (virtual) sequencer

• Virtual sequence coordinates sequences on multiple agents' sequencers (e.g. configure over APB, then send data over AXI)
• It does not generate items itself
• Virtual sequencer holds handles to the real sequencers
• Virtual sequencer is optional, handles can be passed directly

• Both give a sequence exclusive access to a sequencer
• Lock waits in the arbitration queue for its turn, grab jumps to the front of the queue
• Release with unlock()/ungrab()

• `uvm_do macro does create + start_item + randomize + finish_item in one line
• Explicit start_item/finish_item gives control to set fields, use inline constraints and check randomize() result
• Macros are discouraged in many teams

• Objections tell the phase it is not done: raise_objection at start, drop_objection at end
• Run phase ends when all are dropped
• If never dropped, simulation hangs until the global timeout (set_timeout) fires a fatal
• fix: drop in all paths, use drain time

• Analysis port is a one-to-many broadcast with a non-blocking write()
• Monitor writes transactions
• Scoreboard and coverage subscriber implement write() via analysis_imp or analysis FIFO
• Connected in connect_phase: mon.ap.connect(scb.exp)

• TLM is standard and component-to-component with clear port/export/imp roles
• Connections are made in connect_phase without sharing handles
• Supports broadcast (analysis) and different blocking styles
• Better reuse and SystemC interoperability

• Active agent has sequencer, driver and monitor and drives the DUT
• Passive agent has only a monitor and just observes (e.g. at system level)
• Set by is_active (UVM_ACTIVE/UVM_PASSIVE)

• Reference model goes in the scoreboard (or a separate predictor component), never in the driver
• In-order: expected and actual compared in arrival order (FIFO)
• Out-of-order: match by ID/address using associative arrays, for protocols like AXI with reordering

• Uvm_subscriber has one built-in analysis_export and a write() to implement, typically used for coverage collection
• Uvm_scoreboard has no built-in export, you add as many as needed for checking

• Severity: UVM_INFO, UVM_WARNING, UVM_ERROR, UVM_FATAL (fatal ends sim)
• Verbosity applies to INFO messages: UVM_NONE, LOW, MEDIUM, HIGH, FULL, DEBUG
• Set with +UVM_VERBOSITY

• Call run_test() in the top initial block and pass +UVM_TESTNAME=my_test at runtime, so no recompile is needed
• run_test("my_test") hardcodes it

• Clock and reset generation, interface instance, DUT instance connected to the interface, uvm_config_db set of the virtual interface, run_test() call, optional dump commands and bind statements for assertions

• Register Abstraction Layer models DUT registers and lets tests use reg.write/read/mirror
• Front-door goes through the bus protocol (takes time, real path)
• Back-door accesses the register directly by HDL path in zero time (fast setup/checking but skips the bus logic)

• Copy needs an existing destination object and copies fields into it
• Clone creates a new object and copies into it, returns uvm_object so you must $cast to the right type

• Early: item randomized before start_item, before the driver is ready
• late: randomized after start_item returns (driver has requested an item), so constraints can use current DUT/environment state
• Late is recommended

• Read spec, write verification plan (features, checks, coverage)
• Build testbench architecture
• Directed sanity tests
• Constrained random tests and regressions
• Assertions
• Code and functional coverage closure
• Bug tracking
• Reviews
• Sign-off when coverage goals met, no open critical bugs, regressions clean

• uvm_event: synchronization between components with optional data
• uvm_barrier: makes several processes wait until all reach a point
• uvm_pool: global associative-array style storage shared by components
• heartbeat: detects a hang if components stop showing activity