UVM入门与进阶学习笔记1——UVM概述、类库地图、工厂机制、覆盖方法

最新推荐文章于 2026-05-10 12:36:51 发布

原创

最新推荐文章于 2026-05-10 12:36:51 发布 · 1.2w 阅读

181

标签

#测试用例 #测试覆盖率 #功能测试

验证方法学概述

UVM的优势

UVM融合其他验证方法学的积极意义在于，打通了各个EDA公司和IC设计公司的验证技能通道，便于验证技术交流和人才流动，也方便IC设计公司的技术及工具选择。用户不再受限于使用何种仿真器、使用哪一家的验证IP，而只需要将主要精力着眼于设计的功能验证，由此也提升了验证效率。
SV核心特性包括面向对象、随机约束、线程通信、功能覆盖率收集等，这些特性也为建立一个验证环境提供足够多的便利。
UVM验证方法学通过吸取eRM（Specman/e验证方法学），AVM，OVM，UVM等不同方法学的优点，可谓集众家之所长。其思想并非必须要与某种语言绑定。
所有验证方法学服务目的都在于提供一些可重用的类减轻在项目之间水平复用和垂直复用的工作量，同时对验证新人能提供一套可靠的框架，摆脱搭建房子构思图纸的苦恼。
UVM面向所有数字设计，涵盖从模块级到芯片级，ASIC到FPGA，控制逻辑、数据通路到处理器验证的全部场景。
UVM中Universal的含义代表该方法学可适用于大多数验证项目，而它自身提供的基础类库(basic class library)和基本验证结构可以让具有不同软件编程经验的验证人员能够快速构建起一个结构可靠的验证框架。
UVM自定义的框架构建类和测试类能够减轻环境构建的负担，进而将更多的精力集中在如何制定验证计划和创建测试场景。
UVM框架，包括UVM的类库和核心机制、核心UVM组件和层次构建方式、常见UVM组件间的通信方式、UVM测试场景的构成、UVM寄存器模型应用。

类库地图

SV模块中验证环境整体的构建，是从底层模块验证组件搭建到通信和激励生成，这些元素无论是软件对象的创建、访问、修改、配置，还是组件之间的通信等都通过用户自定义的方式实现的。

UVM的初衷是将验证过程中可复用和标准化的部分都规定在其方法学的类库中，通过标准化的方式减轻构建环境的负担。

对验证环境的共同需求：（划重点）

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

UVM核心类库

由于软件环境中对象的生成是动态的，验证环境的组件也需要UVM提供底层功能完成对象的创建和访问。
UVM需提供环境上下层次中创建、连接和运行组件的顺序控制方法，只有在底层机制上有效地保证这一点，才会避免可能发生的句柄悬空问题。
组件通信中，UVM提供功能更丰富的TLM(Transaction level model)接口，可以保证相邻组件的通信不再通过显式句柄引用，而是独立于组件的通信方式。
对于测试序列(sequence)的生成和传输也是利用了TLM传输在sequence和driver之间完成。对于不同sequence的发送顺序控制，需要实现sequence之间的灵活调度。
为了便于验证环境的调试，UVM的报告机制可将来自不同组件、不同级别的信息并且加以过滤，最终生成测试报告。
核心基类提供最底层的支持，包括一些基本方法例如拷贝、创建、比较和打印。在核心类之上发展了支持UVM特性的各个相关的类群。
工厂类提供注册环境组件、创建组件和覆盖组件类型的方法。
事务类和序列类用来规定在TLM(Transaction Level Model)传输管道中的数据类型和数据生成方式。
环境组件类是构成验证结构的主要部分，组件之间的嵌套关系通过层层例化和连接形成结构层次关系。
事务接口类和通信管道类共同实现组件之间的通信和存储。
线程同步类要比SV自身的同步方法更方便，同步时包含的信息更多。
信息报告类使得从UVM环境中报告的信息一致规范化，便于整体的控制和过滤。
寄存器模型类用来完成对寄存器和存储的建模、访问和验证。

工厂机制

三核心要素：注册uvm_{component, object}_utils、创建uvm_{component, object}::type_id::create()和覆盖set_{type,inst}_override{_by_type}

工厂的意义：

工厂机制也是软件的一种典型设计模式，是为了更方便替换验证环境中的实例或注册了的类型，同时工厂的注册机制也带来了配置的灵活性。
实例或类型替代，在UVM中称为覆盖，而被用来替换的对象或类型，应满足注册和多态的要求。
UVM的验证环境构成可分为：一部分构成环境的层次，这部分代码通过uvm_component类完成；另一部分构成环境的属性和数据传输，通过uvm_object类完成。
uvm_component类继承于uvm_object类，这两种类也是进出工厂的主要模具和生产对象。
可以利用工厂通过注册完成对象创建；之所以对象由工厂生产，是利用工厂生产模具可灵活替代的好处，使得在不修改原有验证环境层次和验证包的同时，实现对环境内部组件类型或对象的覆盖。

验证环境的不动产：generator、stimulator、monitor、agent、checker/reference model、environment、test，这些组件在uvm_component的子类中均有对应的组件。

非固定资产即TLM transaction，从generator流向stimulator的数据包，这些类统一由uvm_object表示。

uvm_{component, object}的例化：

每个uvm_{component, object}例化时都应给予一个名字(string)；
“full name”指的是component所处的完整层次结构；
在每个层次中例化的组件名称应独一无二。

创建component或object的方法：

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

module object_create;
import uvm_pkg::*;
`include "uvm_macros.svh"

最低0.47元/天解锁文章