uvm实战-学习笔记

《UVM实战（卷1）》学习笔记
看了第1/2/3/4/5/6/8/9.1 这几个章节。

第一章是综述，第二章是一个具体的例子，学习笔记从第三章相关内容开始。

我个人觉得UVM重要的部分（特点的部分）：
1）factory机制（override config_db）
2）TLM传递
3）phase机制
4）sequence-sequencer 以及virtual seq/sqr
内容中的截图基本来自于 UVM源代码、书自带的例子和《uvm1.1应用指南及源代码分析》这个PDF里的。

需要结合书（《UVM实战（卷1）》第1版）来看这个笔记。

第3章 UVM基础
3.1 uvm_component和uvm_object
常用的类名字：
这个图是从作者张强的《uvm1.1应用指南及源代码分析》里截得，不如书上3.1.1里的图好。

uvm_sequencer也是代码里必须有的，所以我加了uvm_sequencer
uvm_void是一个空的虚类。

在src/base/uvm_misc.svh中定义：
红框的是我们搭testbench的时候用的比较多的基类。

常用的uvm_object派生类：
sequencer给driver的transaction要派生自uvm_sequence_item，不要派生自uvm_transaction
所有的sequence要派生自uvm_sequence或者uvm_sequence的派生类，可以理解为sequence是sequence_item的组合（集合）。

driver向sequencer索要item，sequencer 检查是否有sequence要发送item，当发现有item待发送时，就把这个item发给driver.
常用的uvm_component派生类：
所有的driver要派生自uvm_driver. driver用来把sequence_item中的信息驱动到DUT端口上，从transaction-level向signal-level的转换。

uvm_driver需要参数（REQ RSP），比uvm_component增加了几个成员。

重要的是seq_item_port和req/rsp. （src/comps/uvm_driver.svh）
monitor/scoreboard 派生自 uvm_monitor和uvm_scoreboard，但是uvm_monitor和uvm_scoreboard并没有在uvm_component基础上做扩展。

src/comps/uvm_monitor.svh
sequencer要派生自uvm_sequencer. sequencer做了很多扩展，但是如果我们自己写的sequencer里没有增加成员的话，可以直接写如下代码：
因为sequencer在agent中例化，所以一般写在agent类文件里。

reference_model派生自uvm_component.
agent要派生自uvm_agent. uvm_agent里多了一个is_active的成员。

一般根据这个active来决定是否实例化driver和sequencer. is_active变量的数值需要在env的build_phase里设置完成（可以直接设置，也可以用uvm_config_db#(int)::set）。

env要派生自uvm_env. uvm_env没有对uvm_component扩展。

src/comps/uvm_env.svh
所有的test都要派生自uvm_test或者它的派生类。

uvm_test也没扩展src/comps/uvm_test.svh
uvm_object和uvm_component的macro
macro非常重要，事关把这些类的对象注册到factory机制中去。

