uvm_callback，设计者在进行class的function设计时，有意留下的一些hook，总是遍历某个pool中的对象；
使用者在使用时，将实现添加到某个pool中；
callback中，最重要的三个class；
1)pool类，uvm_callbacks，实现pool的register和add；
2)调用接口类，uvm_callback_iter，实现对pool中对象的遍历；
3)uvm_callback，供extend的基础类，只是定义了callback的mode；
uvm_callbacks类：其中定义了两类pool：
1)不指定uvm_object(null类型)的，m_tw_cb_q；
2)指定具体的uvm_object的，m_pool；
uvm_callbacks_base，只是实现了add和register的小的function的原型定义；
定义了m_b_inst的static变量，以及m_pool的以uvm_object为索引的，uvm_queue，
uvm_typed_callbacks，实现了对uvm_queue中的callback进行add，delete，get，find的function；
定义了m_t_inst的static变量，以及m_tw_cb_q类型的uvm_queue，其中保存uvm_callback；
uvm_callbacks，定义了register，add，delete，add_by_name，delete_by_name的function；
add function，会根据uvm_object是会为null，来判断是写入m_pool还是tw_cb_q中；
delete function，类似；add_by_name，delete_by_name，首先根据uvm_root找到
某个child的对象queue，之后再遍历调用相应的函数；
m_get_q，根据uvm_object是否为null，来拿到tw_cb_q或者m_pool中的queue；
uvm_derived_callbacks，目前感觉用处不大；
之上定义的很多function都是static类型，
uvm_callback_iter，参数化uvm_object，以及uvm_callback的两个参数，虽然pool或者queue都是static的；
但是uvm_object以及callback可以作为删选类型，来保证拿到的queue是需要的那一组；
static函数，first，last，next，prev；
uvm_callback，只定义了enable_mode，其他的function，都供设计者，进行extend设计，
然后使用者在进行extend，继而add到相应的pool，
所以uvm_callback会被继承两层。
callback相关的macros：
1)由于很多参数化类的关系，所以callbacks以及callback_iter都对具体类型进行了typedef；
如对于uvm_reg，分别对pool和iter进行了typedef；uvm_reg_cbs是设计者已经extend的一级class；
2)对register函数的包装：
macros，uvm_register_cb(T,CB)，调用相应callbacks的m_register_pair函数；
3)do callback函数的包装；
macros，uvm_do_callbacks，遍历iter提供的对象；可以直接在宏中制定function名字；
macros，uvm_do_obj_callbacks_exit_on，在函数的某个返回值，退出；
应用中，环境设计者：
1)对uvm_callbacks进行typedef；
2)从uvm_callback extend出新的class；
3)在相应的component中留下function接口；
使用者：
1)从uvm_driver_callback extend出新的实现function的class；可以不同的实现都做extend；
2)在top上进行new和add 操作；
这样cb1和cb2 对象都被加到m_root中以driver为索引的uvm_queue中；
add函数的调用，可以不同bus_driver_cbs_t，也可以使用其他的pool的def，但是必须保证存在该class；
add函数，只需要uvm_object对象，以及相应实现正确类型的callback对象；