Singleton and config_db Patterns without Global Chaos

Overview

Use singleton only for true one-per-simulation identity, then propagate that handle through `uvm_config_db` so dependencies stay explicit, testable, and scope-controlled.

Singleton solves identity and lifecycle: one object instance shared across the simulation, often for run-level configuration or service state. It should not become a backdoor for uncontrolled reads/writes from arbitrary components.\n\nUVM's `uvm_config_db` is hierarchical dependency injection. A test can set objects by path, and each component retrieves what it needs in build phase. This gives observability and scoped overrides without touching global mutable state.\n\nA robust pattern is: singleton creates canonical object once, test mutates and sets it into config_db, components fetch via config_db, and direct singleton calls are minimized outside ownership layers.

In this topic

1. Concept Explained
2. Code Examples
3. SystemVerilog vs C++/Java
4. Pitfalls
5. Exercises
6. Interview Questions

Read the concept first, study the code examples, compare against C++/Java, then test yourself with the exercises and interview questions.

Factory override flow in verification

FACTORY OVERRIDE FLOW

test config
   |
   +--> factory.set_type_override(base_driver, error_inject_driver)
                                   |
                                   v
                         create("drv", parent, base_driver)
                                   |
                                   v
                      +-------------------------------+
                      | instantiated: error_inject... |
                      +-------------------------------+
                                   |
                                   v
                          virtual methods dispatch

Factory decouples call site from concrete class selection.

Related topics

• OOP Patterns & UVM Application section

• SystemVerilog OOP Mastery hub