UVM入门和进阶4：结构_顶层方案_环境元素

参考文档链接：https://verificationacademy.com/verification-methodology-reference/uvm/docs_1.2/html/

本节目录：

  • UVM结构回顾

  • MCDF顶层验证方案

  • 构建验证环境的内径

1 UVM结构回顾

1.1 uvm_top：（系统）

1
const uvm_root uvm_top = uvm_root::get()

uvm_top(uvm_root)，一个隐形的顶层，并不继承于object/component（因为要创建这些）

  • uvm_top 是uvm_root类的唯一实例，即是UVM为界的“一”
    • 它由UVM创建和管理
    • 它所在的域是uvm_pkg
  • uvm_top是所有test组件的顶层，即永远是我们环境的最顶层
    • 所有验证环境中的组件在创建时都需要指明它的父一级
    • 如果某些组件在创建时指定父一级的参数为“null”，那么它将直接隶属于uvm_top。不过这么做存在风险，也并不推荐
  • （主要作用）uvm_top提供一系列的方法来控制仿真，例如：九个phase机制、objection防止仿真退出机制（在run_phase中设置举手（尽量有且只有一个，防止退出避免额外协调，详情查看进阶2）等

金字塔结构

1.2 uvm_test：(自定义)

  • “test”类是用户自定义类的顶层结构

  • 所有的test类都应该继承于uvm_tes3，否则uvm_top将不识别，“后果很严重”一一无法启动test

  • （主要作用）test的目标包括：
    • 提供不同的配置，包括环境结构配置、测试模式配置等，然后再创建验证环境
    • 例化测试序列，并且挂载(attach)到目标sequencer,使其命令driver发送激励
    • 补充：所有变量都要放在test里面，方便管理与维护

为什么不放到env里面：test可以划分出静态与动态部分

1.3 构建验证环境的主要组件对比

主要由三类UVM构建模块（基类）共同组成验证环境

  • uvm_component
    • 继承于uvm_report_object （进一步继承于uvm_object）,提供消息方法
    • 所有的验证环境组件均继承于uvm_component
    • 管理验证环境的层次
  • uvm_env
    • 继承于 uvm_component
    • 没有额外的功能：如果拿到别人环境看到env，尽量少去动env而是去动test
    • 用来为验证环境结构提供一个容器（container）
  • uvm_test
    • 继承于 uvm_component
    • 没有额外的功能
    • 用来提供对uvm_env的额外配置以及挂载激励

1.4 uvm_component：是一个虚类不能例化，可以继承

1.4.1 介绍

一个虚类(virtual class),所有环境组件均继承于该类。所有继承于该类的子类，我们称之为组件或者环境组件

该类提供已下接口或者API：

  • 结构， 例如get_full_name(), get_parent(), get_num_children()
  • 阶段(phase)机制，例如build_phase(), connect_phase(), run_phase()
  • 配置(configuration)机制，例如print_config(), print_override_info()
  • 报告(report)机制，例如report_hook(), set_report_verbosity_level_hier ()
  • 事务记录(transaction recording),例如record，用的比较少模块三会讲
  • 工厂(factory)机制,例如set_inst_override(), set_type_override()

由于环境中所有的组件都继承于uvm_component，因此也就可以使得UVM提供统一的方式来管理层次结构和组件方法

1.4.2 构造函数：有关层次的说明

对于组件的构建函数，固定形式为：

1
function new(string name, uvm_component parent);
  • string name：用来声明当前例化组件的名称，用来自动和它所在的父一级层次组合为组件的整个层次名称，可以 get_full_name()方法获取
  • uvm_component parent：用来指示所例化的父一级句柄，通常用“this”来指代，即例化在当前的父一级组件中
  • 注意与uvm_object的构建函数new(string name)进行区分，由于uvm_object不参与组件的层次构建，因此它只有一个形参， 而没有 uvm_component parent
  • 凡是继承于uvm_component的组件，也应该保持同样的形式参 数列表

2 MCDF顶层验证方案

2.1 概述

在SV模块中，四位verifier需要给MCDF (Multiple Channel Data Formatter)搭建验证环境，进而利用这些模块验证组件在顶层可以完成集成复用

MCDF的主要功能是将输入端的三个通道数据，通过数据整形和过滤，最终输出

