The callback mechanism, in fact, is a program developer that uses OOP to provide the internal interface of the module to the user of the program. Some of the behaviors of other component can be changed at test_case height.
The callback function pre_randomize,post_randomize already provided in SystemVerilog. For UVM and VIPs, the other callback functions are the developers of their own programs in advance
Left the hook.
Implementation of callback:
1) It is not advisable to extend the new class directly from component to realize PRE_DO and other function. Because the change of component will make the whole UVM tree change.
2) Consider using the composition of OOP to manipulate, define a Class A, and define virtual PRE_DO as function in its class. After the class is added to the component of the UVM, the Do function
Before calling Pre_do. This does not have any effect on component because there is no action in PRE_DO because it is not redefined. After redefining virtual PRE_DO, you will naturally
Added the relevant execution code.
Implementation in UVM and VIP:
First the character Uvm_callback derives a Class A, and the virtual function is defined as virtual Pre_do; (or Uvm_reg_cbs)
Define UVM_REGISTER_CB(Driver, A); in the driver class . This is equivalent to adding a to the driver class.
Define A_pool to hold an instantiated object of a, and in the driver class you can directly determine whether A_pool is empty to perform pre_do.
In the driver class, use uvm_do_callbacks(Driver, A, PRE_DO) to invoke Pre_do, before the Do function.
This completes the reserved hooks,
When users are using:
The next step is to extended a when needed, and define the PRE_DO function as well. and add it by calling the Add function before Connect_phase .
A_pool::add (Env.i_agt.drv, CB); CB is the object of the extended class of a.
Callback mechanism in UVM