New function in ovm

Hi,

i confused with function new in ovm

function new(string name,ovm_component =null)//what’s the difference b/n parent with null and without null.

The use of the = sign in the header to a function call is to specify a default value.

In:
function new(string name,ovm_component parent =null)

The argument parent is being set to a null pointer, which is different from:

function new(string name,ovm_component parent)

which does not set it to anything. This is there for your safety because there might be situations where the parent is null.

If you don’t reproduce this signature, then a run time error will occur, especially if the parent argument is also not passed a handle (usually ‘this’)

If you call:

new(“my_handle”);

Then the ovm_component does not have a parent specified and is therefore part of ovm_top.

If you call:

new(“my_handle”, this);

The ovm_component is registered as having the component that created it as its parent. As far as the OVM is concerned it his then part of the OVM component hierarchy under the parent component.

In reply to mperyer:

The only reason the parent argument of an ovm_component would be null is for the top-level of your test. Your test is the parent of the env(s); the env is the parent of agents and scoreboards, the agent is the parent of monitors and drivers; etc.

When you construct classes in SystemVerilog, there are no built-in parent/child structural relationships (HAS-A in OOP terminology). The OVM methodology takes care of this for you by building these parent/child data structures in the ovm_component base class.

In reply to dave_59:

Hi Dave,

Your test is the parent of the env(s); the env is the parent of agents and scoreboards, the agent is the parent of monitors and drivers; etc.

We are instantiating the env in the test and we are not extending the env to create the test. Correct? If that is the case then how will test become parent of the env?

Thanks
sbatta

In reply to sbatta:

You don’t instantiate the env in the test, you construct it by calling the factory method create() and passing it the parent argument ‘this’ to its constructor. ‘this’ is a handle to the current object, which is your test.

We are using the parent and child terminology for structural hierarchy, not for class inheritance. For that we say a base class is extended into a subclass.

In reply to dave_59:

Thnaks Dave,
Here my sample code is

`include"ovm.svh"
import ovm_pkg::*;
module top;
class test extends ovm_test;
 `ovm_component_utils(test);
 function new(string name="test",ovm_component parent =null);
  super.new(name,parent);
 endfunction
 function void build();
  ovm_report_info(get_full_name(),"Welcome to OVM",OVM_LOG);
 endfunction
 task run();
  #100ns;
 endtask
 test t1;
initial
  begin
   t1=new("t1",null);
  end
endmodule

here my log file is…
OVM_INFO @ 0: reporter [RNTST] Running test test…
OVM_INFO @ 0: ovm_test_top [ovm_test_top] Welcome to OVM
OVM_INFO @ 0: t1 [t1] Welcome to OVM

my questions are
1.How the hierarchy is display(differentiate ovm_test_top and t1)
2.I confused with (ovm_component parent) in new function

In reply to aslambasha:

There are many problems with your code. You must not have done a simple cut and paste of your code.

  1. You must not both `include ovm.sv and import the ovm_pkg. You will wind up with two separate definitions of the OVM base class library. You should only import ovm_pkg. See SystemVerilog Coding Guidelines: Package import versus `include - Verification Horizons to see an explanation of the differences. Most simulators have compiled the OVM package for you. Otherwise, you need to compile ovm_pkg.sv
  2. There was a missing endclass : test
  3. You should not be using get_full_name() as the ID argument to ovm_report_info(). That information is already provided by the report.
  4. There was a missing run_test(). You would not have seen “Running test test…” without that statement. So your code sample here is not what you ran.
  5. Assuming the code that you ran had a run_test(“test”); or run_test(); with the command line option +OVM_TESTNAME=test, then you should not explicitly constructing the test class yourself. You wind up with two instances of test. “t1” is the instance you explicitly constructed, and “ovm_test_top” is the instance constructed implicitly by run_test(), using the OVM factory. After construction of the test, run_test() begins the build phase execution of all top-level components, i.e. all components with a null parent.

[br]
[hr]
Now to answer your question about why there is a parent argument to the class test even though you know it will always be null - it has to do with the OVM factory.
Since ovm_test is extended from ovm_component, the factory requires that all ovm_components have two arguments; a string name and an ovm_component parent. You registered test with the factory using the `ovm_components_utils(test) macro. The create() method of the factory for all ovm_components always passes two arguments to the constructor of the registered class. This is also why you should not add additional arguments to an extended ovm_component’s constructor. The create method only passes two arguments. Otherwise, the OVM would have needed different factory registration macros and classes for every permutation of constructor arguments.