Class uvm_callbacks
Inheritance Diagram of uvm_callbacks
Collaboration Diagram of uvm_callbacks
Name |
Default value |
Description |
|---|---|---|
T |
uvm_object |
|
CB |
uvm_callback |
Name |
Type |
Description |
|---|---|---|
reporter |
Name |
Actual Type |
Description |
|---|---|---|
super_type |
Parameter CB This type parameter specifies the base callback type that will be managed by this callback class. The callback type is typically a interface class, which defines one or more virtual method prototypes that users can override in subtypes. This type must be a derivative of uvm_callback. |
|
this_type |
Functions
- static function void add ( uvm_object obj, uvm_callback cb, uvm_apprepend ordering ) [source]
Registers the given callback object, cb , with the given obj handle. The obj handle can be null , which allows registration of callbacks without an object context. If ordering is UVM_APPEND (default), the callback will be executed after previously added callbacks, else the callback will be executed ahead of previously added callbacks. The cb is the callback handle; it must be non- null , and if the callback has already been added to the object instance then a warning is issued. Note that the CB parameter is optional. For example, the following are equivalent:
uvm_callbacks#(my_comp)::add(comp_a, cb); uvm_callbacks#(my_comp, my_callback)::add(comp_a,cb);
- static function void add_by_name ( string name, uvm_callback cb, uvm_component root, uvm_apprepend ordering ) [source]
Registers the given callback object, cb , with one or more uvm_components. The components must already exist and must be type T or a derivative. As with add the CB parameter is optional. root specifies the location in the component hierarchy to start the search for name . See uvm_root::find_all for more details on searching by name.
- static function void delete ( uvm_object obj, uvm_callback cb ) [source]
Deletes the given callback object, cb , from the queue associated with the given obj handle. The obj handle can be null , which allows de-registration of callbacks without an object context. The cb is the callback handle; it must be non- null , and if the callback has already been removed from the object instance then a warning is issued. Note that the CB parameter is optional. For example, the following are equivalent:
uvm_callbacks#(my_comp)::delete(comp_a, cb); uvm_callbacks#(my_comp, my_callback)::delete(comp_a,cb);
- static function void delete_by_name ( string name, uvm_callback cb, uvm_component root ) [source]
Removes the given callback object, cb , associated with one or more uvm_component callback queues. As with delete the CB parameter is optional. root specifies the location in the component hierarchy to start the search for name . See uvm_root::find_all for more details on searching by name.
- static function CB get_first ( int itr, uvm_object obj ) [source]
Returns the first enabled callback of type CB which resides in the queue for obj . If obj is null then the typewide queue for T is searched. itr is the iterator; it will be updated with a value that can be supplied to get_next to get the next callback object.
If the queue is empty then null is returned.
The iterator class uvm_callback_iter may be used as an alternative, simplified, iterator interface.
- static function CB get_last ( int itr, uvm_object obj ) [source]
Returns the last enabled callback of type CB which resides in the queue for obj . If obj is null then the typewide queue for T is searched. itr is the iterator; it will be updated with a value that can be supplied to get_prev to get the previous callback object.
If the queue is empty then null is returned.
The iterator class uvm_callback_iter may be used as an alternative, simplified, iterator interface.
- static function CB get_next ( int itr, uvm_object obj ) [source]
Returns the next enabled callback of type CB which resides in the queue for obj , using itr as the starting point. If obj is null then the typewide queue for T is searched. itr is the iterator; it will be updated with a value that can be supplied to get_next to get the next callback object.
If no more callbacks exist in the queue, then null is returned. get_next will continue to return null in this case until get_first or get_last has been used to reset the iterator.
The iterator class uvm_callback_iter may be used as an alternative, simplified, iterator interface.
- static function CB get_prev ( int itr, uvm_object obj ) [source]
Returns the previous enabled callback of type CB which resides in the queue for obj , using itr as the starting point. If obj is null then the typewide queue for T is searched. itr is the iterator; it will be updated with a value that can be supplied to get_prev to get the previous callback object.
If no more callbacks exist in the queue, then null is returned. get_prev will continue to return null in this case until get_first or get_last has been used to reset the iterator.
The iterator class uvm_callback_iter may be used as an alternative, simplified, iterator interface.
- static function void display ( uvm_object obj ) [source]
This function displays callback information for obj . If obj is null , then it displays callback information for all objects of type T , including typewide callbacks.
CLASS
uvm_callbacks #(T,CB)
The uvm_callbacks class provides a base class for implementing callbacks, which are typically used to modify or augment component behavior without changing the component class. To work effectively, the developer of the component class defines a set of "hook" methods that enable users to customize certain behaviors of the component in a manner that is controlled by the component developer. The integrity of the component's overall behavior is intact, while still allowing certain customizable actions by the user.
To enable compile-time type-safety, the class is parameterized on both the user-defined callback interface implementation as well as the object type associated with the callback. The object type-callback type pair are associated together using the uvm_register_cb macro to define a valid pairing; valid pairings are checked when a user attempts to add a callback to an object.
To provide the most flexibility for end-user customization and reuse, it is recommended that the component developer also define a corresponding set of virtual method hooks in the component itself. This affords users the ability to customize via inheritance/factory overrides as well as callback object registration. The implementation of each virtual method would provide the default traversal algorithm for the particular callback being called. Being virtual, users can define subtypes that override the default algorithm, perform tasks before and/or after calling super.<method> to execute any registered callbacks, or to not call the base implementation, effectively disabling that particular hook. A demonstration of this methodology is provided in an example included in the kit.