Out of block access of overridden class declaration parameters

SystemVerilog
1

Hello,
I have a class with uvm_config_db #()::get method which tries to access a parameterized interface. This interface is set in top_tb.
Below is the code snippet. In the code below “uvm_config_db #(virtual int_ctrl_if#(dac_lib::param_cfg_c#()::NUM))::get(”, the NUM points to 5.
So my question is , is there any way where in a typedef of a class can be declared commonly (somewhere like a package) visible space so that the overridden class declaration parameter can be used in the uvm_config_db::get method as shown below (which would point NUM to 8 instead of 5).

module top_tb;
 parameter NUM = 8;
 typedef param_cfg_c #(.NUM(NUM)) param_cfg_t;
....
endmodule;
package dac_lib;
 class param_cfg_c #(parameter int NUM = 5);
 .....
 endclass
endpackage;

package my_lib;
 class base_test extends uvm_test;
  ....
  function void build_phase(uvm_phase phase);
   uvm_config_db #(virtual int_ctrl_if#(dac_lib::param_cfg_c#()::NUM))::get(null, get_dut(), "int_if", cfg.int_if)
  endfunction;
 endclass;
 .....
endpackage;
2

In reply to Aryan:

There are two approaches that I can think of for what you are looking for.

The first is to use a common package for both the testbench module override and the class overrides

package globals; 
  parameter NUM = 8;
endpackage
module top_tb;

 typedef param_cfg_c #(.NUM(globals::NUM)) param_cfg_t;
....
endmodule;
package my_lib;
 class base_test extends uvm_test;
  ....
  function void build_phase(uvm_phase phase);
   uvm_config_db #(virtual int_ctrl_if#(globals::NUM))::get(null, get_dut(), "int_if", cfg.int_if)
  endfunction;
 endclass;
 .....
endpackage

The other approach is getting rid of the parameters, or at least keeping them from propagating up to the top level of testbench. There have been many papers written about this; here are just a few.
How to Avoid Parameter Creep for Parameterizable Agents and Interfaces
Parameters, UVM, Coverage & Emulation
Parameterized Classes, Interfaces & Registers

3

In reply to dave_59:

Thanks Dave. Your code snippet looks feasible for my testbench code.