Illegal virtual interface dereference error

UVM
, , , ,
1

Driver Code -
class d_driver extends uvm_driver #(seq_item);
`uvm_component_utils(d_driver)
virtual d_interface intf1;

function new (string name,uvm_component parent);
super.new(name,parent);
endfunction

function void build_phase(uvm_phase phase);
super.build_phase(phase);
if(!uvm_config_db#(virtual d_interface)::get(this,“”,“d_interface”,intf1))
`uvm_error(“”, “uvm_config_db::get - Failed”)

endfunction

task run_phase(uvm_phase phase);
phase.raise_objection(this);
seq_item_port.get_next_item(req);
$display(“--------------------------------- Received Item------------------------------”);
req.print();
seq_item_port.item_done();
#20;
put_data();
phase.drop_objection(this);

endtask

task put_data();
intf1.addr <= req.addr;
intf1.data <= req.data;
intf1.rd_en <= req.rd_en;
intf1.wr_en <= req.wr_en;
endtask

endclass

top code -
include "uvm_macros.svh" import uvm_pkg::*; include “d_interface.sv”
include "d_dut.v" include “seq_item.sv”
include "s_sequencer.sv" include “s_sequence.sv”
include "d_driver.sv" include “d_env.sv”
`include “d_test.sv”

module tb_top;

d_interface d1();
d_dut dut1(.intf(d1));

initial begin
  uvm_config_db#(virtual d_interface)::set(null,"*","d_interface",d1);
  uvm_top.finish_on_completion = 1;
  run_test("d_test");
end

endmodule

Error -
** Fatal: Illegal virtual interface dereference.

I don’t think there is any error in interface file. But in case you need other file as well let me know.

2

In reply to Appledore22:

The error message is typical when a testbench component does not get the virtual interface from the config_db.

And you should put the following lines of code to the connect_phase:

if(!uvm_config_db#(virtual d_interface)::get(this,"","d_interface",intf1))
`uvm_error("", "uvm_config_db::get - Failed")
3

In reply to chr_sue:

Hi,

I got into the same issue. The fix worked also in my case. I’m surprised that the handle of the virtual interface needs to be taken twice from the config db. The first time in the build phase, the second time in the connect_phase. Why?

Thank you for the help.

Fabio

1 Like
4

In reply to gennaro:

I did not say you have to do this twice. he UVM is a phased approacg. Ther are special phases for doing certain things. The build_phase is used to construct all components in your testbench. It works top-down. The connect_phase is used to perform all connections, virtual connectiosn as well as the TLM connections. This works bottom-up.

5

In reply to chr_sue:

Thank you. It make sense.

Hope you have patience to help me/us to understand further. There’re some students ramping up on UVM/system verilog, thus the topic is quite interesting from academycal perspective.

Apparently, the usage of connect phase seems to be strictly required, also when there’s no specific top-down bottom-up requirement.

There’s a simple design. There’s one physical interface which is passed, through the config db at two components:

  • test class
  • virtual seqeuncer instantiated by the test class

initial 
     begin
        uvm_config_db#(virtual tb_sv2uvm_if)::set(uvm_root::get(),
                "*uvm_test_err_inj","tb_sv2uvm_if_vi",tb_sv2uvm_if);
        uvm_config_db#(virtual tb_sv2uvm_if)::set(uvm_root::get() , 
                "*m_uvm_tb_vseqr","m_tb_sv2uvm_if", tb_sv2uvm_if);	 
        run_test("uvm_test_err_inj");
     end

The test gets the handle in the build phase (currently, which is wrong but works).
The vsqr has to get the handle in the connect phase (otherwise there’s the error message of this thread).

One analomaly: the error message is fired by vsim when the first signal of the interface is accessed. Such line belongs to the first sequence executed by the vsqr.

I would have expected the error to be fired in the build phase where we were doing


 if(!uvm_config_db#(virtual tb_sv2uvm_if)::get(this,"","m_tb_sv2uvm_if",m_tb_sv2uvm_if))
    `uvm_error("", "uvm_config_db::get - Failed")

In other words, why the get method works? Maybe the physical/virtual connection is done by vsim in the connect phase?

1 Like
6

In reply to gennaro:

A few remarks.
(1) All tarnsaction level components like sequencers, scoreboardsa, coverage collectors do NOT need any virtual interface. These components do never knwo anything about tieming and clock cycles, reset etc.
(2) When you are doing the connections at the end of the build_phase this will work, but it is a bad coding style because we have the connect_phase to implement the connections.

With respect to the usage of the uvm_config_db commands:
(1) for the set in the toplevel module use as the first argument ‘null’. This is indicating the 2nd argument has to be considered as an absolute path
(2) for the get command commonly use as the first argument ‘this’. This indicates the 2nd argument has to be considered as an absolute path.
Following these rules covers 95% of the uvm_config_db usage.
A different 1st argument you need whan you want to pass data to sequences, because they do not belong to the testbench topology.

Hope this helps to fix your issues.