Handle as null

Hi,

A user defined driver is extended from uvm_driver and in new function there are two arguments “name and parent handle”. if parent handle is set “null” then my driver becomes child of uvm_top and the uvm_top is child of uvm_component is this flow is correct?.

One more question, the task run_test in uvm_testbench is called in initial block, this run_test calls a static task called m_run_phase() which again calls the execute_phase method using phase uvm handle. after this what method is called out of these (execute method of uvm_topdown_phase,uvm_bottomup_phase ,uvm_task_phase)?

Thank you

In reply to sasi_8985:

You were mixing up the terms for child and parent. I recommend against using parent and child when referring to OOP inheritance. Parents create(construct) children and they are distinct objects from their parents. When you inherit property, that property becomes yours and all your property belongs to one object. Use base and extended.

The UVM uses terms parent and child to refer to relationships between objects when build a hierarchical tree/graph structure. The class uvm_component has a handle to its parent and handles to all its children so that you can traverse the hierarchical structure. This terminology is used in most programming languages and is independent of OOP.

You correct that if the parent argument is null when constructing any object derived for uvm_component, the UVM sets the parent to the uvm_top object.

I don’t understand your second question, or what you are trying to understand. I’m not sure if going into the details of the UVM implemntation will be productive in this forum.

Hi Dave,
Thanks for the reply…my second question is how each component phases execution is started in the uvm implementation…like for example what starts the build_phase method of every component

Thank you.

In reply to sasi_8985:

UVM phasing is overly complex due to user defined phase domains and phase jumping. (See all the layers from the call stack below for just one component)
The build_phase is a top_down traversal and is slightly more complex because the children are not constructed until after the parents build_phase completes.

All you really need to know is that each executable phase is a virtual method of uvm_component, and every phase of every component gets called at the proper time whether you have overridden it or not.

[ 0] Function my_test::build_phase my_test.sv:9
[ 1] Function uvm_build_phase::exec_func /uvm-1.1d/src/base/uvm_common_phases.svh:54
[ 2] Function uvm_topdown_phase::execute /uvm-1.1d/src/base/uvm_topdown_phase.svh:111
[ 3] Function uvm_topdown_phase::traverse /uvm-1.1d/src/base/uvm_topdown_phase.svh:78
[ 4] Function uvm_topdown_phase::traverse /uvm-1.1d/src/base/uvm_topdown_phase.svh:95
[ 5] Task uvm_phase::execute_phase /uvm-1.1d/src/base/uvm_phase.svh:1156
[ 6] Task uvm_phase::m_run_phases /uvm-1.1d/src/base/uvm_phase.svh:1847
[ 7] Task uvm_phase::m_run_phases /uvm-1.1d/src/base/uvm_phase.svh:1844
[ 8] Task uvm_root::run_test /uvm-1.1d/src/base/uvm_root.svh:417
[ 9] Task uvm_root::run_test /uvm-1.1d/src/base/uvm_root.svh:422
[10] Task uvm_pkg::run_test /uvm-1.1d/src/base/uvm_globals.svh:40
[11] Module top my_test.sv:15

Thank you Dave:-)