uvm_object macro
1）对于uvm_sequence_item就统一用(假设不用parameter)：
2）对于uvm_sequence，要加上
`uvm_object_utils(sequence 类名)
可能还需要`uvm_declare_p_sequencer(sequencer类名)的声明
uvm_component macro
对于driver monitor reference_model scoreboard sequencer case agent env这些
uvm_component派生类都要加上：
`uvm_component_utils(类名)
uvm_component里的成员也可以像uvm_object里成员一样，用field_automation机制。

field_automation机制：
对于uvm_object派生类来说，field_automation机制让对象自动有的copy compare print pack unpack等函数，简化了实现uvm_component派生类里一些function/task的工作量
对于uvm_component派生类来说，field_automation机制最重要的是可以在build_phase 中自动获取uvm_config_db#()::set()的数值（必须加super.build_phase(phase)）---- 也就是不用写 uvm_config_db#()::get()
注意： field_automation的macro的类型要和uvm_config_db的参数类型一致：
如下示例代码， field_int vs uvm_config_db#(bit[47:0]) 这个时候
super.build_phase()是不起作用的。

想要起作用的话，需要用
clone = new + copy 源代码中可以看到clone函数一上来会做一次create，然后调copy 函数
src/base/uvm_object.svh
3.2 UVM的树形结构
uvm_component的new/create要注意第一个参数是名字，第二个参数是parent指针。

UVM真正的树根是“uvm_top”. 根据上面这个树结构，可以看出一个个component的parent是什么。

uvm_top的parent是null。

当一个component在实例化的时候，如果parent 参数设成null，那么parent参数会被仿真器自动设置成uvm_root的实例uvm_top.
在6.6.1章节里也提到了，sequence在uvm_config_db#（）：：get（）的时候，第一个参数设成“null”，实际就是uvm_root::get() 3.5.1章节也提到了这个
层次结构函数：
get_parent() get_child(string name) 这两个分别获取parent指针和指定名字的child 指针。

get_children(ref uvm_component children[$]) 获取所有的child指针
get_num_children() 获取child个数
get_first_child(ref string name) get_next_child(ref string name) 获取child的名字（反映到string name上），返回值是0/1两种情况
应用参考代码如下（改动的2.5.2例子中的my_agent.sv）：
注意：上述代码是在connet_phase中实现的。

上述代码的打印结果如下：
my_agent's name is uvm_test_top.env.i_agt, parent's full path is uvm_test_top.env, children num is 3
uvm_test_top.env.i_agt 0 child: drv --> full
path:uvm_test_top.env.i_agt.drv
uvm_test_top.env.i_agt 1 child: mon --> full
path:uvm_test_top.env.i_agt.mon
uvm_test_top.env.i_agt 2 child: sqr --> full
path:uvm_test_top.env.i_agt.sqr
This should be i_agt. my_agent's name is uvm_test_top.env.i_agt
uvm_test_top.env.i_agt first child name is drv
uvm_test_top.env.i_agt next child name is mon
uvm_test_top.env.i_agt next child name is sqr
my_agent's name is uvm_test_top.env.o_agt, parent's full path is uvm_test_top.env, children num is 1
uvm_test_top.env.o_agt 0 child: mon --> full
path:uvm_test_top.env.o_agt.mon
UVM_WARNING
/tools/synopsys/vcs/G-2012.09/etc/uvm/src/base/uvm_component.svh(1846) @ 0: uvm_test_top.env.o_agt [NOCHILD] Component with name 'drv' is not a child of component 'uvm_test_top.env.o_agt'
This should be o_agt. my_agent's name is uvm_test_top.env.o_agt
uvm_test_top.env.o_agt first child name is mon
3.3 field automation 机制
注意数组类型的field macro比一般的要少real和event的macro. 一般的对于enum类型有3个参数，而数组的只有2个参数。

联合数组的macro比较多
常用函数需要注意 pack unpack pack_bytes unpack_bytes pack_ints unpack_ints 返回值都是bit个数。

field-automation标记位
17bit中 bit0→copy bit1→no_copy bit2→compare bit3→no_compare bit4→print
bit5→no_print bit6→record bit7→no_record bit8→pack bit9→no_pack
UVM_ALL_ON是‘b000000101010101
UVM_ALL_ON|UVM_NO_PACK 这样就会忽略掉pack bit
field-automation的macro可以和if结合起来，参考3.3.4的代码
这个is_vlan变量可以在sequence里约束成0或1，来实现vlan或非vlan
ps：我觉得这个地方代码其实写成像3.3.3里的有一个crc_error的rand bit的更合理一些。

然后crc_error是UVM_ALL_ON|UVM_NOPACK，而crc是UVM_ALL_ON
3.4 UVM打印信息控制
get_report_verbosity_level()
set_report_verbosity_level(UVM_HIGH) 只对当前调用的component起作用
set_report_verbosity_level_hier(UVM_HIGH) 对当前及下面所有的component起作用simv +UVM_VERBOSITY=UVM_HIGH 命令行方式 ------ 我觉得用这个就可以了
重载打印信息：
set_report_severity_override(UVM_WARNING,UVM_ERROR);
上述函数都是在connect_phase及后面的phase使用
设置UVM_ERROR到达一定数量结束仿真
set_report_max_quit_count(int) 设成0就是无论多少error都不退出
get_report_max_quit_count() 返回如果是0，说明无论多少error都不退出
设置在main_phase前调用。

simv +UVM_MAX_QUIT_COUNT=10
3.4.4 3.4.5 3.4.6 3.4.7 我觉得应该用不大到，就不做笔记了
3.5 config_db机制
uvm_config_db#(类型)::set/get(component指针,”…”,”变量名字”，para4)
都是4个参数：
第一个参数是一个component指针，如果是null的话，相当于uvm_root::get()
第二个参数是个路径字符串，第一和第二两个参数组和成一个完整的路径
第三个参数对于set、get要完全一致，是变量名字
set的para4是数值，get的para4是变量
component中的成员变量如果：
1）component用uvm_component_utils宏注册
2）变量用field-automation宏注册
3）component的build_phase函数里有super.build_phase(phase)
那么可以省略get语句
跨层次多重set的时候，看set的第一个参数，层级越高，优先级越高。

调用set的时候，第一个参数尽量使用this
同层次设置的时候是时间优先
非直线设置的时候注意第一和第二参数的使用，如果需要parent指针，则要用this.m_parent
config_db机制支持通配符，但是作者不推荐使用通配符。

但是在对sequence的成员set 的时候需要用通配符（6.6.1章节）。

使用如下函数调试 config_db
check_config_usage() print_config(1/0) 这两个函数在connect_phase函数中调
simv +UVM_CONFIG_DB_TRACE
注意：第二个参数设置错误不会报错！！------- config_db机制务必要注意参数的书写。

第4章 UVM中的TLM1.0通信
TLM 是Transaction Level Modeling缩写
这章要搞清楚 port export imp fifo以及几种操作function/task 和对应component中要实现的function/task
下面的箭头方向都是控制流的方向，不是数据流方向。

我觉得作为一个VMM用户会觉得TLM有点难理解，总想用VMM_CHANNEL去套，结果把自己搞晕。

像port等其实是调imp所在component的task/function.
我看UVM源代码里有一个uvm_seq_item_pull_port的class，它的基类是uvm_port_base. 在uvm_driver的成员seq_item_port就是这个类型的。

与它对应的是uvm_seq_item_pull_imp，uvm_sequencer的成员seq_item_export就是这种类型。

在my_agent.sv中会connect它们。

4.2端口互连
port是动作的发起者，export是动作接收者，但是需要以一个imp来结束。

可以port→export→imp port→port→imp 也可以port→imp export→imp
port→imp用的较多，port→port→imp可以用port指针赋值来实现port→port(4.3.2章节)
操作：
put get/peek transport, transport相当于一次put+一次get
peek和get的不同（4.3.4章节）: 使用uvm_tlm_analysis_fifo的时候，get任务会使fifo 中少一个transaction；而peek任务是fifo把transaction复制一份发出，内部缓存中的transaction不会减少。

----- 一般情况下peek完以后，还得调get。

上述操作都有阻塞和非阻塞之分。

port export imp的类型也有blocking和nonblocking 之分。

port/export/imp类型： put/get/peek/get_peek/transport blocking/nonblocking/不区分blocking-nonblocking之分
imp要多一个参数，除了声明transaction类型（或者REQ RSP类型）以外，还要声明实现这个接口的component
connect的一定是同类型的port/export/imp
TLM的关键在于“与imp对应的component中task/function的实现”。

get/peek/get_peek和put类似，上述task或function必须要实现，如果用不到就写个空函数（章节4.2.9）。

注意上述task或者function的参数。

put是一个transaction参数，get/peek是output 的transaction参数，transport是一个req参数一个output的rsq参数。

连接用connect函数实现，从名字就可以看出来，这个必须在connect_phase中调。

4.3通信方式
这节应该是本章重点。

实际使用中用analysis_port→analysis_imp 还是port→tlm_analysis_fifo←port 可以根据实际情况自己决定。

analysis_port(analysis_export)可以连接多个imp（一对多的通信）←→put和get 系列端口与相应imp的通信通常是一对一的（可以一对多，但是本书没有给出一对多的例子4.2.1章节有介绍）。

analysis_port(analysis_export)更像是一个广播
analysis_port(analysis_export)没有阻塞和非阻塞的概念。

它是一个广播，不等与它相连的其他端口的响应。

analysis_port（analysis_export）必须连的imp是analysis_imp. analysis_imp所在的component必须定义个write的function --------- 注意：是function 代码示例：4.3.1示例代码的analysis_port文件夹
component C和B的代码基本一致。

env的connect_phase函数里做connect：
component中有多个imp的时候，如何实现write函数？
4.3.2给的例子中，scoreboard有两个imp,分别从output_agent和reference-model 的analysis_port获取transaction，然后做compare. 这个时候需要用：`uvm_analysis_imp_decl(_标记) 这个macro，然后“write”函数变成“write_标记（）”函数，analysis_port所在component不用变，还是调write()函数即可。

