Introduction to UVM
By the time a testbench needs to check a real block — not a toy example — it usually needs a driver, a monitor, randomized stimulus, a scoreboard…
Getting Started with UVM
The single most common misconception for someone new to UVM: expecting to "install" it like a standalone tool. There's no UVM application, no package…
Base Classes & the Class Hierarchy
hello_env and hello_test from the previous page both extended UVM base classes without much explanation of where those classes actually come from. Nearly…
Object Utility Methods
Every uvm_object — every transaction, every config object — comes with four capabilities built into the base class: printing itself for a log, copying its…
Utility & Field Macros
Every class in this section so far has opened with a line like uvm_object_utils(bus_txn) or uvm_component_utils(bus_driver), with a promise to explain it…
Interface & Transaction
Section A covered UVM's mechanics in the abstract — class hierarchy, printing, the factory — without ever touching a real DUT. This section builds a…
UVM: The Driver
The fifo_txn class from the previous page is just data — nothing about it knows how to make wr_en or rd_en actually toggle on the DUT's pins. That…
The Monitor & Subscriber
The driver only knows what it was told to drive. Whether the DUT actually responded correctly is a separate question entirely — answering it starts with a…
The Sequencer & Sequence
The driver's get_next_item()/item_done() loop from two pages ago was written without ever explaining where a transaction actually comes from. That's this…
UVM: The Scoreboard
The monitor from earlier in this section broadcasts every transaction it observes — but broadcasting isn't checking. Something has to actually decide…
The Agent & Environment
Every component built so far in this section — driver, monitor, sequencer, scoreboard — exists as a standalone class, with nothing yet actually assembling…
The Test & Testbench-Top
The environment from the previous page is a complete, self-contained, reusable unit — but it has no opinion about when to run or what stimulus to run…
Phases & Objections
The FIFO testbench built up over the previous section — driver, monitor, sequencer, scoreboard, agent, environment, test — relied on build_phase…
User-Defined Phases
The nine phases from the previous page, plus the twelve run-time sub-phases underneath run_phase, cover the overwhelming majority of what any UVM…
The UVM Factory
Every create() call throughout the FIFO testbench — fifo_driver::type_id::create("driver", this), fifo_monitor::type_id::create("monitor", this), and…
Resource DB & Config DB
Testbench-top, back in The Test & Testbench-Top, had one loose thread: it created a virtual interface in a plain-Verilog module, but the driver and…
TLM Basics & Analysis Ports
The monitor and scoreboard from The Monitor & Subscriber and The Scoreboard already used TLM without this section pausing to name the mechanism…
Blocking Put & Get Ports
Analysis ports, from the previous page, are one-to-many broadcasts with no concept of the receiver's readiness — ap.write(txn) fires and moves on, whether…
Non-Blocking Put & Get Ports
log_port.put(txn) from the previous page genuinely stalls the monitor's run_phase for however long fifo_write_logger::put() takes to return. That's fine…
The TLM FIFO
The previous two pages solved rate-mismatch two different ways: block and wait (simple, but stalls the caller), or poll with try_put()/can_put() (never…
TLM Sockets & Multiple Imps
Two loose ends remain in the TLM picture built up across this section: a more compact alternative to declaring a port and export separately, and what to…
Sequence Execution & Macros
The Sequencer & Sequence covered the mechanics every sequence in this section has used since: start_item()/finish_item(), the get_next_item()/item_done()…
Virtual Sequences & Sequencers
Every sequence throughout this section has targeted exactly one sequencer, driving exactly one interface. Real environments often outgrow that — imagine…
Sequence Libraries & Arbitration
Real regressions rarely run just one sequence class over and over — a healthy testbench accumulates a whole family of them (fifo_write_read_seq from…
Reporting & Messaging
Every code example so far has used uvm_info or uvm_fatal instead of $display. That's not a style preference — UVM's reporting macros solve real problems…
Printer & Comparer Policies
Object Utility Methods covered print() and compare() as capabilities every uvm_object gets, with do_print(uvm_printer printer) and do_compare(uvm_object…
Callbacks, Events & Pools
The UVM Factory covered one way to customize behavior without editing existing code: override which class gets built. Callbacks offer a different kind of…
Example Walkthrough: Minimal FIFO Testbench
Sections B through F built this exact testbench piece by piece — interface and transaction, driver, monitor, sequencer and sequence, scoreboard, agent and…
The Register Abstraction Layer
The FIFO testbench built across the previous sections had no registers to model at all — every bit of its behavior was controlled directly through…
RAL Testbench Integration
The Register Abstraction Layer built pwm_reg_block as a standalone object model — accurate, but with nowhere for reg.write() to actually send an access…
RAL Backdoor Access
Every register access described so far — frontdoor, through reg.write()/read(), the adapter, and a real sequencer — travels the same path an actual bus…
RAL Worked Example: A PWM Register Block
The previous three pages built this piece by piece — the register model, the adapter and predictor wiring, and backdoor HDL paths. This page shows all of…
HDL Backdoor Access Routines
RAL Backdoor Access covered peek()/poke() — RAL's backdoor equivalents of read()/write(), resolved through an HDL path configured on a register…
The Singleton Pattern
The word "singleton" has already come up three times in this curriculum without ever being explained on its own terms: Base Classes called uvm_root "a…
Reusable Verification Components
fifo_agent and the PWM's reg_bus_agent were both written for one specific testbench in this curriculum, and both happened to work — but "works in the one…
Using Verification Components
Reusable Verification Components covered what makes a VC safe to drop into any environment. This page covers the other half: how a larger environment…
UVM Interview Questions
This is the last page of the UVM curriculum, and a different kind of page than everything before it: not new material, but a set of original questions…