UVM学习笔记

UVM学习笔记

一、类库地图

1、来源：

将验证过程中可以重用和标准化的部分都规定在其方法学的类库中。

2、对验证环境的共同需求：

• 组件的创建和访问；
• 环境的结构创建、组件之间的连接和运行；
• 不同阶段的顺序安排；
• 激励的生成、传递和控制；
• 测试报告机制。

3、类库地图

4、地图分类：

1. 核心基类：提供最低层的支持，包括复制、创建、比较和打印等一些基本方法；
2. 工厂（factory）类：提供注册环境组件、创建组件和覆盖组件类型方法；
3. 事务（transaction）和序列（sequence）类：规定在TLM传输管道中的数据类型和数据生成方式；
4. 结构创建（structure creation）类；
5. 环境组件（environment component）类：构成验证的主要部分；
6. 通信管道（channel）类；
7. 信息报告（message report）类；
8. 寄存器模型（register model）类；
9. 线程同步（thread synchronization）类；
10. 事务接口（transaction interface）类：与通信管道类共同实现组件之间的通信和存储。

二、工厂机制

1、工厂的意义：为了更方便的替换验证环境中的实例或者注册了的类型。

2、UVM验证环境一部分构成了环境的层次，通过uvm_component类完成；另一部分构成了环境的属性和数据传输，通过uvm_object类完成。

3、运用factory的步骤：

• 将类注册到工厂；
• 在例化前设置覆盖对象和类型；
• 对象创建。

4、uvm_coreservice_t类内置了UVM世界核心的组件和方法，主要包括：唯一的uvm_factory，用来注册、覆盖和例化；全局的report_server，用来做消息统筹和报告；全局的tr_database，用来记录transaction记录；get_root()方法用来返回当前UVM环境的结构顶层对象。

5、覆盖方法

6、确保正确覆盖的代码要求

7、UVM通过域的自动化，使得用户在注册UVM类的同时也可以声明今后会参与到对象复制、克隆、打印等操作的成员变量。

8、验证的不动产：generator、simulator、monitor、agent、checker/reference model、environment、test。非固定资产：TLM transaction、从generator流向stimulator的数据包。

9、创建component和object的方法：

comp_type::type_id::create(string name,uvm_component parent);

其中parent参数将整个UVM结构串接起来；

object_type::type_id::create(string name);

只能作为configuration或者transaction等用做传递的配置结构体或者抽象数据传输的数据结构体。

10、uvm_coreservice_t类，内置UVM世界核心的组件和方法，主要包括：

• 唯一的uvm_factory，用来注册、覆盖和例化；
• 全局的report_server，用来做消息统筹和报告；
• 全局的tb_database，用来记录transaction记录；
• get_root()方法用来返回当前UVM环境的结构顶层对象。

11、注册宏

• `uvm_{component,object}_utils

• 通过例化该类的对象来完成；

• 调用宏时只注册一次，放置到factory字典当中；

12、component/object配合工厂注册、创建和覆盖的方法：

create()、create_component()、get()、get_type_name()、set_inst_override()、set_type_override()

三、覆盖

1、覆盖机制可以将原来所属的类型替换为另一个新的类型，保证了原有代码的封装性。新的替换类型必须与被替换类型相兼容。

2、类型覆盖：UVM 层次结构下所有原有类型都会被覆盖类型所替换；

实例覆盖：在某些位置中原有的类型会被覆盖类型所替换。

3、覆盖方法：

static function void set_type_override(uvm_object_wrepper override_type,bit replace=1);

其中override_type是注册后的某一个类在工厂中注册的句柄，使用new_type::get_type()找到。

static function void set inst_override(uvm_object_wrapper override_type,string inst_path,uvm_component parent=null);

其中inst_path表示组件结构的路径字符串。

4、comp2覆盖了comp1类型：

comp1::type_id::set_type_override(comp2::get_type());

5、factory的三个核心要素：注册、创建和覆盖：

`uvm_{component,object}_utils
uvm_{component,object}::type_id::create()
set_{type,inst}_override{,_by_type}()

四、核心基类（uvm_object）

1、核心方法：

copy、clone、compare、print、pack/unpack。

2、域的自动化（field automation）：

用户在注册UVM类的同时也可以申明今后会参与到对象拷贝、克隆、打印等操作的成员变量。使用`uvm_{component,object}_utils_begin和`uvm_{component,object}_utils_end来配对包裹接下来的域的自动化。

3、Copy和clone：

前者默认已经创建好了对象，只需要对数据进行拷贝；后者则会自动创建对象并对source object进行数据拷贝，再返回target object句柄。

4、比较（compare）：

function bit compare (uvm_object rhs,uvm_comparer comparer=null);

5、全局对象：

uvm_default_comparer、uvm_default_printer、uvm_default_packer。

6、打印（print）：

• uvm_dafault_tree_printer：可以将对象按树状结构打印；
• uvm_dafault_line_printer：可以将对象数据打印到一行上面；
• uvm_dafault_table_printer：可以将对象按表格的方式打印；
• uvm_dafault_printer：UVM默认的打印设计，指向uvm_dafault_table_printer。

五、phase机制

1、用途：可以很清晰地将UVM仿真阶段层次化。

