UVM学习整理——UVM整体介绍

目录

一、典型UVM验证平台介绍

1.1典型UVM验证平台的主要组成和基本功能

1.2UVM类库地图

1.3UVM常用类的继承关系

---

一、典型UVM验证平台介绍

1.1典型UVM验证平台的主要组成和基本功能

driver：向sequencer申请sequence_item(数据包transaction)，并将包里的信息按照总线协议规定驱动到DUT的端口上；

sequencer：组织管理sequence，driver申请数据时，它就把sequence生成的sequence_item发给driver；

scoreboard：比较reference model和monitor分别发送来的数据，根据比较结果判断DUT是否正确工作；

monitor：从DUT接收数据，并将其转成transaction级别的sequence_item，发送给scoreboard，供其比较；

reference model：模仿DUT，完成与DUT相同的功能，为scoreboard提供判断标准；

agent：将sequencer、driver和monitor封装在一起（UVM_ACTIVE/UVM_PASSIVE、两种模式），agent模块的使用提高了代码的可重用性；

env：将平台上的component组件封装在一起，并配置各个组件间的通信端口，实现一个环境多个用例。运行不同用例时，在其中实例化env即可；

base_test（uvm_test_top）：例化和配置共同的组件和env，其他的test继承base_test，并进行针对性的修改；

sequence：（不属于验证平台的任一部分）产生激励内容（transaction）。通过sequence中的body任务创建（随机化）事务，并发送给sequence。

图 1 典型UVM验证平台

图 2 其他简单验证平台

UVM验证平台的优势：

1.（理念）UVM为验证工程师提供了一套完美的库文件，验证工程师只需要对这些库文件进行扩展即可建立自己的验证平台，此外UVM提供了一个标准的验证平台模板，节省构建平台结构的时间，可以把精力集中放在事物级建模以及结果的分析上。同时UVM也支持覆盖率驱动模式，根据当前覆盖率的情况，验证工程师决定下一步的验证内容。

2.（环境组件）UVM组件更加完善，引入了agent和sequence的概念，并将driver模块的功能更加细化，分工更加明确，降低组件间的关联性，提高验证平台的可移植性和复用性，同时各个模块的验证环境是独立封装的，对外不需要保留数据端口，便于环境的进一步集成复用；

3.（通信）UVM平台使用TLM（transaction level modeling事务级建模)端口进行组件间的通信，相对于mailbox或者旗语的通信方式更为简便，同时降低组件之间的依赖性和通信频率，提高整体仿真效率；

4.（功能）uvm提供诸多机制可以方便的进行各种操作，比如实现factory机制（可以实现不改变原代码情况下实现对象的替换，比如替换driver来实现不同的驱动行为）、field_automation机制（可以直接调用UVM中的函数，无需自己定义）、phase机制（在顶层协调各个子环境时，无需考虑由于子环境之间的例化顺序导致的对象引用时句柄悬空的问题）等等，UVM平台还提供了寄存器模型，便于对DUT和reference model进行配置。

1.2UVM类库地图

按照UVM的核心机制将UVM常见类分块如下：

图 3 UVM常见类

1. 核心基类：提供最底层的支持，包括一些基本的方法，如复制、创建、比较和打印。在此基础上发展其他支持UVM特性的相关类群；
2. 工厂（factory）类：提供注册环境组件、创建组件和覆盖组件类型的方法；
3. 事务（transaction）和序列（sequence）类：规定在TLM传输管道中的数据类型和数据生成方式；
4. 结构创建（structure creation）类：为UVM层次结构提供支持，提供环境中上下层次组件的创建、连接和运行顺序，避免可能发生的句柄悬空引用问题。
5. 环境组件（environment component）类：是构成验证结构的主要部分，组件之间的嵌套关系通过层层例化和连接形成了结构层次关系；
6. 通信管道（channel）类：事务接口类和管道通信类共同实现了组件之间通信的存储；
7. 信息报告（message report）类：使UVM环境中的报告信息一致规范化，便于整体的控制和过滤。
8. 寄存器模型（register model）类：用来完成对寄存器和存储的建模、访问和验证。
9. 线程同步（thread synchronization）类：提供方便的同步方法，以及在同步时包含更多的信息；
10. 事务接口（transaction interface）类：实现了组件之间的通信。

1.3UVM常用类的继承关系

图 4 UVM中常用类的继承关系

UVM的验证环境构成可以分为两部分：一部分构成了环境的层次，这部分代码是通过uvm component完成；另外一部分构成了构成了环境的属性（例如配置）和数据传输，这一部分通过uvm object完成。两种类都是使用factory机制完成注册和实例化（type_name::type_id::create()），因此都可以使用factory机制中的一些功能（重载功能）。

常见的uvm_object类和uvm_component类两者的差别：

1.主要区别在验证平台中的生命周期不同，一般来说，有生命周期的类都是派生自uvm_object或uvm_object的派生类;

2.在UVM中注册的宏不同：`uvm_object_utils和`uvm_component_utils;

3.uvm_component的特性：uvm_component类在例化时通过指定parent参数形成树形组织结构，更好的管理验证平台；uvm_component具有phase机制的自动执行特点。

4.uvm_component的限制：uvm_component是从uvm_object派生的。但是uvm_component作为UVM的树节点，使它失去了uvm_object的某些特性。

主要限制：

限制一：uvm_component无法使用clone函数（可用copy，因为调用copy之前，目标实例已例化，parent已定）（clone出来的新class，其parent无法指定），uvm_object有clone函数，用于分配一块内存空间，并把另一个实例复制到新的内存空间，即clone = new + copy（使用copy 前，目标句柄必须已经用new（此时指定parent）分配好了内存空间。clone时，目标实例可以只是一个空指针，因为clone会分配内存）。

限制二：位于同一父节点下的不同components，实例化时不能使用相同的名字。

限制三：uvm_component组件类必须在build_phase中实例化，uvm_object的实例化可以在任何phase完成。