OOP Patterns for Testbenches

Overview

Knowing class syntax is not the same as knowing how to structure a testbench. Real verification environments rest on a handful of design patterns applied over and over: a disciplined transaction base class, a factory for test-time type substitution, singletons for global configuration, callbacks for extending components without editing them, and a parent-child component hierarchy with phased execution. Every one of these patterns exists in plain SystemVerilog — and every one of them is exactly what UVM later standardizes . Build them by hand once and UVM stops being magic; it becomes a library of patterns you already understand.

This module is also the highest-yield interview material in the course. "Implement a factory without UVM", "why is the constructor protected in a singleton", and "how do you inject errors without modifying the driver" are asked at nearly every senior verification interview, precisely because they test whether you understand the machinery beneath the methodology.

Sub-topics

1. The Transaction Base Class — copy/compare/convert2string/pack discipline.

2. The Factory Pattern from Scratch — creator registry, create-by-name, type override.

3. Singletons & Config Objects — protected constructor, static get(), config tradeoffs.

4. Callbacks & Hooks — pre/post hooks and a callback queue in the driver.

5. Building a Component Hierarchy by Hand — env/agent/driver tree with phased run.

OOP PATTERNS TOPIC MAP — and where each resurfaces in UVM

  txn base class            factory                   singleton/config
  copy/compare/print        registry["name"] → new    cfg = config::get()
        │                         │                         │
        ▼                         ▼                         ▼
  uvm_object methods        uvm_factory +             uvm_config_db /
  (do_copy/do_compare)      type_id::create()         uvm_root singletons

  callbacks                 component hierarchy
  drv.cbs.push_back(cb)     env → agent → drv/mon/sb
        │                   build → connect → run
        ▼                         │
  uvm_callback /                  ▼
  uvm_do_callbacks          uvm_component tree + phases

  One arrow direction: learn the plain-SV pattern here,
  recognize the UVM incarnation later — not the other way round.

Key takeaways

• Every UVM mechanism is a plain-SV pattern with a standard library wrapper — learn the pattern first.

• The five patterns compose: factory-created transactions flow through a callback-extended driver inside a phased hierarchy configured by a singleton.

• These patterns are the core of senior verification interviews — be able to write each from a blank file.