How to uvm_config_db to set parameter based interface down to my env?

[hugemx830202]

Hi,

Today, I met a new issue with UVM1.0p1, I want to set a paramter based interface from module top level to my env, but it is unsuccessful, I don't why, please help to see if I made mistakes, thanks, here are what I have done:

1. create the parameter interface like this:

interface ubus_if_parameter (parameter int DATAMSB=32) ;

...

endinterface:ubus_if_parameter

2. in my env, declare such interface like this:

virtual interface ubus_if_parameter vif_para;//leave the DATAMSB as default value 32

3. in module top level:

declare such interface as:

ubus_if_parameter #(.DATAMSB(64)) vif_para();//change the DATAMSB value as 64

But the problem is that, if set as the following line:

uvm_config_db#(virtual ubus_if_parameter)::set(uvm_root::get(), "*", "vif_para", vif_para);

then, IUS will report : ncelab: *E,TYCMPAT (./ubus_tb_top.sv,58|92): formal and actual do not have assignment compatible data types (expecting datatype compatible with 'virtual interface ubus_if_parameter#(.DATAMSB(32))' but found an incompatible 'ubus_if_parameter#(.DATAMSB(62)) instance' instead).

But if I set as: uvm_config_db#(virtual ubus_if_parameter#(.DATAMSB(62)))::set(uvm_root::get(), "*", "vif_para", vif_para); I found that the vif_para in my env is null pointer.

So I want to ask where is wrong with my method, how to use uvm_config_db to set parameter based interface to my env?Thanks a lot!

BR

MEIXIAO

Edited April 27, 2011 by hugemx830202

[vishal.jain]

Hi MEIXIAO,

You should declare parameterized interface as below :

interface ubus_if_parameter #(int DATAMSB=32);

...

endinterface:ubus_if_parameter

ubus_if_parameter #(.DATAMSB(64)) vif_para();

virtual interface ubus_if_parameter#(64) vif_para=vif_para;

uvm_config_db#(virtual ubus_if_parameter#(64))::set(uvm_root::get(), "*", "vif_para", vif_para);

-Vishal

[uwes]

hi,

uvm config db requires compatible types. the value arg of set/get needs to be assignment compatible to the type parameter of uvm_config_db! in your example the type is "virtual ubus_if_parameter" which is the same as "virtual ubus_if_parameter#(32)" BUT the instance vif_para is a ""virtual ubus_if_parameter#(64)" which is not asssignment compatible with the #32 variant. its one of the strange sv problems that all types get specialized (and there is nothing like a generic type anymore). in sv assignment compatible means that ALL parameters have to be equivalent!

/uwe

[hugemx830202]

But the fact is that, I want to implement a fully parametered UVC, means that the UVC interface 'DATAMSB' can be changed according to the TB requirements, so I can not perdict DATAMSB value in my UVC env, the only way is to set a default value 32 to it, and change it to 64 in module top, is there some way to implement this in UVM1.0p1?

[uwes]

hi,

the SV LRM has the requirement of assignment compatible types and the restrictions based upon the parameters. however you still got a couple of options:

1. create your uvc supporting the max with of your busses. make the real width a configuration field (not a parameter) and adjust the bus values at runtime by using masks

2. completely parameterize your uvc (passing down all parameters from the top through the env to monitors/agents/drivers etc.). this usually works ok if you have a limited+fixed set of parameters and/or sub components

3. refactor your uvc so that most of it is not parameterized and replace the instances of the generic base classes with derived parameterized classes at runtime.

(basically real vlog parameters have to be at least elab time constants, you cant base them at a runtime decision)

[hugemx830202]

I am not quite understand item 2, I know the method about how to pass down the parameter to class components like driver/monitor/agents, but how to pass down the parameter for interface? Seems we can not use uvm_config_db::set to pass parameter to interface, is that right?

[uwes]

I am not quite understand item 2, I know the method about how to pass down the parameter to class components like driver/monitor/agents, but how to pass down the parameter for interface? Seems we can not use uvm_config_db::set to pass parameter to interface, is that right?

#2 means completely use parameters (the SV language "parameters") in all required places and pass the parameters into all required instances.

parameters are elab time constants - everything passing through uvm_config_db is a runtime thing so that will not work. but why is this an issue?

interface test82i #(int S=3);
endinterface

module test82;
   class monitor#(int S=5);
       virtual test82i#(S) myif;
   endclass

   class agent#(int S=10);
       monitor#(S) mon;
   endclass	

agent#(20) i = new();
endmodule

[Ashik Ghona]

Keep all your parameters used in interface  in package. import that package in appropriate scope. then you don't need to pass parameters with interface and hence you don't need to use uvm_config_db with interface parameter. only normal interface you have to set using uvm_config_db.

 

example : 

//if_pkg.sv file

package if_pkg;

 parameter DATA_WIDTH = 20

endpackage

 

//interface.sv file

import if_pkg :: *

interface my_if (input logic clk);

  logic [DATA_WIDTH-1 : 0] data;

endinterface

 

 

//top.sv file

import if_pkg::*

 

module top;

bit clk= 0 ;

 

my_if   inst_if (.clk(clk));

 

DUT #(

           .DATA_WIDTH(if_pkg::DATA_WIDTH)

          )

        dut_inst(

                     //ports

                    );

initial 

 begin

   uvm_config_db #(virtual my_if):: set(uvm_root::get(), "*" , "inst_if",  inst_if);

 end

 

endmodule

 

So in above code DATA_WIDTH will be visible inside instance of my_if interface and you don't need to pass parameter to interface. It will be passed to DUT also 

[tudor.timi]

Grouping your parameters in a package like this just means that all class instances will have the same value for the data width (as per your example). The whole idea with parameterized classes is that you can have a instance with a data width of 16, one with 32, etc. If you don't need that, then grouping the parameters in one package like this just gives you one place to change should you decide that from now on you want to work with 32 bits instead of 16.

[pratta]

I wrote series of articles about the difficulties that SV parameters introduce when developing reusable verification components.  See the following:

 

http://www.vip-central.org/2012/09/parameterized-interfaces-and-reusable-vip-part-1/

http://www.vip-central.org/2012/09/parameterized-interfaces-and-reusable-vip-part-2/

http://www.vip-central.org/2012/09/parameterized-interfaces-and-reusable-vip-part-3/