文章目录

• 一、基础架构
• 1.1. 架构图一
• 1.2. 架构图二
• 1.3. 架构图三
• 二、组件家族
• 2.1. 各个组件关系
• 2.2. UVM树的建立

一、基础架构

1.1. 架构图一

?? 验证平台的作用就是确定待测设计（DUT）完全符合设计规格，通常将DUT放到一个验证平台中来实现，其经典架构如下：（Master agent为ACTIVE模式，Slave agent为PASSIVE模式）

?? 构成环境的组件都从uvm_component类继承而来，这是因为它们都从uvm_component类继承了phase机制，都会经历各个phase阶段。常见组件如下：

• uvm_sequencer：所有的sequencer都要派生自uvm_sequencer。
  ????? sequencer功能：组织管理sequence，driver申请数据时，它就把sequence生成的sequence_item发给driver。
• uvm_driver：所有的driver都要派生自uvm_driver。
  ?????driver功能：向sequencer申请sequence_item(数据包)，并将包里的信息按照总线协议规定驱动到DUT的端口上。
• uvm_monitor：所有的的monitor都要派生自uvm_monitor。
  ?????monitor功能：从DUT接收数据，并将其转成transaction级别的sequence_item，发送给scoreboard，供其比较。
• uvm_agent：所有的agent要派生自uvm_agent。
  ?????agent功能：将sequencer、driver和monitor封装在一起，agent模块的使用提高了代码的可重用性。
  ?????（UVM_ACTIVE/UVM_PASSIVE、两种模式）
• uvm_scoreboard：一般的scoreboard都要派生自uvm_scoreboard。
  ?????scoreboard功能：比较reference model和monitor分别发送来的数据，根据比较结果判断DUT是否正确工作。
• uvm_env：所有的env要派生自uvm_env。
  ?????env功能：将平台上的component组件封装在一起，实现一个环境多个用例。运行不同用例时，在其中实例化env即可。
• uvm_test：所有的测试用例要派生自uvm_test或其派生类。
  ?????任何一个派生的测试用例中，都要实例化env。这样，当用例运行时，才能把数据发给DUT，并接收DUT的数据。

1.2. 架构图二

扩展架构图：（Master agent和Slave agent都为UVM_ACTIVE模式）

??还有一个component比较重要reference model，UVM中并没有针对reference model定义一个类。所以通常来说，reference model都是直接派生自uvm_component。reference model的作用就是模仿DUT，完成与DUT相同的功能。DUT是用Verilog写成的时序电路，而reference model则可以直接使用SystemVerilog高级语言的特性，同时还可以通过DPI等接口调用其他语言来完成与DUT相同的功能。

1.3. 架构图三

??完整的复杂UVM架构图如下：

二、组件家族

2.1. 各个组件关系

??component与object是UVM中最基本的两个概念。

??uvm_object是UVM中最基本的类，几乎全部的类都是由uvm_object类派生出来，其中包含uvm_component。

??uvm_component有两大特性是uvm_object所不具备的。一是通过在new的时候必须要指定parent参数来产生一种树形的组织结构，二是具有phase的自动执行特点。所有的ＵＶＭ树的结点都是由uvm_component构成的，只有基于uvm_component派生出的类才有可能是ＵＶＭ树的结点。UVM中一些常见类的继承关系如图３所示。

2.2. UVM树的建立

??仿真过程中，首先执行的是 build_phase() ,该 phase 用于构建 uvm-tree 的结构，注意： uvm_component 组件类必须在 build_phase中实例化，也是这个原因，因为 build_phase() 的主要用途就是实例化组件类，构建 tree，典型的UVM树如下图；