Singleton and config_db Patterns without Global Chaos: Concept Explained

Concept

In short: 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.

Related topics

• Back to Singleton and config_db Patterns without Global Chaos