SystemVerilog OOP Mastery · All levels
Factory Pattern: Polymorphism with Type and Instance Overrides
UVM factory operationalizes polymorphism: you code against base types, then tests swap concrete behavior with type and instance overrides without touching reusable environment code.
Overview
UVM factory operationalizes polymorphism: you code against base types, then tests swap concrete behavior with type and instance overrides without touching reusable environment code.
In GoF terms, UVM factory combines Abstract Factory and Strategy. Component and object creation always happens through a stable base contract, while override policy is selected by the test layer. That separation is what keeps VIP reusable across projects with different stress goals.\n\nType override is broad and should be used when every creation site of a base type needs the same derived behavior. Instance override is surgical and should be used when only one hierarchy path needs alternate behavior. This mirrors dependency injection scopes in software systems.\n\nMost regressions around factory come from timing and naming: overrides must be in place before create calls execute, and paths must match the real hierarchy. A quick factory print in build/connect phase is often the fastest way to verify intent.
In this topic
1. Concept Explained
2. Code Examples
3. SystemVerilog vs C++/Java
4. Pitfalls
5. Exercises
6. Interview QuestionsRead 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.