将MCD结构分为四个模块：

  • 上行数据的通道从端(Channel Slave)
  • 仲裁器(Arbiter)
  • 整形器(Formatter)
  • 控制寄存器(Control Registers)

2.2 子模块环境搭建方案

2.2.1 reg_env：对于寄存器的验证环境

对于寄存器模块的验证环境reg_env,它的组织包括：

  • reg_master_agent,提供寄存器接口驱动信号
  • reg_slave_agent,提供寄存器接口反馈信号
  • scoreboard,分另从reg_master_agent内的monitor和reg_slave_agent内 的monitor获取监测数据，并且进行数据比对
  • reg_master_agent：对reg配置包括addr，data_w/r，cmd
  • reg_slave_agent：
    • 驱动channel_fifo_avaible
    • 其他信号做监测

2.2.2 chnl_env：对channel

下图是验证一个channel

数据通道从端的验证环境chnLenv的组件包括：

  • chnl_master_agent,提供上行的激励数据
  • chnLslave.agent,提供用来模拟arbiter仲裁信号，并且接收流出数
    据
  • reg_cfg_agent,提供用来模拟寄存器的配置信号，并且接收内置
    FIFO的余量信号
  • scoreboard,分另ll从chnl_master_agent、chnl_slave_agent和reg_cfg_agent的monitor接受监测激据，并且对channel的流入流出 数据进行比对

2.3 arb_env

仲裁器的验证环境arb_env的组件包括：

  • 模拟channel输出接口的arbiter_master_agent的三个实例，用来对 arbiter提供并行数据输入，同时对arbiter反馈的仲裁信号做出响应
  • arbiter_slave_agent,用来接收arbiter的输出数据，模拟formatter 的行为，对arbiter的输出信号做出响应
  • reg_cfg_agent,提供用来模拟寄存器的配置信号，对三个channel 数据源分别做出不同的优先级配置
  • scoreboard,从三个arbiter_master_agent、arbiter_slave_agent 和reg_cfg_agent中的monitor获取监测数据，对arbiter的仲裁机制 做出预测，并且将输入输出数据按照预测的优先级做出比对

2.2.4 fmt_env

整形器的验证环境 fmt env 的组件包括：

  • fmt_master_agent， 用来模拟arbiter的输出数据
  • fmt_slave_agent ，用来模拟MCDF的下行数据接收端
  • reg _cfg _agent ，用来模拟寄存器的配置信号，用来指定输出数据包的长
  • scoreboard ，从 fmt master _agent 、 fmt_slave_agent 和 reg_cfg agent 的 monitor 获取数据监测数据，通过数据包长度来预测输出的数据包，与formatter输出的数据包进行比对

2.3 环境集成方案

两个方案没有谁好谁坏

2.3.1 方案1

基本就是我们SV的环境，除了vitrual sequencer我们后期学

MCDF顶层验证环境复用了这些模块验证环境的组件：

  • reg_master_agent
  • chnl_master_agent
  • fmt_slave_agent

通过这三个激励组件可以有效生成新的激励序列，而将各个agent的 sequencer句柄合并在一处时，virtual sequencer的作用就体现出来了

我们可以通过这个中心化的序列分发管道，将各个agent的sequence也集中管理

MCDF的scoreboard提供了一个完整的数据通路覆盖方案，即从各个 agent的monitor数据监测端口将数据收集起来，同时建立MCDF的参 考模型，预测输出数据包，最终进行数据比对

集成代码

sqr作用就是传递trans

virtual_sequencer拿着各个agent_sequencer句柄，相当于句柄的路由，进行中间的管理作用

2.3.2 方案2

较为复杂一点，组件更多，多了cfg

  • 可以把例如：agent.slave配置成passive，agent.master配置成active

  • 好处：

    • 子系统出问题agent.sb仍然可以工作
    • 独立性好，别人的拿过来直接可以用，做之前进行cfg就可以
    • （可选）方案二大多数情况下还是需要一个顶层的sb检查，针对性检查（use case）

为什么arbiter也要放进来，因为可以单独检查arbiter

集成代码

2.3.3 方案对比

方案一与方案二相同的地方在于，顶层都需要新建 virtual sequencer 和 virtual sequence ，用来生成顶层的测试序列

而 virtual sequence也不是从零创建的，它本身也是利用原有模块环了有机的组合，最后协调生成了新的测试序列

