Introduction
Introduction Get started Hello UVM example UVM Phases Part 1 UVM Phases Part 2 UVM Base Classes UVM Object and Core Methods UVM Components
Building a Testbench
UVM Transaction UVM Sequence UVM Sequencer UVM Driver UVM Monitor UVM Scoreboard UVM Agent UVM Environment UVM Test
Other Components
Coverage Collector
Execution Model
UVM Phases Objections
Communication
TLM Basics TLM Blocking Put Port TLM Non-Blocking Put Port TLM Blocking Peek Port Analysis Ports TLM FIFO
Configuration
UVM Factory UVM Config DB
Runtime Control
UVM Plusargs Seeds & Reproducibility Verbosity Control Debug Runtime Controls
Advanced
Virtual Sequences Virtual Sequencer
UVM RAL
Intro Abstraction Flexibility Comparison Coverage Minimum Requirements Learning Path Register Types First Implementation Register with 2 Fields Register with Reserved Bits Access Policies Part 1 Access Policies Part 2 Access Policies Part 3 Access Policies Part 4 Memory Modeling Register Block Adapter Introduction Adapter Methods Adapter Example Predictor Types Desired and Mirror Values Register Methods Desired Value Mirror Value

UVM Factory

The UVM Factory enables flexible component and object creation using type overrides and instance overrides.

📘 What is the UVM Factory?

The UVM Factory is a mechanism that allows objects and components to be created dynamically and replaced without modifying original source code.

  • Supports reuse
  • Enables test-level customization
  • Allows polymorphism
  • Essential for scalable verification
🚀 Why the Factory is Powerful
  • Override drivers in specific tests
  • Replace sequences dynamically
  • Modify behavior without editing environment code
  • Support regression-level flexibility

It enables separation between structure and behavior.

🏗 Factory Registration 

class my_driver extends uvm_driver #(packet);
  `uvm_component_utils(my_driver)
endclass

The macro `uvm_component_utils registers the class with the factory.

💻 Factory-Based Creation 

driver = my_driver::type_id::create("driver", this);

Instead of using new(), we use type_id::create() to allow factory overrides.

🔄 Type Override Example 

class extended_driver extends my_driver;
  `uvm_component_utils(extended_driver)
endclass

initial begin
  my_driver::type_id::set_type_override(extended_driver::get_type());
end

This replaces all instances of my_driver with extended_driver.

🎯 Instance Override Example 

my_driver::type_id::set_inst_override(
  extended_driver::get_type(),
  "env.agent.driver"
);

Only the specified instance path is overridden.

🔍 Factory Debugging 

+UVM_FACTORY_PRINT

Prints factory configuration and override mappings.

📊 Type Override vs Instance Override
Feature Type Override Instance Override
Scope All instances Specific instance
Flexibility Global Targeted
Usage Regression-level changes Fine-grained customization
🧠 Key Takeaways
  • Always use factory-based creation
  • Never use direct new() for components
  • Factory enables powerful test customization
  • Essential for professional UVM environments
⬅ Back to UVM Components