代码示例如下：
使用macro声明
write函数变名字
analysis_port所在component实现不变。

使用uvm_analysis_fifo（uvm_tlm_analysis_fifo）, analysis_fifo的本质是一块缓
存+两个imp. 用fifo来实现 port→fifo←port
使用fifo最重要的是选好两端的port类型,然后根据选好的两端port类型，来选择fifo上要连接的imp/export fifo本身实现了write() put() get() peek()等一系列的function/task，在两端port所在的component中直接调就可以。

连接在fifo两端的都是port，所以connect函数的起点是两端。

4.3.3的示例代码：
可以看到env里声明的几个fifo都是connect_phase函数中connect函数括号里的参数。

i_agt.ap、o_agt.ap和mdl.ap是analysis_port
mdl.port、scb.exp_port和scb.act_port都是blocking_get_port
fifo上有很多export，但是这些export实际都是imp
src/tlm1/uvm_tlm_fifo_base.svh
上面连接的agt_mdl_fifo.analysis_export也是一个analysis_imp: 源代码中实现如下：
src/tlm1/uvm_tlm_fifos.svh
fifo是一个component，可以调一些函数来debug：
used() is_empty() is_full() flush()
fifo里缓存深度可以在new的时候用第三个参数设置。

问题：fifo的两端是不是一般就是 analysis_port和blocking_get_port ? ---- 感觉4.3.5章节开始一段文字描述是这个意思。

