One thing that always confuses me: is whether add uvm_component parent in the class constructor of UVM objects or not.
As I understood for all items inherited from uvm_component, they all need uvm_component parent as part of constructor input argument.
function new (string name, uvm_component parent);
super.new(name, parent);
endfunction
But all classes inheretied from uvm_object, they dont need.
My question is why?
Per my understanding we are providing uvm_component parent for factory can replace these objects, why uvm_object inherited class dont need to be replaced by factory?
And one more interesting fact I noticed for uvm_sequence: so uvm_sequence constructor does nor require uvm_component parent attribute, but when we create the sequence by factory we provide the parent argument.
The reason why the constructor of a class derived from uvm_component needs to know its parent is because classes derived from uvm_component are part of the infrastructure of your test environment; that test environment has hierarchy and each component needs to know where it sits in that hierarchy. (For example, the configuration database uses the component hierarchy.)
Classes derived from uvm_object are not part of the the infrastructure of your test environment; they are data that flows through it.
In UVM, there are mainly 3 types of classes.
uvm_component - For class based hierarchical testbench structure
uvm_object - Data structures for testbench configuration
uvm_transaction - Stimulus generation & analysis
The values of the arguments of new method are used to create an entry in a linked list which the UVM uses to locate uvm_components in a pseudo hierarchy, this list is used in the messaging and configuration mechanisms. So ideally, while creating the components through create methods, the name argument string should be the same as the declaration handle of the component and the parent argument should be the keyword "this" so that it refers to the uvm_component in which the component is being created.
uvm_object class does not require such things, because it is not used to make the hierarchy of the testbench. And uvm_sequence is also derived from uvm_object only.
uvm_object -> uvm_transaction -> uvm_sequence_item ->
uvm_sequence_base -> uvm_sequence
Per my understanding we are providing uvm_component parent for factory
can replace these objects, why uvm_object inherited class dont need to
be replaced by factory?
I think you are a little confused about parent and base classes.
In the UVM test hierarchy, a parent class is the class that is one level above in the test heirarchy. For example:
uvm_test is the parent of uvm_env
uvm_env is the parent of uvm_agent
uvm_agent is the parent of uvm_driver, uvm_sequencer, uvm_monitor
This is the parent you specify when instantiating child uvm components. It is needed for the config db, build phasing, check phasing, etc etc.
Now, on the other hand, base classes are an OOP concept. You can extend a base class and add on functionality to it. So for example, you may have something like:
my_agent_base extends uvm_agent (uvm_agent is base class, my_agent_base is derived)
my_agent_derived1 extends my_agent_base
my_agent_derived2 extends my_agent_base
If you register all these components with the factory, it allows you to override my_agent_base with my_agent_derived1. This allows for swapping-in-and-out of components with different behaviour in your testbench.
You can do this with uvm_components and uvm_objects, no problem. The only requisite is your register them with the factory.
Normally, uvm_objects are dynamic objects created and destroyed during a test multiple times.
uvm_components persist for the entire duration of the test and have phases of execution.
Hope this helps
Related
The above two diagrams are contradicting. Can someone please clarify what is the correct class inheritence for this class? Below mentioned is the link for both in the sequential order
https://www.dvteclipse.com/uvm-1.2_Public_API/uvm_pkg-uvm_port_base.html
It is a little sneaky because both are true. Looking at the source, the first line declare uvm_port_base
virtual class uvm_port_base #(type IF=uvm_void) extends IF;
uvm_port_base inherits from IF, which is a parameter. Default value of IF is uvm_void.
For example, many TLM classes override the parameter with another class to extend from. For Example:
class uvm_blocking_put_export #(type T=int)
extends uvm_port_base #(uvm_tlm_if_base #(T,T));
uvm_tlm_if_base extends form uvm_if_base_abstract, which extends from uvm_report_object, which extends from uvm_object, which extends from uvm_void. Basically uvm_blocking_put_export still has uvm_void as a parent but it also got all the added functionality added by all the other parents. This redirected inheritance is a work around to multiple inheritance challenge for a language that can only support single inheritance*.
*As of the 2012 release, SystemVerilog added a multiple inheritance approach inspired/borrowed/similar-to Java's approach to the issue, by adding interface class and implements. However not all the major simulator vendor haven't implemented the improvement. I'm guessing UVM will eventually be overhauled and utilizes these features after simulator support for this feature is mainstream.
I am working on a ClojureScript wrapper for qx.mobile and would like to programmatically build a cljs type hierarchy mirroring the qx class hierarchy.
Is there a way to get all the subclasses of a qooxdoo class?
How about a programmatic way to query the superclass of a class?
I am already putting qx.Class.getProperties to good use.
Thx, kt
The programmatic way of getting the superclass of a given class is documented at http://demo.qooxdoo.org/current/apiviewer/#qx.Class
<classname>.superclass
or getting the name of the superclass as a string
<classname>.superclass.classname
which means that e.g.
qx.ui.core.Widget.superclass.classname
will return the string "qx.ui.core.LayoutItem".
Regarding the programmatic way to retreive all subclasses of a class:
This is currently not possible without iterating the whole class hierarchy/tree and testing the objects against being subclasses of the given class.
We discussed at https://gitter.im/qooxdoo/qooxdoo that it maybe would be usefull to create an array for each class holding the subclasses. This could be added to the code of the private method __createClass in qx.Class.
We would like to encourage everyone who needs this (or other) functionalities to join us on https://github.com/qooxdoo/qooxdoo/ and help extending qooxdoo by creating a pull requests. Thank you.
After digging arround a bit in qx.Class we decided to implement a method qx.Class.getSubclasses which returns a hash object with all subclasses of a given class.
var subclasses = qx.Class.getSubclasses(qx.ui.core.Widget);
gets all subclasses of qx.ui.core.Widget.
Landed in qooxdoo master with commit https://github.com/qooxdoo/qooxdoo/pull/9037
first issue:
in GObject I confuse that whether the instance object of subclass deriving from parent class inherits properties of parent class or not?
second issue:
in GObject g_object_class_install_properties function adds properties into itself class in class initializer function,but in effect these properties for each instance object of class have a copy.in other words, each instance object of class have a copy of these properties.
in addition, I read GObject code snippet.
at below code in Gobject.c fileļ¼
class->set_property = g_object_do_set_property;
class->get_property = g_object_do_get_property;
firstly when are above functions called?
secondly if subclass derive from parent class subclass overrides these motheds (set_property and get_property),then if g_object_new creats new subclass instance and set properties value the set_property callback function is only called , whether after calling subclass set_property it calls set_property method of parent class or not ?
I don't know that after only calling at a time set_property of subclass,Is set_property method of parent class called at a time?
if you know these issues,please spend you time for anwsering my isses, thank you in advance very much.
If you have not yet seen the GNOME Developer site, it has several pages of useful information relevant to the questions you ask. The links pointed to below contain very simple example code, followed by very detailed descriptions of what happens in the code. The example pages I have cited (and linked) below address your questions specifically, but much more content on the topic is available in surrounding pages.
First issue:
Derivable types can be subclassed further, and their class and
instance structures form part of the public API which must not be
changed if API stability is cared about. They are declared using
G_DECLARE_DERIVABLE_TYPE:
See examples here:
G_DECLARE_DERIVABLE_TYPE()
Second issue:
generic get/set mechanism for object properties. When an object is
instantiated, the object's class_init handler should be used to
register the object's properties with
g_object_class_install_properties.
See examples here: Object properties
I believe your specific question:
when are above functions called?
is addressed is great detail in these, and surrounding paragraphs in the Object Properties link above:
If the user's GValue had been set to a valid value,
g_object_set_property would have proceeded with calling the object's
set_property class method. Here, since our implementation of Foo did
override this method, execution would jump to foo_set_property after
having retrieved from the GParamSpec the param_id [4] which had been
stored by g_object_class_install_property.
Once the property has been set by the object's set_property class
method, execution returns to g_object_set_property which makes sure
that the "notify" signal is emitted on the object's instance with the
changed property as parameter unless notifications were frozen by
g_object_freeze_notify.
I want to know what is wrapper class in salesforce and a scenario of using wrapper class with simple exapmle.??
I would say check it here and RTFM:
http://wiki.developerforce.com/page/Wrapper_Class
A wrapper or container class is a class, a data structure, or an
abstract data type whose instances are collections of other objects.
In Apex and Visualforce this type of class can be extremely useful but
to a new developer the talk of wrapper classes may fly right over your
head, it definitely did for me. Here I will supply a simple demo of
how wrapper classes can be used.
From my understanding, prism's unity container can resolve types event if they have not been registered, does this make _container.RegisterType kinda useless ?
Thanks!
If I am understanding your question correctly, what you are seeing is that Unity can (try to) make instances of classes directly, which is different from resolving types. It is perfectly reasonable to ask Unity to create a class "directly", however, in order to leverage "Inversion of Control", you would normally ask a container to resolve an interface, where you have mapped an interface to a class via RegisterType. This way you can map different implementations of classes to interfaces, without having to change your code, that is "Inversion of Control" and "Interfaced-based Programming" at work.
This process involves you asking to resolve an interface, followed by Prism finding what is bound to the interface i.e. resolution, and then making an instance for you i.e. factory capabilities. The factory capabilities of Unity will ensure that any other dependencies are resolved that are required to make an instance of the resolved class e.g. using dependency injection on class constructor parameters. This whole process is recursive until all dependencies are resolved.
For Example
If you ask for an IFoo and it is bound Foo, Unity will try and make an instance of Foo. If Foo has a constructor which takes an IBar, Unity will try and resolve IBar and create an instance of this to use in the constructor for IFoo.
So in the following code:
We can resolve IFoo as described above.
We can make an instance of class Bar directly, as it has no dependencies.
We can make an instance of class Foo directly, as it has a dependency on IFoo, but we have registered it.
We cannot make an instance of Woo directly as there is no registration for IYay.
//Types
public interface IBar{}
public class Bar : IBar {}
public interface IFoo{}
public class Foo : IFoo{ public Foo(IBar bar) {} }
public interface IYay{}
public class Woo { Woo(IYay yay){} }
//Registrations
container.RegisterType<IFoo, Foo>();
container.RegisterType<IBar, Bar>();
//Resolve IFoo
IFoo foo = container.Resolve<IFoo>();
//Create Bar directly
Bar bar = container.Resolve<Bar>();
//Create Foo directly
Foo foo = container.Resolve<Foo>();
//Create Woo directly - won't work as IYay is not registered!
Yay yay = container.Reolve<Yay>();
In the example above RegisterType is used to map a concrete implementation to an interface. It is at this point that we can map any implementation we want and this will ripple throughout our program as long as the container is always used to resolve types.
For example, if we change what IBar is mapped to, then any time IFoo is resolved it will be created with that different implementation of IBar. This gives us a substantial way of altering a program's behaviour by just changing a single line of code i.e. RegisterType.