1:uvm_object 是UVM中最基本的类,几乎所有的类都继承自uvm_object包括uvm_component。
2:uvm_component有两大特性是uvm_object所没有的,一是通过在new的时候指定parent参数来形成一种树形的组织结构,二是有phase的自动执行特点。
3:UVM树的结点都是由uvm_component组成的,只有基于uvm_component派生的类才能成为UVM树的结点。UVM中常用类的继承关系
4:验证平台常用到派生自uvm_object的类有:uvm_sequence_item(所有的transaction要从这个类中派生);uvm_sequence(所有的sequence要从这个类派生);config(所有的config一般直接从uvm_object派生)。
5:验证平台常用的派生自uvm_component的类有:uvm_dirver(主要完成transaction的索要和transaction级别到DUT能够接受的端口级别信息的转换);uvm_monitor(从DUT的pin上接收数据,并将收到的数据转成transaction类型);uvm_sequencer(将sequence生成的transaction传递给driver);uvm_scoreboard(比较reference model和monitor的数据);reference model(完成和DUT一样的功能,一般由DPI等接口调用其他语言来完成相同的功能);uvm_agent(将相同协议的driver和monitor封装起来,便于重用);uvm_env(容器类,将固定不变的component封装在一起);uvm_test(所有的测试都要派生自uvm_test或其派生类);
6:与uvm_object相关的宏:uvm_object_utils(将一个直接或者间接派生自uvm_object的类注册到factory中);uvm_object_param_utils(将一个直接或者间接派生自uvm_object的参数化的类注册到factory中);uvm_object_utils_begin(transaction使用field_automation机制时需要用到此宏);uvm_object_param_utils_begin(类似);uvm_object_utils_end(与*begin*一起使用)。
7:与uvm_component相关的宏:uvm_component_utils(将一个直接或者间接派生自uvm_component的类注册到factory中);uvm_component_param_utils(类似);uvm_component_utils_begin(与object类似但主要不是为了使用copy,print等函数而是可以自动地使用config_db来得到某些变量的值);uvm_component_param_utils_begin(类似);uvm_component_utils_end(类似);
8:uvm_component的限制:理论上说uvm_component派生自uvm_object应该具有它的所有特征。但是uvm_component作为UVM树的结点存在让其失去了一些特性。像uvm_object可以使用clone函数,分配一块内存空间并把另外一个实例copy到这块新的内存空间,但uvm_component不支持(会导致parent无法指定)。另外位于同一父结点下的不同component,在实例化的时候不能使用相同的名字。
9:所有UVM树的结点本质上都是一个uvm_component。每个uvm_component都有一个特点,它们在new的时候,需要指定一个类型为uvm_component、名字是parent的变量(parent通常都是this)。
10:UVM真正的树根是一个称为uvm_top的东西,uvm_top是一个全局变量,它是uvm_root唯一的一个实例。uvm_test_top的parent是uvm_top,而uvm_top的parent则是null,所以uvm_top是真正的树根。uvm_root的存在可以保证整个验证平台只有一棵树,所有结点都是uvm_top的子节点。
11:可以通过调用层次相关函数,得到parent或children的信息。
12:filed automation机制(可以直接使用常用函数)有一系列的宏,分别用于整数、实数、枚举类型事件、字符串、动态数组、静态数组、队列和联合数组等变量的注册。
13:field automation机制常用的函数:copy(如果要将A实例复制到B实例中,应该使用B.copy(A).); pack_bytes (将所有字段打包成byte流) ;unpack_bytes(将byte流恢复到类的实例中);pack(打包成bit流);unpack(恢复bit流到实例中);pack_ints(将所有字段打包成int);unpack_ints (类似);print(打印所有字段);clone(申请内存并复制);除此之外field automation机制还用于自动得到config_db::set设置的参数。
14:field automation机制可以通过设置每个字段的标志位来选择copy、compare、print、record、pack的时候是否对此字段进行操作,通常标志位是UVM_ALL_ON,即每个字段可以执行所有操作。
15:field automation 中的宏可以与if结合完成字段的选择性执行。
16:UVM通过设置冗余级别来提高仿真日志的可读性。UVM默认的冗余阈值时UVM_MEDIUM,所有低于等于UVM_MEDIUM的信息都会被打印出来。
17:可以通过阈值设置函数设置需要的阈值,也可以通过仿真指令设置。
18:信息打印的重要性可以被重载。UVM默认有四种信息的严重性:UVM_INFO,UVM_WARNING,UVM_ERROR,UVM_FATAL。这四种严重性可以互相重载,即可以把一个component里的UVM_WARNING 显示为UVM_ERROR。
19:UVM_FATAL会自动结束仿真,也可以设置当UVM_ERROR达到一定数量后结束仿真,而且还可以设置计数目标,即也可以把UVM_WARNING当作计数目标。
20: UVM的断点功能。即当程序执行到预先设置的断点处,停止仿真,进入交互模式,从而进行调试,使用UVM_STOP完成。
21:UVM可以将输出导入文档,默认情况下将输出到终端(显示器)。而且可以按照严重性,ID,结点等分类导入LOG。
22:可以通过get_full_name()函数获取不同component的路径,但是在显示路径时最顶层为uvm_test_top(并不会显示uvm_top的名字,即__top__)。
23:config_db的set和get函数一般是成对出现的,函数的第一个参数和第二个参数联合起来组成路径,而且第一个参数必须是一个uvm_component实例的指针,第二个参数是相对此实例的路径。第三个参数用于确认,即set和get的第三个参数必须一致。第四个参数表示要设置的变量。
24:get在特殊情况下可以省略:即同时满足变量使用field automation机制(uvm_field_int …)注册,组件使用uvm_component_utils宏注册和set的第三个参数必须与get函数中的变量名一致(即第四个参数)这三个条件。在build_phase中调用super.build_phase() 就可以省略build_phase中原有的get函数。
25:当发生跨层次的多重设置的时候,有效的优先级为权威优先(越靠近树根权威性越高),即当uvm_test和uvm_agent同时往driver里使用config_db设置变量的值,最后会是uvm_test里的值生效。如果权威性相同,则后设置的生效。
26:在使用set函数的时候第一个参数应该尽量使用this,如果无法使用this(如在top_tb中),使用null或者uvm_root::get()。
27:当同一层次的多重设置时,子类的设置生效。
28:config_db也可以非直线的设置和获取来避免冗余(不推荐),也可以使用通配符。
29:可以使用一些函数debug config_db,像check_config_usage()函数可以调试截至到调用函数时,哪些参数是被设置过但从未被获取过(可以debug字符串有没有写错)。也可以使用print_config()函数来遍历整个验证平台的结点。