The problem about library uvm-1.1c

[mrforever]

Hi, all experts

I met such a UVM_FATAL when i compile the codes as follows.

file1:

interface chpp_sigif;

...

endinterface: chpp_sigif

file2:

class chpp_env extends uvm_env;

// Virtual Interface variable

protected virtual interface chpp_sigif duv_vif;

...

function void build_phase(uvm_phase phase);

...

if(!uvm_config_db#(virtual chpp_sigif)::get(this, "", "duv_vif", duv_vif)) begin

`uvm_fatal("NOVIF",{"virtual interface must be set for: ",get_full_name(),".duv_vif"});

end

...

endfunction

...

endclass: chpp_env

vcs(Version: G-2012.09) reports such a UVM_FATAL as follows:

UVM_INFO @ 0: reporter [RNTST] Running test test_config...

UVM_FATAL ../sv/00_top/100_chpp_env.sv(73) @ 0: uvm_test_top.env [NOVIF] virtual interface must be set for: uvm_test_top.env.duv_vif

--- UVM Report Summary ---

** Report counts by severity

UVM_INFO : 1

UVM_WARNING : 0

UVM_ERROR : 0

UVM_FATAL : 1

** Report counts by id

[NOVIF] 1

[RNTST] 1

$finish called from file "/EDA_Tools/synopsys/vcs1209/etc/uvm-1.1/uvm-1.1c/src/base/uvm_report_object.svh", line 277.

The UVM_FATAL says that virtual interface must be set for: uvm_test_top.env.duv_vif. But duv_vif is already the virtual interface. And i open the file "uvm_report_object.svh" but cann't find any clue. Will it be the problem of uvm-1.1c library which is downloaded from the sites http://www.accellera.org/downloads/standards/uvm ?

The other information reported by vcs

*********** IMPORTANT RELEASE NOTES ************

You are using a version of the UVM library that has been compiled

with `UVM_NO_DEPRECATED undefined.

What's the purpose defining the macro `UVM_NO_DEPRECATED? Could any expert explain my question? thanks very much.

[mrforever]

Oh, my god! Forget today is Christmas day! The problem will sink unfortunately!

Sadly...

[ajeetha.cvc]

Do you have a corresponding uvm_config_db#(virtual chpp_sigif)::set somewhere in your env/test?

Ajeetha, CVC

www.cvcblr.com/blog

[mrforever]

Do you have a corresponding uvm_config_db#(virtual chpp_sigif)::set somewhere in your env/test?

yes, i have such codes in testbench

...

chpp_sigif duv_if(); // SystemVerilog Interface

typedef virtual chpp_sigif chpp_vif;

...

initial begin

uvm_config_db#(chpp_vif)::set(uvm_root::get(), "*", "duv_if", duv_if);

run_test();

end

...

Edited December 25, 2012 by mrforever

[mrforever]

i got it, maybe i should change the name duv_if to duv_vif.

thanks, Merry Christmas, ajeetha.cvc

[mpeer]

Hi mrforever,

One of my colleague had similar issue. try the same code without "typedef"

chpp_sigif duv_if(); // SystemVerilog Interface

...

initial begin

uvm_config_db#(virtual interface chpp_vif)::set(uvm_root::get(), "*", "duv_if", duv_if);

run_test();

end

Regards

Peer Mohammed

[adielkhan]

Open uvm debug window. View the set and get calls. Check names and types match. Sub window should contain all sets and gets on a variable.

-adiel

[mrforever]

i have solved the problem when i change the name duv_if to duv_vif. but i still have one question. how does uvm_config_db::set() and uvm_config_db::get() do the type match in the case of that duv_vif is not a virtual interface in testbench while duv_vif is virtual interface in class chpp_env. Will uvm ignore the virtual keyword when it does the type match using uvm_config_db?

[mrforever]

thanks, adiel

[jadec]

how does uvm_config_db::set() and uvm_config_db::get() do the type match in the case of that duv_vif is not a virtual interface in testbench while duv_vif is virtual interface in class chpp_env. Will uvm ignore the virtual keyword when it does the type match using uvm_config_db?

You used a typedef for the virtual interface type parameter in your set:

typedef virtual chpp_sigif chpp_vif;

This is an exact match to the virtual interface type parameter in the get.

[mrforever]

You used a typedef for the virtual interface type parameter in your set:

typedef virtual chpp_sigif chpp_vif;

This is an exact match to the virtual interface type parameter in the get.

Hi, jadec.

Thanks for your reply. Maybe i didn't state the problem clearly. Now the codes as follows can work well.

file1:

interface chpp_sigif;

...

endinterface: chpp_sigif

file2:

class chpp_env extends uvm_env;

// Virtual Interface variable

protected virtual interface chpp_sigif duv_vif;

...

function void build_phase(uvm_phase phase);

...

if(!uvm_config_db#(virtual chpp_sigif)::get(this, "", "duv_vif", duv_vif)) begin

`uvm_fatal("NOVIF",{"virtual interface must be set for: ",get_full_name(),".duv_vif"});

end

...

endfunction

...

endclass: chpp_env

file3:

module chpp_tb_top;

import uvm_pkg::*;

import chpp_pkg::*;

`include "test_lib.sv"

chpp_sigif duv_vif(); // SystemVerilog Interface

...

initial begin

uvm_config_db#(virtual chpp_sigif)::set(uvm_root::get(), "*", "duv_vif", duv_vif);

run_test();

end

...

endmodule

file4:

package chpp_pkg;

import uvm_pkg::*;

`include "uvm_macros.svh"

typedef uvm_config_db#(virtual chpp_sigif) chpp_vif_config;

typedef virtual chpp_sigif chpp_vif;

...

endpackage: chpp_pkg

In file2, we can know that duv_vif in uvm_config_db::get() is virtual, but in file3, duv_vif in uvm_config_db::set() should be non virtual because the line "chpp_sigif duv_vif(); // SystemVerilog Interface" has declared duv_vif. The variable chpp_vif in file4 isn't used at all. Then how do uvm_config_db::set() and uvm_config_db::get() do the type match in the case of that duv_vif is not a virtual interface in testbench while duv_vif is virtual interface in class chpp_env.

Best regards

mrforever

Edited January 5, 2013 by mrforever

[jadec]

A virtual interface is a variable that holds a reference to an interface instance. You can assign an interface instance to a virtual interface variable, you can't assign to an non-virtual interface. So the uvm_config_db::set() in file3 is correct in its use of virtual interface type.

Both the type parameter and the string name in set() must match the get().

You could use the "chpp_vif" typedef in place of the type "virtual chpp_sigif", but generally it's better to use the same text in both places so that it is obvious that they are the same.

You were right that your original problem was that the string names didn't match. The types were not the issue.

[mrforever]

Hi jadec,

Thanks very much, I think I understand it now.