从方案二可以看出， mcdfenv的子组件不再是uvm agent类，而是各个模块的验证环境 uvm _ env 类

通过直接复用这些子环境，我们也间接复用了它们内部的 score board。在 build 阶段，我们需要将各个子环境中不需要再产生激励的 agent , 配置为 passive 模式，而默认情况 下这些 agent 均为 active 模式

这种复用方式使得我们无需再新建一个 MCDF scoreboard ，只需要确保 MCDF 的各个子模块均有 scoreboard 会检查功能，这样从整体上便可以覆盖完整的数据通路

方案一中最大的额外投入在于需要新建一个scoreboard用来检查MCDF的整体功能

如果顶层设计没那么复杂，重新实现一个顶层scoreboard其复杂度还是可控的；但是如果将来的顶层环境更加复杂，那么复用底层的scoreboard就变得省时省力了

方案二的目的在于复用底层模块环境的scoreboard,减少顶层环境的额外成本。方案二不同于方案一的有下列几个地方：

  • 顶层环境的组件都直接复用了各个模块验证环境
  • 顶层环境在集成模块验证环境时，需要将各个子模块中的agent配置为不同模式（ active或者passive） ,以此适应顶层场景
  • 不再需要实现新的scoreboard,而是可以复用原有模块验证环境的scoreboard

2.4 总结

从上面框图和代码中观察到，UVM带来的环境复用，相比于之前SV验 证环境做到了下面的几个优势：

  • 各个模块的验证环境是独立封装的，对外不需要保留数据端口，因此便于环境 的进一步集成复用
  • UVM自身的phase机制，在顶层协调各个子环境时，无需考虑由于子环境 之间的例化顺序而导致的对象句柄引用悬空的问题
  • 由于子环境的测试序列是相对独立的，这使得顶层在复用子环境测试序列而构 成virtual sequence时，不需要其它额外的迁移成本
  • UVM提供的config_db配置方式，使得整体环境的结构和运行模式都可以从树 状的config对象中获取，这也使得顶层环境可以在不同uvm_test进行集中管理配置

相比SV

数据接口：

  • 以前是用mailbox句柄

  • 现在使用端口

  • 为什么？
    • 使用mailbox会有跨层次问题

phase机制

子环境而是相对独立，具有sequence

config_db配置，使得结构和运行模式从树状config对象获取，对顶层环境再不同uvm_test进行集中管理

3 构建验证环境的内径

3.1 构建环境四要素

发送测试序列之前，首先需要创建一个结构化环境。将环境核心要素拆解开，分为四部分：

  • 单元组件的自闭性：完全的封装，不依赖其他组件，可以单独编译（非常重要）

  • 回归创建：type_id::create

  • 通信都那口连接
  • 顶层配置

ps：在构建环境时，可从这四点查找是否缺少了某个组件

3.2 四要素详细介绍

3.2.1 单元组件的自闭性

即以后你提供的env一定要独立

3.2.2 回归创建

SV：上一级的组件例化子一级的组件通过执行new()

UVM：通过build_phase

  • 保证了父级组件先于子级组件

补充两种配置方式：

  • config：build拿到后固化，即config只config一次
  • transaction：动态配置

3.2.3 通信端口连接

3.2.4 顶层配置（配置层次可参考本节叙述）

顶层环境的变量部分

使用config_db字符串而不是直接用句柄

如下放置到config_db数据库里面

子一级组件创建时拿出来

3.3 顶层配置结构

  • rgm：寄存器模型
  • scbd
  • topcfg：传递rgm句柄，is_active，变量值等配置信息

3.4 环境元素分类

uvm_test作为比uvm_env更高层次，将对test传递配置信息，包括构成环境的组件uvm_component在内环境元素可以分为以下部分：

  • 成员变量
    • 一般变量
    • 结构变量
    • 模式变量
  • 子组件
    • 固定组件
    • 条件组件
    • 引用组件
  • 子对象
    • 自生对象
    • 克隆对象
    • 引用对象

3.5 环境元素详细介绍

3.5.1 成员变量

  • 一般变量：内部操作与外部访问
  • 结构变量：内部子组件
  • 模式变量：控制组件行为

对u结构变量和模式变量使用int/enum进行定义

3.5.2 子组件

引用组件就是个句柄，有结构变量决定的组件叫结构组件

下图展示了谁是固定组件谁是引用组件

3.5.3 子对象

查看例如部分