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 Config DB

The uvm_config_db is a hierarchical configuration mechanism used to pass data between UVM components in a flexible and reusable way.

📘 Overview

uvm_config_db allows higher-level components (like tests) to configure lower-level components (like agents, drivers, monitors).

  • Pass virtual interfaces
  • Configure agent active/passive mode
  • Share configuration objects
  • Avoid tight coupling between components

It is typically used during build_phase.

🚀 Why Config DB is Important
  • Enables reusable verification environments
  • Supports hierarchical configuration
  • Prevents hard-coded dependencies
  • Allows flexible test-level control
💻 Basic Syntax
Set Configuration

uvm_config_db#(type)::set(
    parent,
    "instance_path",
    "field_name",
    value
);
Get Configuration

uvm_config_db#(type)::get(
    this,
    "",
    "field_name",
    variable
);
🔌 Example: Passing Virtual Interface 

// In Test (top-level)
uvm_config_db#(virtual my_if)::set(
    this,
    "env.agent",
    "vif",
    vif_handle
);


// In Driver (build_phase)
if (!uvm_config_db#(virtual my_if)::get(
        this,
        "",
        "vif",
        vif
    )) begin
    `uvm_fatal("NOVIF", "Virtual interface not set")
end

The test sets the virtual interface, and the driver retrieves it during build_phase.

🎯 Example: Configuring Agent Mode 

// In Test
uvm_config_db#(uvm_active_passive_enum)::set(
    this,
    "env.agent",
    "is_active",
    UVM_PASSIVE
);

This configures the agent to run in passive mode without modifying the agent code.

🏗 Hierarchy Rules
  • Configuration is applied hierarchically.
  • Higher-level components configure lower-level ones.
  • Instance paths can use wildcards (*).
  • Search happens upward in hierarchy.
⚠ Common Mistakes
  • Calling get() in run_phase instead of build_phase
  • Incorrect instance path
  • Forgetting to check return value
  • Overusing wildcards
📊 Config DB vs Direct Assignment
Feature Config DB Direct Assignment
Reusability High Low
Hierarchy Support Yes No
Scalability Excellent Poor

Run These Examples on EDA Playground

Run the complete UVM Config DB Examples directly in your browser without installing tools.

▶ Open UVM Config DB Example 1

▶ Open UVM Config DB Example 2
⬅ Back to UVM Components