uvm设计分析——callback

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对象；