uvm设计分析——tlm
tlm模块，用来在不同模块之间实现实时通信，主要基于两个定义在通信双方的port类来实现。
两个port之间，通过connect函数，来拿到双方的class指针，进而调用对方的function。
但是uvm规定，控制流(调用function与被调用方)只能按一定的方向来执行，所以只有某一类port类可以调对应port的function。
由于imp所在的class中，每次通信可能实现的function不同，而且做virtual function的重载也会引入新的class，
所以imp中的port类，在定义时，就调用parent中对应的function，这样在parent的class中就必须实现相应的function。
tlm模块的类图：
interface class，实现put，get，write，transparent等方法定义，
有两种，tlm_if_base，用在general的object或component class中，
sqr_if_base，用在driver和sequencer class中，
port_component，是基于uvm_component的extend，主要为了方便调用report机制，
port_base，定义connect，binding等function，实现内部provider，provided对象queue的初始化，
port_base与port_component class中互有对方的指针变量，可以实现对方的function，
但是在应用过程中，port_component只是提供了report的访问。
port/export/imp class，是实际应用中的class，都是通过macros来进行实现的。
其中只定义了该port对应的function和一个new函数。
从实现中的连接方式来看，port，export只是命令的传递者，imp是命令的执行者，其中实现了具体的function---调用parent相应的function。
所以，port，export可以被定义很多层级，来方便传递，都不影响最终的执行。
代码中表现为，port调用自己provider的put等函数，即export的provider的put等函数，即imp中调用的parent的put函数。
uvm还规定了自己的连接规则，定义在port_base connect和check_relation function中。每次进行connect函数调用的时候，都会检查。
error类型，1) mask_if不同，用来区分不同的port组;
2) 发起connect的是imp;
3) export连接port;
warning类型，1)port可以连接port，必须是child port连接parent的port;
2)port连接export，imp，必须是同一hierarchy;
3)export连接export，imp，必须是parent export，连接child export，imp;
analysis port并没有这些warning的要求。
从通信方式看，analysis类表示广播，可以connect多个，实现过程中，遍历各个port、export queue中的imp；
实现的是无延时的function write；
其他包括sqr_if都是一对一的，只能connect一个，
实现中，在每个port class的new函数中，都规定了该port能够连接的最小和最大的export，imp，
analysis [0：$]，其他的port，只能是1。在resolve_binding的时候，会进行该size的检查。
从操作行为看，定义的port的function：try_put，can_put，try_get，can_get，try_peek，can_peek，nb_transport，write，
定义的port的task：put， get， peek，transport， (imp中固定function 实现bridge，具体实现与parent class)
sqr_if port中定义的function：item_done，has_do_available，put_response，
定义的task：get_next_item，try_next_item，wait_for_sequences，get，put，peek，
(实现于sequencer，调用于driver)
port_base中的三个重要函数：
1)connect函数，需要显式调用，必须在end_of_elaboration phase结束之前完成，之后调用会报错。
2)resolve_binding函数，由uvm_root 在 end_of_elaboration phase开始隐式递归调用，所有component中的child都会做检查。
3)get_if函数，在put，write等函数中被调用，拿到imp_list中的provider的指针，
port_base中的三个重要变量：
1)this_type m_provided_by[string]
this_type m_provided_to[string]，存放provider和provided的port_base对象类型，在connect函数被赋值；
2)this_type m_imp_list[string]，在resolve_binding函数中，被更新，存放对应provided的对象的类型；
如果provider的size很多，或遍历之后，都放在imp_list中。
3)this_type m_if，指向第一个m_imp_list中的port类型的对象，
各个port class中的size， min，max，mask_if等配置在new的时候，直接初始化。
analysis min为0，max无限制，
其他port，min为1，max为1，
多个export调用同一个imp时的function重名问题，uvm的解决方法是重新define多个不同的class对象的imp，分别调用各自的不同名称的function；
使用时，需要先define，也就是定义一个新的class，之后进行正常的connect，在imp调用的时候，会调用write_suffix这样的function；
从而区分不同的export对应的imp实现。
这样的imp定义，需要根据mask_if来定义各自的class，因为new的时候，MASK define仍然是和正常的imp相对应的。
export并不需要担心重名的问题，因为它的function并没有具体的时候，只是进行imp_list中的遍历调用，所以function内容都一样。
fifo部分，只是将多个port类型和一个mailbox封装在一起，中间保存，传递trans。
tlm_fifo_base中，定义了两个analysis_port，负责将trans，广播出去；
两个imp，分别实现，get，put，等等全部的interface function接口；
tlm_fifo中，定义了mailbox，可以在fifo new的时候，显式指定fifo的深度；默认1
具体实现put，get等函数；(实现并不像parent中的那样具体)；单纯写入mailbox，再用analysis port写出去；
tlm_analysis_fifo中，只是增加了一个analysis_imp，然后实现try_put；
tlm_fifo中的function，put操作，mailbox，put操作，然后通过put_ap的analysis再发出去；
get操作，mailbox，get操作，然后通过get_ap的analysis再发出去；
tlm_analysis_fifo中的function，只增加write函数；
tlm_fifo中的mailbox function：size，is_empty，is_full，used，flush，单纯的mailbox function；
tlm1中的绝大多数port，只支持一个参数，只有req或者rsp，不会同时有这两个。
但是transport或者master/slave类型的port，支持req和rsp的同时存在。
tlm_fifo，也只是支持一种req的mailbox的存在，
req_rsp_channel，支持req和rsp的同时存在，因为其中定义了两个mailbox，
在实际使用中，声明，port，export的声明，需要指定一种req，作为参数；
imp的声明，需要指定一种req参数，还必须将parent的type 也传进来；
new函数，port、export需要指定parent，需要solve_binding；
imp需要指定parent，因为需要调用parent的function；
connect函数，需要在各个port都例化之后，在进行连接，因为port中的imp_list需要的是一个object；
所以，目前connect函数，都被放在connect phase；
