From Hand-Built TB to UVM · SystemVerilog

Part 6 of 9Testbench ArchitectureIntermediate

3topics
3lessons

A hand-built class testbench already contains most of UVM under different names. UVM standardizes these patterns and adds automation for phasing, the factory, configuration, reporting, and TLM plumbing.

Diagram

THE BRIDGE AT A GLANCE

  HAND-BUILT TB                        UVM
  ─────────────                        ───
  test (plusarg select)    ────►  uvm_test (+UVM_TESTNAME + factory)
  env class                ────►  uvm_env
  generator                ────►  uvm_sequence (+ sequencer)
  mailbox handoff          ────►  sequencer/driver handshake
  driver                   ────►  uvm_driver
  monitor + mailbox fanout ────►  uvm_monitor + analysis ports
  scoreboard               ────►  uvm_scoreboard
  done-counter / events    ────►  uvm_objection
  $display + verbosity     ────►  uvm_report / `uvm_info

  same architecture — standardized names + automation

Lesson	What it covers	Path
Concept Mapping: TB to UVM	Each hand-built piece next to its UVM twin, plus the two mappings that change shape.	Required
What UVM Automates (and What It Costs)	The five automations side by side with hand-built code, and the price tag.	Recommended
Migrating a TB to UVM	A staged ladder that keeps tests green, with plain models kept working inside UVM.	Optional

Path tells you how to spend your time. Required is the core first pass for building a layered testbench. Recommended is what most learners should read. Optional is reference, specialist or revision material that you can return to later.

What you already built, and what UVM automates

Each row is a piece you wrote by hand in this section. The last column is the chore UVM takes over; the idea itself stays the same.

You built	UVM calls it	What UVM automates
A test class chosen by a plusarg	`uvm_test`	The factory creates the test from +UVM_TESTNAME, so no selection ladder is edited per test.
An env that builds and wires its parts in a constructor	`uvm_env` with build and connect phases	Phases run in a fixed order across the whole tree, so wiring no longer depends on construction order.
A generator that puts items into a mailbox	`uvm_sequence` plus a sequencer	Arbitration between several sequences, and a per-item handshake back to the sequence.
A driver that gets from a mailbox and drives pins	`uvm_driver`	The get-next-item and item-done handshake replaces the hand-made mailbox protocol.
A monitor that puts copies into one mailbox per consumer	`uvm_monitor` with an analysis port	One write reaches every subscriber, and a new one attaches without editing the monitor.
A scoreboard fed by two mailboxes	`uvm_scoreboard` with analysis imports	The same compare, with the plumbing that feeds it provided by TLM.
A done counter and a drain delay	Objections	Components raise and drop objections, and the phase ends when none remain.
$display with a verbosity knob	`uvm_report` and `uvm_info`	Severity, id and verbosity filtering, plus error counts for the final report.
A virtual interface passed through constructors	`uvm_config_db`	Set it once at the top, and any component gets it by hierarchy path.

In PacketFIFO terms: pf_pkt becomes a sequence item, pf_driver a driver, the two pf_monitor copies one monitor with an analysis port, and pf_scoreboard a scoreboard. The compare, the accepted-byte rule and the drain logic carry over unchanged. See PacketFIFO Step: A Monitor and Scoreboard for the hand-built version.

Check yourself A hand-built testbench has a generator, a driver, mailboxes, and a done counter. Which UVM pieces replace each, and what new capability arrives with the handshake?

The generator becomes a sequence plus a sequencer, mailboxes become the sequencer/driver handshake and analysis ports, and the done counter becomes objections. The new capability is per-item completion feedback, which makes reactive stimulus natural.

Related topics

Up nextConcept Mapping: TB to UVM

Practice this lesson Previous lesson Report an error

THE BRIDGE AT A GLANCE HAND-BUILT TB UVM ───────────── ─── test (plusarg select) ────► uvm_test (+UVM_TESTNAME + factory) env class ────► uvm_env generator ────► uvm_sequence (+ sequencer) mailbox handoff ────► sequencer/driver handshake driver ────► uvm_driver monitor + mailbox fanout ────► uvm_monitor + analysis ports scoreboard ────► uvm_scoreboard done-counter / events ────► uvm_objection $display + verbosity ────► uvm_report / `uvm_info same architecture — standardized names + automation

Lesson

What it covers

Path

Concept Mapping: TB to UVM

Each hand-built piece next to its UVM twin, plus the two mappings that change shape.

Required

What UVM Automates (and What It Costs)

The five automations side by side with hand-built code, and the price tag.

Recommended

Migrating a TB to UVM

A staged ladder that keeps tests green, with plain models kept working inside UVM.

Optional

What you already built, and what UVM automates

Each row is a piece you wrote by hand in this section. The last column is the chore UVM takes over; the idea itself stays the same.

You built	UVM calls it	What UVM automates
A test class chosen by a plusarg	`uvm_test`	The factory creates the test from +UVM_TESTNAME, so no selection ladder is edited per test.
An env that builds and wires its parts in a constructor	`uvm_env` with build and connect phases	Phases run in a fixed order across the whole tree, so wiring no longer depends on construction order.
A generator that puts items into a mailbox	`uvm_sequence` plus a sequencer	Arbitration between several sequences, and a per-item handshake back to the sequence.
A driver that gets from a mailbox and drives pins	`uvm_driver`	The get-next-item and item-done handshake replaces the hand-made mailbox protocol.
A monitor that puts copies into one mailbox per consumer	`uvm_monitor` with an analysis port	One write reaches every subscriber, and a new one attaches without editing the monitor.
A scoreboard fed by two mailboxes	`uvm_scoreboard` with analysis imports	The same compare, with the plumbing that feeds it provided by TLM.
A done counter and a drain delay	Objections	Components raise and drop objections, and the phase ends when none remain.
$display with a verbosity knob	`uvm_report` and `uvm_info`	Severity, id and verbosity filtering, plus error counts for the final report.
A virtual interface passed through constructors	`uvm_config_db`	Set it once at the top, and any component gets it by hierarchy path.

Check yourself A hand-built testbench has a generator, a driver, mailboxes, and a done counter. Which UVM pieces replace each, and what new capability arrives with the handshake?