使用fifo还是imp自己来把握。

各有各的好处。

imp可以使用uvm_analysis_imp_decl(_标记)的macro，有时候会很方便。

而analysis_fifo可以用for循环来操作fifo数组，也可以带来代码的简洁。

imp不能在connect和new的时候用for循环。

第5章 UVM验证平台的运行
5.1 phase机制
所有的phase如下图：
中间绿色的是task phase,两头青色的是function phase
component的实例化是在build_phase中完成，object的实例化可以在任何phase完成。

function phase中除了build_phase都是“自下而上”的执行 ---- 这里的上下是指的树结构中的上下。

------- build_phase是“自上而下”
同层次的兄弟关系的component，build phase执行顺序是根据new时候name的字典序–5.1.3章节
对于叔侄关系的component，build phase执行顺序是深度优先。

例如前面UVM树中，“scb”和“i_agt.drv”，因为i_agt在scb前面，会执行完i_agt，然后drv\mon\sqr，然后o_agt,然后mon，然后才是scb。

所有component的同一个run time phase是同时开始的。

----- 也就是说会等其他component的上一个phase结束才开始当前phase。

super.build_phase(phase)一定要加，其他phase的super….可以不用加.
phase之间可以跳转。

例如在正常工作的时候，发生了的reset，那么应该是main_phase 跳转到reset_phase. 例如：5.1.7章节的示例代码
jump导致main_phase的objection没有被drop. ------ 仿真发现这里会有一个UVM WARINGING报出来，这个问题如何解决呢？---应该不用管它
simv +UVM_PHASE_TRACE可以调试phase
超时退出机制：
1）在test的build_phase里加上 uvm_top.set_timeout(500ns,0);
2）`define UVM_DEFAULT_TIMEOUT 500ns
3）simv +UVM_TIMEOUT=”500ns,YES”
控制objection的时机：
推荐在sequence里的body（）task中实现控制objection
5.2.2章节示例代码：
注意用 starting_phase的判断。

给main_phase设置drain_time。

所谓drain_time，就是main_phase结束之后经过drain_time时间以后再进入post_main_phase。

在test的main_phase task中使用set_drain_time函数：
objection的调试
simv +UVM_OBJECTION_TRACE
5.3章节介绍了domain，我觉得基本不会用这个吧？
第6章 UVM中的sequence
sequencer将sequence传递给driver. 引入sequence，带来的变化：
1）uvm_transaction的派生类变成uvm_sequence_item的派生类
2）需要sequencer
3）driver main_phase有变化
4）启动sequence（一般在case的build_phase中）
上述变化反映到代码中，如图 6.1.2章节的示例代码
下图中有两种方法实现my_sequencer
sequence的启动方式(3种)：
1）在case的main_phase中：注意要设置cseq的staring_phase。

我觉得书上6-5代码清单里有两个地方写的不合理，一个是start的参数应该是sqr的路径，另外是少了设置starting_phase
2）注意在case的build_phase中
3）更推荐用下面这种方式：
sequence被启动后，会自动执行sequence的body task（以及 pre_body mid_body post_body）
在同一个sequencer上可以启动多个sequence，因为启动了多个，所以不能设置default_sequnce了，需要用上面第一种方法来启动sequence. --------- 但是sequence 的嵌套可以解决这个问题（上层sequence做default_sequence 6.4章节）
sequence可以用uvm_do_pri uvm_do_pri_with等macro来设置优先级priority, 当一个sequencer上有多个sequence的时候，这个优先级就有意义了。

优先级就带来sequencer的仲裁算法。

默认的仲裁算法是SEQ_ARB_FIFO（杨哥遵循陷入先出顺序，不考虑优先级），所以设置优先级以后，需要改变仲裁算法。

在case的main_phase中调函数set_arbitration()
前面提到的“嵌套sequence”也可以像上面这样来设置仲裁算法。

sequencer的操作：
lock() grab() 获取独占权。

unlock() ungrab() 释放独占权
is_relevant() 设置sequence有效和无效。

返回值1 有效，返回值0无效
wait_for_relevant() 当sequencer发现启动的所有sequence都无效的时候，会自动调wat_for_relevant() task。

在wait_for_relevant() task中，必须使sequence无效的条件清除。

is_relevant() 和 wait_for_relevant() 如果需要的话，一般是成对重载。

6.3 sequence相关macro及实现
最重要的是uvm_do系列宏，尤其是在引入virtual sequencer以后uvm_do_on系列宏用的会很多。

`uvm_do_on_pri_with(SEQ_OR_ITEM,SEQR,PRIORITY,CONSTRAINTS) uvm_do系列macro 都是来源于这个最长的macro
除了uvm_do系列macro之外，还可以用uvm_create + uvm_send。