phase	函数/任务	执行顺序	功能	典型应用
build	函数	自顶向下	创建和配置测试平台的结构	创建组件和寄存器模型，设置或获取配置
connect	函数	自底向上	建立组件之间的连接	连接TLM/TLM2的端口，连接寄存器模型和adapter
end_of_elaboration	函数	自底向上	测试环境的微调	显示环境结构，打开文件，为组件添加额外配置
end_of_simulation	函数	自底向上	准备测试环境的仿真	显示环境结构，设置断点，设置初始运行的配置值
run	任务	自底向上	激励设计	提供激励、采集数据和比较数据，与OVM兼容
extract	函数	自底向上	从测试环境中收集数据	从测试平台提取剩余数据，从设计观察最终状态
check	函数	自底向上	检查任何不期望的行为	检查不期望的数据
report	函数	自底向上	报告测试结果	报告测试结果，将结果写入到文件中
final	函数	自底向上	完成测试活动，结束仿真	关闭文件，结束联合仿真引擎

2、常用的phase包括build、connect、run、report，分别完成组件的建立、连接、运行和报告。

3、run_phase中，用户如果要完成测试，通常需要组织以下激励序列：上电、复位、寄存器配置、发送主要的测试内容、等待DUT完成测试。

4、

5、uvm_top承担的核心职责：

• 通过创建组件时指定parent来构建层次；
• 若parent为null，那它将作为uvm_top的子组件；
• Phase控制，控制所有组件的phase顺序；
• 索引功能，通过层次名称来索引组件实例；
• 报告配置，通过uvm_top来全局配置报告的繁简度；
• 全局报告配置。

6、通过uvm_top调用方法run_test（test_name），uvm_top做了如下初始化：

• 得到正确的test_name；
• 初始化objection机制；
• 创建uvm_test_top实例；
• 调用phase控制方法，安排所有组件的phase方法执行顺序；
• 等待所有phase执行结束，关闭phase控制进程；
• 报告总结和结束仿真。

六、config机制

1、便利性：在仿真中可以通过变量设置来修改环境。通过外部的参数配置，使得环境在创建时可以根据不同参数来选择创建的组件类型、组件实例数目、组件之间的连接以及组件的运行模式。

2、常见的uvm_config_db类使用方式：

• 传递virtual interface到环境中；
• 设置单一变量值，例如int、string、enum等；
• 传递配置对象（config object）到环境。

例如：

uvm_config_db#(T)::set(uvm_component cntxt, string isnt_name, string field_name, T value);
uvm_config_db#(T)::gett(uvm_component cntxt,string isnt_name, string field_name, inout T value);

3、interface传递：解决了连接硬件世界和软件世界。uvm_config_db使得接口的传递和获取彻底分离开来。

七、消息管理

1、消息的处理方式是同消息的严重级别对应的。

处理方式	说明
NO_ACTION	不做任何处理
UVM_DISPLAY	将消息输出到标准输出端口
UVM_LOG	将消息写入到文件中
UVM_COUNT	增加退出计数变量quit_count，当quit_count达到一定数值时停止仿真
UVM_EXIT	立刻退出仿真
UVM_CALL_HOOK	调用对应的回调函数
UVM_STOP	停止仿真

而不同的严重级别消息，用户可以使用默认的消息处理方式

严重级别	默认处理方式
UVM_INFO	UVM_DISPLAY
UVM_WARING	UVM_DISPLAY
UVM_ERROR	UVM_DISPLAY|UVM_COUNT
UVM_FATAL	UVM_DISPLAY|UVM_EXIT

2、四个消息函数有若干共同信息：严重级别（severity）、冗余度（verbosity）、消息ID、消息、文件名和行号。

3、回调函数：用户在调用回调函数时，首先会调用report_hook()函数，接下来才按照severity级别选择更细致的回调函数report_SEVERITY_hook()。

八、组件家族

1、uvm_driver类定义：

class uvm_driver #(type REQ = uvm_sequence_item, type RSP = REQ) extends uvm_component;

该类会从uvm_sequencer中获取事务（transaction），经过转化进而在接口中对DUT进行时序激励。

2、uvm_monitor：该类为了监测接口数据，任何需要用户自定义的数据监测行为的monitor 都应该继承与该类。

3、该类执行的功能包括：

1. 观测DUT的interface，并且收集总线信息；

2. 永远保持PASSIVE模式，永远不会驱动DUT；

3. 在总线协议或者内部信号协议观察时，可以做一些功能和时序的检查；

4. 对于更加复杂的检查要求，它可以将数据发送至其他验证组件。

4、uvm_sequencer：如同一个管道，从这个管道中会产生连续的激励事务，并最终通过TLM端口送至driver一侧。也可从uvm_driver那获得随后的RSP对象来得知数据通信是否正常。

5、sequencer既管理sequence，同时也将sequence中产生的transaction item传送到driver一侧。

6、uvm_agent：一个标准的验证环境单位，通常包含driver、monitor、sequencer。按总线传输方向agent可分为master和slave，master agent用来向DUT发起transaction，slave agent用来响应events。

7、is_active是agent的一个成员，缺省值是UVM_ACTIVE。

8、uvm_scoreboard：接收来自多个monitor的检测数据，继而进行对比和报告。

9、uvm_env：包含多个uvm_agent和其它component。uvm_env为结构化容器，可以容纳其他组件，同时也可作为子环境在更高层的集成中被嵌入。

10、uvm_test:决定环境的结构和连接关系和使用哪一个测试程序，只有通过它才能正常运转UVM的phase机制。