Cadence IUS: When to "set_config" encapsulated interfaces ...

[Don Hewitt]

In my tb_top (top level module), I use "set_config" to put the class object that encapsulates my interfaces within an initial block. The problem is that the initial block does not get executed before the build() method of the driver and monitors that use "get_config" to retrieve the interfaces.

What am I missing here? This works using Mentor.

[Bart]

Hi Don

Are you calling the set_config in a separate initial block to the run_test() call? You may just have a standard Verilog race condition between the execution of separate initial blocks, i.e. the run_test() initial block gets executed first, and the hierarchy built, before the set_config call is executed.

If this is the case, try putting the set_config in the same initial block as run_test(), but before the run_test() call..

[Don Hewitt]

Good thought. The run_test() is in the same initial block. I actually have several initial blocks and none get executed before the build() method of the monitor and driver. The Cadence CAE has suggested that maybe the initial blocks don't execute until the run() phase - god i hope not. I have reviewed the recommended approach to this in the UVM book and I am following it.

The only other thing I can think of is that maybe breakpoints don't work in initial blocks - hard to believe.

thanks

[Bart]

The Cadence CAE has suggested that maybe the initial blocks don't execute until the run() phase - god i hope not.

Its a possibility - once you execute the initial block containing the run_test() call, all the simulation phases are executed. All the phases up to run execute in zero time, so its possible your other initial blocks are not executed until the run phase, once the initial block containing run_test suspends..