使用uvm_create + uvm_send的优势是可以在两个macro之间加一些赋值操作等，当然也可以把约束随机加在这里。

uvm_create是实例化transaction，uvm_send是把transaction发送出去。

uvm_rand_send uvm_rand_send_pri uvm_rand_send_with uvm_rand_send_pri_with与uvm_do 系列macro类似
start_item和finish_item 上述macro的实际实现函数-------- 我觉得我们代码里应该不会用这两个函数。

task pre_do(bit is_item)
function void mid_do(uvm_sequence_item this_item)
function void post_do(uvm_sequence_item this_item)
注意上述task/function的参数。

mid_do和post_do因为参数是基类对象，函数重载里可能需要做$cast.
6.4 sequence进阶应用
前面提到了uvm_do系列宏既可以用在uvm_sequence_item上也可以用于uvm_sequence，所以sequence可以嵌套。

sequence中可以有rand成员，并且可以把rand成员和transaction的rand成员约束起来。

通过上面的约束，上层sequence里可以约束下层sequence里transaction的成员：
sequence的参数代表了它的req和rsp的uvm_sequence_item派生类的类名。

如果需要发送不同uvm_sequence_item派生类的对象，那么需要把sequence、sequencer和driver参数声明成基类uvm_sequence_item。

由于是基类，所以在driver中seq_item_port.get_next_item(req)的时候要做$cast转换. 因为sequence默认参数就是uvm_sequence_item，所以不用写。

