Wednesday, October 20, 2010
OVM phases and run_test
When we call the run_test() task in the ovm_test class, which phases of the ovm are executed and in which order???
very simple and straight forward answer by Dave (Doulos)
When you call run_test, the simulation proceeds by calling the phase methods in every instantiated ovm_component, starting with build, then connect, end_of_elaboration, start_of_simulation, run, extract, check and finally report.
Most phase methods are executed in a bottom-up order which means the method is started in a child component before the parent. The exception is build which is run top-down since each parent is responsible for building its child components.
All of the phases (except for run) are functions which means that the simulation time only advances during the run phase.
Most phase methods are executed in a bottom-up order which means the method is started in a child component before the parent. The exception is build which is run top-down since each parent is responsible for building its child components.
All of the phases (except for run) are functions which means that the simulation time only advances during the run phase.
what is the need for a virtual interface container in OVM
Before getting into the details let's look at these questions
Can we use field automation macros with virtual interfaces. Or
Can we use factory concept with virtual interfaces?
well if you are not sure...let me say that you can't do so.
How do we use configuration mechanism to use a different interface in place of the one coded
the answer is you have to add some redundancy...create an object with the virtual interface in it i.e define a class which contains the virtual interface, on this object you can use all the configuration/factory mechanism...
interface ifc_a; endinterface class vif_container_a extends ovm_object; virtual ifc_a vif; `ovm_field_utils_begin(vif_container_a) `ovm_field_utils_end function void do_copy(ovm_object rhs); vif_container_a vc; if(!rhs || !$cast(vc, rhs)) return; vif = vc.vif; endfunction ovm_object_registry #(vif_container_a, "vif_container_a") vc_reg; function string get_type_name(); return "vif_container_a"; endfunction endclass
We use the do_copy hook as part of the container copy to get around the fact that the field automation macros don't support VIFs. Now you can use the factory to get different VIF containers.
Since the factory creates new instances of objects you still are left with the issue of knowing what kind of VIF you have so you can bind it to an actual interface.
Since the factory creates new instances of objects you still are left with the issue of knowing what kind of VIF you have so you can bind it to an actual interface.
For examples on virtual interface containers and usage...refer OVM cookbook.
Threads on OVM world forum:
Can an interface pass a reference to itself?
Suggestion from Doulos is always use a parameterized class (the virtual interface container) when you use parameterized virtual interface and the parameter of the class must be virtual interface when passed, so a type (int could be used as default setting but should be a type, when passing care must be taken so that it is virtual interface)....this approach works with questa only as per ovmworld forum
class if_wrapper #(type my_if_t = int) extends ovm_object; my_if_t v_if; [..] endclass; Foo_intf #(.BAR(10),.GAR(11)) intf; if_wrapper #(virtual Foo #(.BAR(10),.GAR(11))) wrap = new("intf",intf);ss
viewing cover groups in ncsim/simvision
I could not see cover groups in class browser of simvision...
why can't we see covergroups embedded in classes...
covergroup comes into class properties(data) or methods or is a special case ?
solution...is
Launch in GUI mode....select coverage from design browserthen vmanager/emanager will be launched and you can see all covergroups/coverage in the vmanager....enjoy...
Thursday, October 14, 2010
Approaches for Power Management verification of SoC having dynamic power and voltage switching