Try adding a delay (e.g. #10) in front of the run_test as a quick hack to see if that's the problem?

[KathleenMeade]

Hello Don!

I suggest that you put the set... syntax in the same initial block as the run_test() call Then you know that the set is called before the test is created and started.

Are you using the new uvm_config_db mechanism? This is built into the library now - based on the same mechanism that was suggested in the book - with a common syntax.

In your top-level module:

module top;
...
apb_if apbif(clock, reset);
...

initial begin
  // Configure Virtual Interfaces
  uvm_config_db#(virtual apb_if)::set(null, "uvm_test_top.my_tb.apb0*", "vif", "apbif");
  // Run the UVM Test via the +UVM_TESTNAME command-line option
  run_test();
end
endmodule : top

Then in your driver connect_phase(), for example, you should have something like this:

function void apb_master_driver::connect_phase(uvm_phase phase);
 super.connect_phase(phase);
 if(!uvm_config_db#(virtual apb_if)::get(this, get_full_name(), "vif", vif)
    `uvm_error("NOVIF", {"Virtual interface must be set for : ", get_full_name(), ".vif"});
endfunction : connect_phase

Please let me know if you would like me to send you a small example - or you can take a look at the UVM Reference Flow - posted under the contributions page.

I hope this helps!

Kathleen

[Don Hewitt]

I have the "set_config" syntax in the same initial block as "run_test()". The problem is that the build() method of the monitor gets called even before the "run_test()" line is executed. I am using the Cadence tools and trying to port what worked on Mentor. Not sure what to do here.

[KathleenMeade]

Hi Don,

This does not make sense... The run_test() is the method that creates the test and initiates the phasing. Are you calling the monitor build() directly instead of letting the phasing do it? My suggestion would be to remove the manual build() call so that run_test starts the phasing and initiates the build() at the proper time.

Kathleen

[Don Hewitt]

I agree. It does not make sense. I examined the call stack after breaking in the build() method of my monitor. It traced me back into ovm_root - so I don't think I'm intentionally calling build(). I'll look further.

Thanks

[KathleenMeade]

I consulted with one of the Cadence UVM library developers and here is what he had to say.

It is possible that if he is manually calling build on any of his objects anywhere that he may have an issue (that assumes that he is manually instantiating any components… if all of his components live under the test that gets created by run_test then it is impossible for the run_test to happen after the set_config unless he has done a fork/join around the set_config and run_test).

The other question is whether the set_config is actually hitting his component. He says it works in questa, so it should be okay, but I would make sure that the topology is getting built out the way he expects (the instance names are what he expects, etc).

I'm sorry its not easy to figure out...

Kathleen

[Bart]

Hi Don

Are you creating any hierarchy in the initial blocks? For example do you have calls to create or do you construct any components in the top level module? I've seen problems like you describe when people explicitly create testbench hierarchy as well as calling run_test(). There should be no component creates or constructors in the top module.

[Don Hewitt]

I have three initial blocks in my top level module. I do build up an array of interfaces in the container class. I commented those out just to see and it did the same thing

initial begin

sys_clk = 0;

#(4 * SYS_CLK_PERIOD);

forever begin

sys_clk = #(SYS_CLK_PERIOD/2) ~sys_clk;

end

end

initial begin

fork

clk_rst.run();

join_none

end

initial begin

/*

Set the vif handles in the virtual interface container and then put

the vif_container in the factory config space. The last 0 is to stop

the set_config_object from cloning the vif_container. Each Agent's

Driver and Monitors will pull them out of the factory.

*/

vif_ocn_container_h.axi[0] = dut_axi_00_if;

vif_ocn_container_h.axi[1] = dut_axi_00_if;

vif_ocn_container_h.pif[0] = dut_pif_00_if;

vif_ocn_container_h.pif[1] = dut_pif_00_if;

vif_pcie_container_h.pcie1[0] = dut_pcie_00_if;

vif_gmac_container_h.gmac1[0] = dut_gmac_00_if;

vif_cpri_container_h.cpri1[0] = dut_cpri_00_if;

vif_srio_container_h.srio1[0] = dut_srio_00_if;

vif_ddr3_container_h.ddr31[0] = dut_ddr3_00_if;

set_config_object("*", "vif_pcie_container", vif_pcie_container_h, 0);

set_config_object("*", "vif_gmac_container", vif_gmac_container_h, 0);

set_config_object("*", "vif_cpri_container", vif_cpri_container_h, 0);

set_config_object("*", "vif_srio_container", vif_srio_container_h, 0);

set_config_object("*", "vif_ddr3_container", vif_ddr3_container_h, 0);

set_config_object("*", "vif_ocn_container", vif_ocn_container_h, 0);

/*

To change which test gets run; specify the test on the command line of

the runtb script (-test PCI_TEST). This will send in OVM_TESTNAME =

PCI_TEST to vsim.

*/

//run_test("debug");

run_test("tst_ocn_debug");

end

[Don Hewitt]

I set a break point in the build() method of my test and looked at the call stack. As follows:

worklib.tests_pkg::test_base@1405_.build

worklib.tests_pkg::tst_ocn_debug@1739_1.build

worklib.ovm_pkg::build_phase#(ovm_pkg::ovm_component)@1238_2.call_func

worklib.ovm_pkg::ovm_component@1739_1.do_func_phase

worklib.ovm_pkg::ovm_root@1209_1.m_do_nonblocking_phase

worklib.ovm_pkg::ovm_root@1209_1.do_nonblocking_phase

I am running the test class "tst_ocn_debug" which extends my "test_base" which extends "ovm_test"

I think that the call stack tells me that I am not calling the build() method of my test. Is there another way I can find out? I'll keep on looking.

[Bart]

Hi Don

Do you have a print topology?

[Don Hewitt]

Problem resolved. With the help from Cadence support, we figured out that it was the multi-language command line switches that was causing the problem. Somehow; these switches snuck in even though I was only using SystemVerilog/OVM. I was in a rush to get things going. I guess that in multi-language mode, the test was not started with the "run_test()" in the initial block. Maybe since OVM was not the only language, it thought it needed to start from a different place?

Thanks to all who contributed to this thread.

[nagesh0280]

This issue got resolved by removing the following two options from the irun command line (as this is a SV only environment and they were not needed),

-ml_ovm

-ovmtest tst_ocn_debug

Thanks,

Nagesh

nageshg@cadence.com