6.4.3示例代码：
driver中的cast操作
实际的testbench中，很可能会在sequencer里加入一些成员变量，一般这种情况下要declare p_sequencer这个指针。

用macro – uvm_declare_p_sequencer(sequencer类名) 在sequence中可以实现： 6.4.4章节示例
问题： p_sequencer的声明macro 是不是一直加着 ----直接写在base_sequence里比较好。

可以做一个base_sequence,需要p_sequencer的声明的话，写在base_sequence里，这样就不用每个sequence都声明p_sequencer指针了。

6.5 virtual sequence
virtual sequence (virtual sequencer)是特色。

如下图所示:
系统级环境里可能有多个env，带来了多个sequencer/sequence，这样在case里不好维护。

实现一个virtual sequencer，里面包括指向各个sequencer的指针；而virtual sequence 就像前面介绍的“sequence嵌套”一样实现。

由于virtual sequencer里有实际sequencer的指针，所以肯定不能用“typedef uvm_sequncer….”来实现。

同时，由于virtual sequencer有成员了，所以在virtual sequence里要declare p_sequencer,并且指向virtual sequencer.
base_test的connect_phase函数中，要把virtual sequencer里的成员赋值到各个env的sqr上。

---- 所以virtual sequencer和各个env是同级的
所谓“virtual”是说它本身不会发送transaction，所以virtual sequencer和virtual sequence都不用写transaction的参数（用了默认的参数）。

6.5.3章节示例代码
virtual sequence：声明p_sequencer指针，注意uvm_do_on的sequencer参数
virtual sequencer 声明指针
base_test 在connect_phase中连接sequencer
case：设置virtual sequencer的main_phase的default_sequence为virtual sequence.
前面提到了objection的控制在sequence的body task中实现。

现在引入了virtual sequence以后，objection的控制就移到顶层virtual sequence的body task中。

sequence中尽量不要用fork join_none，避免执行到endtask
虽然sequence不是component，但是也可以在sequence中使用uvm_config_db (类似于tp_tb中使用)。

在case中对sequence的成员用uvm_config_db#(类型)::set()的时候要注意： sequence 由于是一个object，它的名字可能不确定，所以这里一般用通配符。

而在sequence中get 的时候，则使用uvm_root::get()/或者null和get_full_name()，作为前两个参数。

6.6.1示例代码 set用通配符和get的路径参数
在sequence中可以对testbench中的component的成员使用uvm_config_db#(类型)::set()，同样因为路径的问题，第一个参数一般是null或者uvm_root::get()
书上还给了一个设置sequence自己的成员的例子，不知道有啥用….
6.6.3章节介绍了uvm_config_db的wait_modified task，参数只有3个，和get前三个一样。

6.7 response
sequence sequencer driver的参数有两个: req类型和rsp类型，默认情况下rsp和req一样的类型。

当sequence需要driver返回response的时候，就需要用到rsp了。

sequence中在uvm_do macro之后调get_reponse(rsp) task, 而在driver中增加的代码较多：
6.7.1章节示例代码
get_reponse和put_response对应。

注意driver中必须有set_id_info函数。

put_response可以省略：需要item_done函数带rsp参数： seq_item_port.item_done(rsp) ----- 但是当有多次rsp的时候，就不能这么用了。

