UVM学习--基本概念篇1

1、什么是UVM?UVM具有什么优势？

UVM 是 Universal Verification Methodology 的缩写，即通用验证方法学。它起源于 OVM（Open Verification Methdology），是由 Cadence， Mentor 和 Synopsys 联合推出的新一代的验证方法学。主要优势：

三个EDA软件提供商共同支持。
通用的验证平台开发，贯穿于验证平台的可重用性。
第一种自动化方法和第二种自动化类库的集合。
不局限于特定的仿真器
提供一些可重用的类减轻复用工作量
支持CDV（覆盖率驱动）、CRV（受限随机）验证
支持寄存器模型

2、uvm_component和uvm_object之间有何区别？

首先，uvm_component派生自uvm_object，继承了uvm_object的特性并且拓展。主要区别如下：uvm_component：

在new时指定parent参数形成树形结构
具有phase自动执行的特点
准静态实体（从创建开始到仿真结束一直存在）
存在控制仿真行为的phase机制
始终连接到硬件或者TLM端口

uvm_object：

动态实体（需要时创建，不需要时销毁，相当于一个function）
不存在phase机制，不存在uvm拓扑结构中
不会连接到硬件或者TLM端口

3、UVM phase中top-down(自顶而下）、down-top（自底而上）以及并行执行的phase分别有哪些？

UVM中的phase绝大部分都是自底向上的，即从树叶到树根，只有两个phase是从树根到树叶的（自顶向下）。
build_phase方法自顶向下执行，以便在顶部(测试)设置的配置可以向下传播到各component中。final_phase方法是自顶向下执行的，以允许top test控制底层final_phase方法的功能。
run_phase和其他12个小phase是并行执行的，其他都是串行，后面12个小phase之间则是动态运行。

4、为什么build_phase是自顶而下而connect_phase是自底而上？

build_phase方法自顶向下执行，以便在顶部(测试)设置的配置可以向下传播到各component中。在build_phase中主要就是做实例化的工作，顶层实例化以后，一层层向下实例化才不会引发调用错误。connect_phase主要是连接各个component之间的传输问题，用于在组件之间建立TLM类型的连接，这就是它在构建阶段之后发生的原因。它自底而上工作，以便在设计层次结构中获得正确的实现。

5、UVM中的function phase和task phase分别有哪些？

除了run_phase和12个小phase是task phase，消耗仿真时间，其他都是function phase，不消耗仿真时间。

6、哪个phase花费了更多时间以及为什么？

run_phase作为task phase，是运行时间最长的phase，其他12个task phase的总时间和其相等，而剩下的都是function phase。run_phase将从仿真（run）开始到仿真结束执行。run_phase非常耗时，测试用例产生激励正是在run_phase中实现。

7、UVM phase如何启动？
一般来说有两种启动方式，一种是在顶层模块的run_test()中添加测试用例名，一种是在命令行中指定测试用例。例如+UVM_TESTNAME =test1将启动测试用例名为test1的测试用例。

8、模块和基于class的testbench的区别有哪些？模块是仿真期间始终存在的静态对象。
class是一个动态对象，因为它们可以在仿真的生命周期中销毁。特别指出：interface是静态对象，因此只能用于top、模块等静态对象中，driver为动态的对象类，因此driver等类中使用的为virtual interface，通过虚指针指向实际的interface。

9、什么是uvm_config_db？uvm_config_db和uvm_resource_db之间有什么区别?

uvm_config_db是一个参数化类，用于将不同类型的参数配置到uvm数据库中，使得它可以被任何较低级别层次结构中的组件使用，在仿真中通过变量设置修改环境。uvm_resource_db虽然也是一种用来共享数据的类，但是层次关系在其类中没有作用。与uvm_config_db相比，尽管uvm_resource_db也有内建的数据库通过字符串或者类型来索引配置数据，但是一个缺点就是层次的缺失和因此带来的自顶向下的配置覆盖关系的缺失。

uvm_resource_db采取的是“last write wins”即对同一个配置，最后的写入有效；而uvm_config_db采取的是“parent wins”，它会首先按照层次采取最顶层的配置优先。
uvm_resource_db给人带来的困惑是，如果高层次和低层次都对同一个配置变量进行了写入，那么在build阶段，由于是采取top-down的执行顺序，低层次的配置写入发生在最后，反而会作为有效值写入。因此uvm_resouce_db无法实现层次化的覆盖，这就不利于集成和复用。
另外uvm_resource_db只需要scope字符串参数，同时上下文的set/read中的scope必须保持一致。对于较简单和透明的环境，这一要求并不难，但是对于复杂的和封装完善的环境，这就对用户提出了更高的要求。因为用户需要对底层环境的验证IP了解更多，得知它们采用的scope参数，才能在顶层做出正确的参数匹配才可以完成配置。

10、`uvm_component_utils()和`uvm_object_utils()的优势和区别是什么？

utils宏定义注册机制保证了object/components进行正确factory操作所需的基础结构。有两个宏的原因是factory设计模式固定了构造函数可以拥有的参数数量。从uvm_object派生的类具有带一个参数的构造函数，即字符串名称。从uvm_component派生的类有两个参数，必须指定一个string类型的名称和一个uvm_component父类。两个`uvm_ * utils宏插入代码，提供了factory模式create()方法，该方法将调用委托给uvm_object或uvm_component的构造函数。需要使用相应的宏，以便传递正确的构造函数参数。这意味着在扩展这些类时，为了能够使用UVM factory模式，无法添加额外的构造函数参数。

11、`uvm_do和`uvm_rand_send之间的区别是什么？

`uvm_do宏定义主要做了三件事：

创建一个实例
把实例进行随机化
随机化后的实例发送给sequencer

`uvm_rand_send需要创建实例的过程，其他是一样的，只是需要用户自己去创建一个sequence或者sequence item。

12、uvm_transaction和uvm_sequence_item之间的区别？

uvm_sequence_item派生自uvm_transaction，因此添加了额外的属性和方法，提供了更多的功能，我们自创的事务transaction全部都是派生自uvm_sequence_item而非uvm_transaction。uvm_sequence_item为sequencer和sequence提供了钩子，所以你可以使用sequence和sequencer生成事务，而uvm_transaction只提供do print和do record等基本方法。

13、用户是否可以自定义UVM中的phase？

可以，但是用到不多，除了UVM中可用的预定义uvm_phase之外，用户还可以选择将自己的phase添加到组件中。这通常通过扩展uvm_phase类和使用构造函数调用super.new来完成，new有三个参数：阶段任务或功能的名称、自上而下或自下而上的阶段、任务或功能。

14、new()和create之间的区别是什么？

为对象实例分配内存用new()方法。在UVM中使用create()方法可以从factory创建对象实例，这允许使用factory重载时将所需对象替换为不同类型的对象，而无需重新编码。一般来说，用的较多的是对object用new()方法，对component用create()方法，因为后者需要用到factory机制。

15、什么是objection机制?

UVM中的objection机制是允许组件之间的分层状态通信，这有助于决定验证结束的时间。

每个内置phase都有一个内置的objection机制，它为组件和对象提供了一种同步其测试活动的方法，并指示何时可以安全地结束phase，最终确定验证进程的结束。

组件或sequence将在活动开始时raise objection（提起异议），该活动必须在phase结束之前完成，因此将在该活动结束时drop objection（撤销异议）。一旦所有被raise的 objection都被drop，phase就会终止。

一般来说，我们选择在sequencer或者顶层中使用objection，其他地方一般不使用，而使用方法在UVM1.1和UVM1.2中有些许差别。

16、什么是TLM fifo？

简而言之，TLM FIFO是两个UVM组件之间的FIFO，最好是在Monitor和Scoreboard之间。Monitor继续发送DATA，它将存储在TLM FIFO中，Scoreboard可以在需要时从TLM FIFO获取数据。实际上就是包装好的类，隐藏了IMP，减少了函数等，容易上手。

17、什么是analysis_port?

analysis_port (uvm_tlm_analysis_port) 是一种特定类型的事务级端口，可以连接到零个，一个或多个analysis export，组件可以通过该端口调用在另一个组件中实现的方法。

uvm_analysis_port向所有uvm_analysis_imp中实现的方法广播一个值。

uvm_analysis_imp接收uvm_analysis_port广播的所有transaction。

uvm_analysis_export将较低级别的uvm_analysis_imp导出到其父类一级。

18、什么是UVM寄存器模型？为什么需要它？

在验证上下文中，寄存器模型（或寄存器抽象层）是一组类，用于模拟DUT中寄存器和存储器的存储器映射行为，以便于激励生成和功能检查（以及可选的功能覆盖的某些方面）。UVM提供了一组基类，可以扩展它们以实现全面的寄存器建模功能。本质是重新定义了验证平台与DUT的寄存器接口，使得验证人员更好的组织及配置寄存器，简化流程。

因为有了寄存器模型，可以在任意task phase中使用寄存器模型以前门或者后门访问的方式读取配置寄存器的值，可以在某些function phase中以后门访问的方式读取寄存器的值。