多次的时候只能是调多次get_reponse 和put_response
get_response是一个阻塞的task，当sequence没有获取到driver返回的rsp的时候，会阻塞住sequence的body()，所以当driver不能及时返回rsp的时候，get_response←→put_response这个机制就有问题了。

UVM的解决方法是使用response_handler函数：
在pre_body()函数中use_reponse_handler() 打开这个功能，然后重载response_handler(uvm_sequence_item response)这个函数→一般需要$cast给sequence 中的rsp成员 . 而sequence的body task里就不用再调get_response了
6.7.3章节代码示例：
rsp和req的类型可以不同，这个时候注意sequence driver sequencer的参数
6.8 sequence library
sequence library是一系列sequence的结合。

uvm_sequence_library本身是uvm_sequence 的派生类。

实现sequence_library的时候要注意：
1）在new函数里要增加 init_sequence_library()函数
2）增加`uvm_sequence_library_utils(类名) 的macro
对于里面的sequence只需要增加一个macro： `uvm_add_to_seq_lib(sequence类名，sequence_library类名)
一个sequence可以加入到不同的sequence_library中
使用sequence_library可以有效简化Testcase，因为case中设置sqr的main_phased的default_sequence是sequence_library类名::type_id::get()
可以使用sequence_library_cfg来控制sequence_library里迭代次数、选择算法以及sequence的个数。

但是我觉得使用简化的方法更方便和直观（不用sequence_library_cfg 类，而是直接对sequence_library对象的成员赋值）：
6.8.4示例代码：在case的build_phase里实现，需要把sequence_library new出来
第8章 UVM中的factory机制
重点章节 uvm特色
UVM的factory机制也是建立在 systemverilog的Polymorphism机制上的，所以function\task也得是声明成virtual的才行。

使用factory重载的限制：
1）重载的类和被重载的类，都要在定义的是用uvm_*_util宏来注册
2）实例化的时候要用::type_id::create(“名字”)的方法 ------- 无论component还是object
3）重载的类是被重载的类的派生类
4）component和object之间不能重载
重载的方式和种类注意get_type() 在build_phase中调用
component中的函数：replace参数代表“是否可以被后面的重载覆盖”
set_type_override_by_type(原始类名::get_type()，重载类名::get_type(),replace) set_inst_override_by_type(相对路径字符串，原始类名::get_type()，重载类名::get_type())
也可以用类名字符串来代替原始类名::get_type()和重载类名::get_type()
set_type_override(原始类名字符串，重载类名字符串,replace)
set_inst_override(相对路径字符串，原始类名字符串，重载类名字符串)
直接使用factory这个全局变量的函数：
与上面的非常类似，只是把“相对路径字符串”变成“绝对路径字符串”，而且移到最后一个参数：
直接使用factory的函数可以放在simv命令里去
simv +uvm_set_inst_override=” my_monitor,new_monitor,uvm_test_top.env.o_agt.mon”
factory机制的调试：
在build_phase后面的phase中调
comp.print_override_info();
factory.debug_create_by_name();
factory.debug_create_byte_type();
factory.print();
uvm_root.print_topolofy();
可以重载 uvm_sequence_item uvm_sequence uvm_component. 都是在case的build_phase 中调，而且都是直接用factory的方法
第9章 UVM的代码重用
9.1 callback机制
只给callback机制做了笔记。

uvm的callback和vmm的差不多。

代码步骤如下：
1）先实现一个uvm_callback的派生类A,以及A的virtual task/function
2）typedef uvm_callback s#(my_driver,A) A_pool 注意s
3）在my_driver中注册callback: `uvm_register_cb(my)driver,A)
4）my_driver中使用 `uvm_do_callback s(my_driver,A,task()) 注意s
5）从A派生出一个实际用到的类 my_callback ，实现task
6）在case的connect_phase中实例化my_callback（假设是my_cb），并create它，然后A_pool::add(my_driver的路径指针，my_cb) -------- 因为my_driver是在main_phase 里调callback的，所以要在main_phase前面做这个工作
9.1.4章节示例代码：。