《UVM实战(卷1)》学习笔记

合集下载

UVM Lab Guide自学笔记——快速入门UVM

UVM Lab Guide自学笔记——快速入门UVMfrom Monchy(蒙奇)在2020年秋招前根据Synopsys的SystemVerilog Verification UVM1.1Lab Guide自学UVM验证，在此分享前两章详细的学习笔记，几乎是指南的中文翻译，大量的过程截图对初学者很友好。

（UVM Lab Guide是Synopsys给出的UVM官方入门指南，里面包涵源码和实验指导，可以在网上自行下载。

建议参考《UVM实战》（张强））1UVM Environment1学习目标创建一个简单的UVM测试环境嵌入报告消息编译测试环境运行仿真并观察结果将数据、sequencer和驱动程序类添加到环境编译并仿真环境以观察行为2实验准备UVM由一组编码准则以及一组基类和宏组成。

这组基类和宏可帮助你开发外观和感觉上一致的测试平台。

这套编码准则使您能够开发鲁棒且高度可重复使用的测试平台组件，从而减少了修改、维护验证基础架构的时间，并花费更多时间验证您的设计。

第一个实验将按照UVM编码准则，使用UVM基类和宏开始构建UVM验证环境的过程：UVM lab文件夹有3个目录：labs（实验文件夹，里面的程序待补充）、solutions（lab的参考代码）和rtl（被测试的rtl代码）。

3搭建UVM测试平台任务1.创建简单的UVM 测试文件test_collection.svSolution:`ifndef TEST_COLLECTION_SV `define TEST_COLLECTION_SV `include "router_env.sv"class test_base extends uvm_test;`uvm_component_utils(test_base)router_env env;function new(string name,uvm_component parent);super.new(name,parent);`uvm_info("TRACE",$sformatf("%m"),UVM_HIGH);endfunction:newvirtual function void build_phase(uvm_phase phase);super.build_phase(phase);`uvm_info("TRACE",$sformatf("%m"),UVM_HIGH);env =router_env::type_id::create("env",this);endfunction:build_phasevirtual function void start_of_simulation_phase(uvm_phase phase);super.start_of_simulation_phase(phase);`uvm_info("TRACE",$sformatf("%m"),UVM_HIGH);//Note:If you want to see the topology as a tree format try://uvm_top.print_topology(uvm_default_tree_printer);uvm_top.print_topology();factory.print();endfunction:start_of_simulation_phase endclass:test_base`endiftest.sv Solution:program automatic test;import uvm_pkg::*;`include "test_collection.sv"initial begin$timeformat(-9,1,"ns",10);run_test();end endprogram编译并仿真简单的UVM 测试平台：$vcs -sverilog -ntb_opts uvm-1.1test.sv 编译开关-ntb_opts 用于使能UVM$simv +UVM_TESTNAME=test_base 可以通过factory configuration 修改测试。

OVM自学笔记

1.Sequence 中的m_sequencer和p_sequencer两者都是sequencer的指针，默认情况下都指向由ovm_sequencer_base继承而来在factory中注册的那个sequencer。

区别是m_sequencer由ovm_sequencer_base保护，不可ovm_user来更改，而p_sequencer可由user通过`uvm_declare_p_sequencer(sequencer_name)来改变指向。

所以用户如果想从一个sequence得到sequencer的信息可指定p_sequencer的指向，之后通过p_sequencer.*的方式取得相应信息。

实例：（uvm实例ovm通用）`uvm_object_utils(seq_name)`uvm_declare_p_sequencer(sequencer_name)if you need to access the sequencer information (or any of it's hierarchy information) from a sequence.I believe m_sequencer should not be used as it is protected./forums/showthread.php?193-m_sequencer-vs-p_sequencer2.一个Sequence 中的执行顺序CREATED：The sequence has been allocated.PRE_BODY：The sequence is started and the pre_body task is being executed.BODY：The sequence is started and the body task is being executed.POST_BODY：The sequence is started and the post_body task is being executed.ENDED：The sequence has ended by the completion of the body task.STOPPED：The sequence has been forcibly ended by issuing a kill() on the sequence. FINISHED：The sequence is completely finished executing.3.OVM使仿真结束方法（1）global_stop_request：基于task的目标结束方式（2）ovm_test_done：object结束方式，当所有object dropped调用global_stop_request （3）kill or do_kill_all：强行结束，不推荐（4）timeout：超时结束，需要用set_global_timeout来设定超时时间详细内容参考OVM_Reference的P384.ovm_test_doneovm_test_done_objection的实例化class（global类），用来结束run phase。

UVM基础总结——基于《UVM实战》示例

UVM基础总结——基于《UVM实战》示例UVM（Universal Verification Methodology）是一种用于验证集成电路设计和系统级设计的方法学。

它提供了一种强大的框架，可以加速和规范验证过程，提高设计的质量和效率。

在《UVM实战》这本书中，通过讲解一系列示例，向读者介绍了UVM的基础知识和使用方法。

本书首先介绍了UVM的基本概念和工作原理。

UVM使用一种基于对象和类的面向对象方法来描述和组织验证环境。

它将验证环境划分为几个层次，包括顶层、环境、代理、驱动器、监视器等。

每个层次都包含不同的类和方法，用于实现不同的功能。

通过继承和实例化这些类，可以快速构建一个完整的验证环境。

接下来，本书介绍了UVM中的一些重要概念和方法。

例如，本书详细讲解了UVM的组件和接口。

组件是UVM中最基本的单元，用于实现特定的功能。

接口定义了组件之间的通信和数据交换方式。

UVM使用一种称为TLM（Transaction Level Modeling）的方法来进行通信，通过事务的方式传递数据。

本书还介绍了UVM中的一些重要机制，例如配置和工厂。

配置机制用于配置和管理验证环境中的各个组件和接口的参数。

它可以实现灵活的参数化配置，以适应不同的测试需求。

工厂机制用于管理对象的创建和销毁。

通过注册和继承，可以快速生成对象，并实现对象的多态。

本书还详细介绍了UVM中的测试用例和事务。

测试用例是验证环境中的最高层次，用于描述和控制验证过程。

测试用例可以包括多个事务，每个事务描述一个特定的操作或数据传输过程。

通过编写测试用例和事务，可以实现不同的功能和覆盖率要求。

最后，本书还介绍了一些高级的UVM特性和技术。

例如，本书介绍了UVM中的随机性和约束，用于实现随机的测试用例和事务。

本书还介绍了UVM中的一些重用机制，例如组件和测试用例的复用，以提高测试效率和质量。

通过《UVM实战》这本书的学习，我深入了解了UVM的基础知识和使用方法。

UVM实战指南范文

UVM实战指南范文UVM（Universal Verification Methodology）是一种基于SystemVerilog语言的验证方法学，广泛应用于硬件验证领域。

在UVM中，通过建立一个可重复使用的测试环境，结合使用事务级建模（TLM）和事务级验收测试（TLM），实现了分层、模块化的测试方法，提高了验证效率和可复用性。

一、UVM基础知识1.UVM组成：UVM主要由以下几个组成部分组成：- testbench：测试平台，包括环境、测试、配置和结果收集。

- environment：包含需要被验证的设计和其他组件，如计时模型（TLM）和监控器。

- agent：代理，用于管理测试和设计之间的数据传输和控制通信。

- sequence：序列，用于控制测试向设计发送输入和观察输出。

- driver：驱动器，控制从测试平台发送数据到设计。

- monitor：监控器，从设计中监听信号和寄存器的值。

- scoreboard：比分板，用于比较设计的输出和期望的输出。

2. UVM中的消息系统：UVM中的消息系统可以用于在验证过程中传递和显示消息信息。

消息分为几个级别，如UVM_DEBUG、UVM_INFO、UVM_WARNING和UVM_ERROR等。

通过设置消息级别，可以控制消息的显示和记录。

在UVM中，可以使用`uvm_info(`,`uvm_warning(`,`uvm_error(`等函数来生成和发送消息。

二、UVM测试环境构建1.UVM测试环境构建：UVM测试环境的构建遵循一个分层、模块化的方法。

首先，可以定义一个基础环境，包含全局配置和全局测试。

然后，可以在基础环境的基础上构建更高级的环境，如顶层环境和模块环境。

在每个环境中，可以定义组件（如代理、序列和监控器）和接口，然后进行连接。

三、UVM测试流程1.UVM测试配置：首先，可以使用UVM配置对象来指定测试的配置选项，如时钟频率和寄存器的初始值。

uvm 基础知识

uvm 基础知识UVM是一种基于SystemVerilog语言的硬件验证方法学，它为验证工程师提供了一套验证环境和方法，帮助他们设计和开发复杂的硬件验证测试台。

以下为UVM的基础知识：1. UVM环境：UVM环境由各种组件组成，包括顶层测试环境，验证IP，驱动（driver），监控（monitor），事务（transaction），序列（sequence）和配置参数等。

2. UVM顶层测试环境：UVM顶层测试环境是UVM环境的主体，它实例化和连接各种验证组件，管理验证过程和数据路径。

3. 驱动（Driver）：驱动是UVM环境的一个组件，负责将测试向硬件发送数据。

它接收事务（transaction）并将其转换为物理信号发送到被测设备。

4. 监控（Monitor）：监控是UVM环境的一个组件，用于监听硬件信号并将其转换为事务（transaction）。

它将被测设备的输出信号捕获并生成与之对应的事务。

5. 事务（Transaction）：事务是UVM环境中的一种数据结构，它封装了验证过程中的数据和控制信息。

事务用于在驱动和监控之间传递数据。

6. 序列（Sequence）：序列是UVM环境中的一个组件，用于生成一系列的事务。

序列定义了事务的数据和控制信息，以及生成和管理事务序列的逻辑。

7. UVM Testbench：UVM Testbench是UVM环境的一部分，它是整个验证环境的顶层组织结构。

UVM Testbench包含了顶层测试环境、监控、驱动、序列等组件。

8. 配置参数：UVM使用一种叫作配置参数（configuration parameter）的机制，用于动态地配置和管理各种验证组件的行为和功能。

9. UVM测试用例：UVM测试用例是UVM环境中的一个组件，它描述了验证目标的特定功能和行为。

测试用例通常由一个或多个序列组成，用来生成一系列的事务。

以上是UVM的基础知识，了解这些概念可以帮助你更好地理解和应用UVM验证方法学。

UVM基础总结——基于《UVM实战》示例

UVM基础总结——基于《UVM实战》⽰例⼀、前⾔⼯作⼀直在做SoC验证，更关注模块间的连接性和匹配性，所以相⽐于擅长随机约束激励的UVM来说，定向测试的概念更容易debug。

当然前提是IP已经被充分验证。

因此觉得接触UVM的机会较少。

到现在发现即使在SoC验证中依然有它的⽤武之地。

⽐如验证可独⽴于CPU⼯作的IP、快速对系统性能进⾏评估、重⽤IP级别的验证环境，甚⾄是⼀些通⽤的VIP也有基于UVM编写的。

基于这些考量，也逐渐开始接触。

《UVM实战》是很多验证⼯程师的启蒙，本⽂借⽤书中开头的⽰例简单梳理下UVM的基本知识。

⼆、UVM基础概述关于UVM的知识⽹络上已经铺天盖地了，下边的内容只是⾃⼰的⼀些认识和随记。

UVM其实就是基于SV语⾔写的⽤于验证的代码库和对应的验证规范。

下图是UVM验证环境的整体结构（图来源见参考⽂献1）。

图中注释介绍了每个组成部分的作⽤。

《UVM实战》书中给我留下最深刻的印象就是⽤⼦弹、弹夹和⼿枪分别类⽐transaction sequence和sequencer，这也是UVM环境灵活的重要原因之⼀。

这是激励的产⽣机制，⾄于响应的采集和响应任务会交给monitor和scoreboard。

后者中的期望数据或者参考数据的来源⽐较灵活，函数、⽂件或是reference model的响应均可。

以上是UVM的空间维度，这⼀概念也被抽象成如下的树状结构。

各个部分必然存在信息交互。

sequence和sequencer之间传递的是transaction，实际上component之间也是transaction级别的通信，叫做TLM （transaction level model）最常见的就是monitor中uvm_analysis_port通过uvm_tlm_analysis_fifo连接到reference model或scoreboard中的uvm_blocking_get_port。

uvm知识点总结

uvm知识点总结UVM 架构UVM 的架构包括以下几个重要部分：1. UVM 库 (UVM Library): UVM 库是一个可复用的验证组件集合，包含了多个验证类，如uvm_component、uvm_object、uvm_sequence 等，这些类组成了 UVM 框架。

2. UVM Testbench: UVM Testbench 是一个验证环境框架，它是基于 UVM 库构建起来的，用于创建验证环境、生成测试用例、进行仿真等。

3. UVM Test: UVM Test 是一个测试用例，主要由 UVM sequence 和 UVM 配置对象构成，它是用来验证被测试设计的功能是否正确。

4. UVM Agent: UVM Agent 是一个验证组件，是用于连接被测试设计和验证环境的中间层；它包括了 driver、monitor、sequence、sequencer 等。

基本概念UVM 中的一些基本概念包括以下内容：1. UVM Component: UVM 组件是 UVM 测试环境中的基本单元，用于组织和管理验证环境中的各种功能。

UVM 组件包括了 uvm_component、uvm_object、uvm_sequence 等。

2. UVM Object: UVM 对象是 UVM 中的一个基本概念，它是 uvm_component、uvm_sequence 和 uvm_transaction 的基类，用于实现类似于面向对象编程的功能。

3. UVM Phase: UVM 通过阶段 (Phase) 来管理验证环境的初始化、运行和结束等过程。

UVM 提供了一系列的任务来进行阶段的管理，如 uvm_phase、uvm_sequence、uvm_objection 等。

4. UVM Transaction: UVM 事务是指在验证中进行的交互过程，包括了数据传输、信号传递、命令执行等；UVM 提供了 uvm_transaction 类来实现事务级建模。

uvm知识点

uvm知识点UVM知识点UVM（Universal Verification Methodology）是一种用于硬件验证的标准方法学。

它提供了一套完整的验证框架和库，可用于设计和验证工程师开发的各种硬件设计。

UVM的主要目标是提高验证效率、加速验证流程，并提供一种可重用性的验证方法。

下面将介绍UVM的几个重要知识点。

1. UVM中的基本概念UVM中有几个基本概念需要理解。

首先是UVM Testbench，它是一个验证环境的集合，包括UVM Agent、UVM Sequence、UVM Driver、UVM Monitor等组件。

UVM Agent是验证环境中的一个重要组成部分，负责模拟设计中的一个或多个接口，并与设计进行通信。

UVM Sequence是一个用于生成测试向量的对象，它通过UVM Driver将测试向量发送给设计。

UVM Monitor是用于监控设计中信号变化的组件。

2. UVM中的消息和日志在UVM中，消息和日志用于记录验证过程中的重要信息。

UVM提供了几种不同级别的消息，包括FATAL、ERROR、WARNING、INFO和DEBUG。

开发人员可以根据需要选择适当的级别来记录不同类型的消息。

UVM还提供了灵活的消息过滤机制，可以根据需求过滤和控制消息的输出。

3. UVM中的事务和序列事务是在UVM中用于描述和传输数据的基本单元。

它包含了一些用于描述数据的字段，例如地址、数据和控制信号等。

事务通常由UVM Sequence生成，并通过UVM Driver发送给设计。

序列是一组事务的集合，用于描述测试向量的生成方式。

UVM提供了丰富的序列控制机制，可以灵活地生成各种测试向量。

4. UVM中的环境配置UVM提供了一种灵活的配置机制，可以在运行时配置验证环境的各个组件。

通过使用UVM的配置对象，可以在运行时修改和控制环境中的各种参数和属性。

这种配置机制可以大大提高验证环境的灵活性和可重用性。

《UVM实战》读书笔记思维导图

第7章 UVM中的寄存器模型
7.1 寄存器模型简介
7.2 简单的寄存器模型
7.3 后门访问与前门访问
7.4 复杂的寄存器模型
7.5 寄存器模型对 DUT的模拟
7.6 寄存器模型中一些内建的seque...
7.7 寄存器模型的高级用法
7.8 寄存器模型的其他常用函数
第8章 UVM中的factory机制
的组成
2.2 只有
2
driver的验证
平台
3 2.3 为验证平
台加入各个组件
4 2.4 UVM的终
极大作： c...
5 2.5 建造测试
用例
第3章 UVM基础
3.1
1
uvm_compo
n e n t 与 u v. . .
3.2 UVM的树 2
形结构
3 3.3 field
automation. ..
最新版读书笔记，下载可以直接修改
《UVM实战》
PPT书籍导读
读书笔记模板
最
新
版
本
本书关键字分析思维导图
代码
平台
用法器
版权
信息
寄存
机制
参数
应用模型
编程设计
第章
验证
迁移
基础
测试用例
使用
小而美
目录
01 第1章与UVM的第一次接触
02
第2章一个简单的 UVM验证平台
03 第3章 UVM基础
04
4 3.4 UVM中打
印信息的控制
5 3.5
config_db机制
第4章 UVM中的TLM1.0通信
4.2 UVM中各种端口的互连

uvm 继承关系(一)

uvm 继承关系(一)UVM继承关系1. 概述UVM（Universal Verification Methodology）是一种通用的验证方法学，广泛应用于硬件设计行业。

在UVM中，继承关系是一种重要的设计模式，用于定义验证环境中的各个组件。

2. UVM继承关系的类型在UVM中，继承关系主要有以下几种类型：配置数据库继承关系配置数据库继承关系用于保存和管理测试环境中的配置信息。

通过继承，可以实现配置信息的重用和扩展。

Testbench继承关系Testbench继承关系用于构建验证环境中的测试平台。

通过继承，可以实现测试平台的模块化和复用。

Agent继承关系Agent继承关系用于构建验证环境中的Agent组件，用于生成和接收设计模块的数据。

通过继承，可以实现Agent的配置和功能的扩展。

Sequence继承关系Sequence继承关系用于生成测试模式，驱动Agent发送特定的数据到设计模块。

通过继承，可以实现测试序列的复用和扩展。

Scoreboard继承关系Scoreboard继承关系用于验证设计模块的输出结果是否符合预期。

通过继承，可以实现Scoreboard的功能扩展和错误检测。

3. UVM继承关系的作用UVM继承关系在验证环境的构建中扮演重要角色，具有以下作用：代码重用通过继承可以实现代码的重用，减少重复编写相似功能的代码，提高开发效率。

功能扩展通过继承可以扩展已有组件的功能，满足特定需求。

例如，在Agent组件中可以扩展数据生成算法。

模块化设计通过继承可以实现模块化的设计，各个组件之间相互独立，易于维护和管理。

多态性通过继承可以实现多态性，使得组件的行为根据实际情况进行动态变化，提高测试的灵活性和可扩展性。

4. 总结UVM继承关系是一种重要的设计模式，在验证环境的构建中具有重要作用。

各种继承关系的应用使得验证环境更加模块化、可复用和灵活，提高了验证的效率和可维护性。

因此，熟练掌握UVM继承关系的使用是每个资深创作者的必备技能之一。

UVM学习笔记（一）

UVM学习笔记（⼀）UVM(Universal verification methodology)简介所有的验证⽅法学服务⽬的都在于提供⼀些可以重⽤的类来减轻在项⽬之间⽔平复⽤和垂直复⽤的⼯作量UVM类库地图 ---> P260类库地图的分类：核⼼基类⼯⼚(factory)类事务(transaction)和序列(sequence)结构创建(structure creation)类环境组件(environment component)类通信管道(channel)类信息报告(message report)类寄存器模型类线程同步(thread synchronization)类事务接⼝(transaction interface)类⼯⼚机制概述⼯⼚机制也是软件的⼀种典型设计模式(design pattern)⼯⼚的意义UVM⼯⼚的存在就是为了更⽅便地替换验证环境中的实例或者注册了的类型，同时⼯⼚的注册机制也带来了配置的灵活性实例或者类型替代在UVM中称作覆盖（override）,⽽被⽤来替换的对象或者类型，应该满⾜注册（registration）和多态（polymorphism）的要求UVM验证环境构成可以分为两部分，⼀部分构成了环境的层次，这部分代码是通过uvm_component类完成，另外⼀部分构成了环境的属性（配置）和数据传输，这⼀部分通过uvm_object类完成uvm_component类继承于uvm_object类，⽽这两种类也是进出⼯⼚的主要模具和⽣产对象模具：通过注册，可以利⽤⼯⼚完成对象创建对象由⼯⼚⽣产，也是利⽤了⼯⼚⽣产模具可灵活替代的好处，使得在不修改原有验证层次和验证包的同时，实现了对环境内部组件类型或者对象的覆盖uvm_{component,object}的例化创建uvm_component对象时，comp_type::type_id::create(string name, uvm_component parent);创建uvm_object对象时，object_type::type_id::create(string name);⼯⼚提供的便利——创建(create)⼀般来说，运⽤factory的步骤可分为：将类注册到⼯⼚在例化前设置覆盖对象和类型（可选的）对象创建在两种类comp1和obj1的注册中，分别使⽤了UVM宏 `uvm_component_utils和`uvm_object_utils宏做的事情就是将类注册到factory中，在解释注册函数之前，我们需要懂得在整个仿真中，factory是独有的，即有且只有⼀个，这保证了所有类的注册都在⼀个“机构”中class comp1 extends uvm_component;`uvm_component_utils(comp1) //将对象已经注册在⼯⼚中function new(string name="comp1", umv_component parent=null);super.new(name,parent); //继承了⽗类的new$display($sformatf(“%s is created”，name))；endfunction： newfunction void build_phase(uvm_phase phase);super.build_phase(phase);endfunction: build_phaseendclassclass obj1 extends uvm_object;`uvm_object_utils(obj1) //将对象已经注册在⼯⼚中function new(string name="obj1");super.new(name,parent); //继承了⽗类的new$display($sformatf(“%s is created”，name))；endfunction： newendclasscomp1 c1, c2;obj1 o1, o2;initial beginc1 = new("c1");o1 = new("o1");c2 = comp1::type_id::create("c2", null);o2 = obj1::type_id::create("o2");end。

《UVM实战(卷1)》学习笔记

《UVM实战（卷1）》学习笔记看了第1/2/3/4/5/6/8/9.1这几个章节。

第一章是综述，第二章是一个具体的例子，学习笔记从第三章相关内容开始。

我个人觉得UVM重要的部分（特点的部分）：1）factory机制（overrideconfig_db）2）TLM传递3）phase机制4）sequence-sequencer以及virtualseq/sqr里的。

需要也是item，当所有的driver要派生自uvm_driver.driver用来把sequence_item中的信息驱动到DUT端口上，从transaction-level向signal-level的转换。

uvm_driver需要参数（REQRSP），比uvm_component增加了几个成员。

重要的是seq_item_port和req/rsp.（src/comps/uvm_driver.svh）monitor/scoreboard派生自uvm_monitor和uvm_scoreboard，但是uvm_monitor和uvm_scoreboard并没有在uvm_component基础上做扩展。

src/comps/uvm_monitor.svh里没有增加2对于`uvm_component_utils(类名)uvm_component里的成员也可以像uvm_object里成员一样，用field_automation机制。

field_automation机制：对于uvm_object派生类来说，field_automation机制让对象自动有的copycompareprintpackunpack等函数，简化了实现uvm_component派生类里一些function/task的工作量对于uvm_component派生类来说，field_automation机制最重要的是可以在build_phase中自动获取uvm_config_db#()::set()的数值（必须加super.build_phase(phase)）----也就是不用写uvm_config_db#()::get()注意：field_automation的macro的类型要和uvm_config_db的参数类型一致：如下示例代码，field_intvsuvm_config_db#(bit[47:0])这个时候super.build_phase()是不起作用的。

UVM实战指南

UVM实战指南&t=1&c=fks_000000084⽽为了在widget的对象中使⽤这个函数对象，必须事先在设计好的调⽤点对callback对象可以看出，在执⾏的过程中，可以对widget对象进⾏动态的添加callback，从⽽动态的改变widget对象的动作。

上⾯的例⼦⾮常简单，仅仅是输出⼀些讯息⽽已，有⼀些局限：1.这个callback结构并不能够真的改变widget对象的内部成员，以及处理的数据内容，仅仅能够输出⼀些讯息。

2.对每⼀个widget的对象，都需要单独添加相关callback对象，假如程序中⼜创建了⼀个新的widget对象，那么这个对象的callback queue初始是空的，也就是没有callback。

必须再次添加才能让这个新的widget调⽤相应的callback功能。

3.callback只有⼀个地⽅，可以扩展到多个地⽅。

另外也可以使⽤function，⽽不仅仅是task.⼯⼚模式的简单理解⾸先,如果⼀个客户要⽤到⼀款⼿机,⼀般的做法是客户去创建⼀款⼿机,然后拿来⽤:这时,客户需要知道怎么去创建⼀款⼿机,客户和⼿机就紧密耦合在⼀起了.为了降低耦合,就出现了⼯⼚类,把创建⼿机的操作放到了⼯⼚⾥⾯去,客户直接使⽤⼯⼚的创建⼿机⽅法,传⼊想要的⼿机型号就⾏了,⽽不必去知道创建的细节.随着⼿机种类越来越多,简单⼯⼚模式出现了弊端,每次新加⼊⼿机品种,⼯⼚类都要加⼊新的创建逻辑.这时我们就可以把⼯⼚类定义成了接⼝,⽽每增加⼀种新的⼿机,就增加该⼿机对应⼯⼚类的实现,这样⼯⼚的设计就可以扩展了,⽽不必去修改原来的代码:随着⼯⼚规模的继续扩⼤,⼯⼚开始⽣产充电器了.这时候⼯⼚有⼆个系列的产品:⼿机和充电器.⽽⼿机必须使⽤对应的充电器才能使⽤.这时候分别使⽤⼀个⼿机⼯⼚和⼀个充电器⼯⼚都不能满⾜我们的需求,我们必须确认⼿机跟充电器的对应关系.我们把⼯⼚改造⼀下,把⼿机⼯⼚跟充电器⼯⼚联系在⼀起:抽象⼯⼚模式⼯⼚⽅法模式简单⼯⼚模式UVM实战指南——第1部分2010-10-31 21:54:15| 分类：SystemVerilog| 标签：uvm |字号订阅验证的复杂度已经明显超过设计。

Get格雅UVM实战指南

UVM实战指南Callback——最简单的callback2021-01-21 22:06:01| 分类：SystemVerilog|字号订阅在RVM、VMM、OVM/UVM中，常常提到callback这个概念。

指在事先设置好的地方留下一个接口，通过向这个接口添加一些函数对象，来到达不改变代码结构而动态修改代码行为。

下面用systemverilog来举一个简单的callback 例子：1 class callback;23 virtual task cb_pre_run();4 $display("base callback run");5 endtask:cb_pre_run67 endclass:callback89 class widget;1011 callback cb_queue[$];1213 function void add_cb(callback cb);14 cb_queue.push_back(cb);15 endfunction:add_cb1617 task run();18 // add callback here19 foreach(cb_queue[i])begin20 cb_queue[i].cb_pre_run();21 end22 $display("widget run....");23 endtask:run24 endclass:widget2526 module top;2728 class ext_callback extends callback;29 task cb_pre_run();30 $display("ext callback run");31 endtask:cb_pre_run32 endclass:ext_callback33 widget w;34 callback cb0;35 ext_callback cb_ext;363738 initial begin39 w =new;40 cb0 =new;41 cb_ext =new;42 w.run;43 w.add_cb(cb0);44 $display("=========== After Add base Callback");45 w.run;46 w.add_cb(cb_ext);47 $display("=========== After Add extention Callback");48 w.run;49 end5051 endmodule;// top在sysverilog中，没有函数指针的概念，因此必须将函数包装成为一个对象，就是上面例子中的callback class. 而为了在widget的对象中使用这个函数对象，必须事先在设计好的调用点对callback对象中的函数进行逐个调用〔代码19-21行〕。

UVM实战指南第部分

(*)题外话：TLM可能是UVM中最重要的概念，掌握了TLM，就可以开场尝试编写一些小程序了。

翻译这篇文章，也是为了稳固加强对TLM的理解。

(*)几个名词：transaction翻译为事务或者交易；packet翻译为封包，packet属于transaction；monitor翻译为监视器；driver翻译为驱动器；scoreboard翻译为记分牌；有些词汇直接被运用到UVM源代码上，所以有时候用英文更容易描述清楚。

(*)语言的目的是为了交流，翻译不是为了纯粹的语言转换，而是为了传递思想。

4.6 UVM中事务级建模(TLM)20多年前，设计者从门级转向RTL级。

这次转换来自于标准Verilog/VHDL的RTL编码风格，以及RTL综合实现工具的推出。

使用RTL最大的好处是让设计者更多的专注于时序行为的设计以及功能的正确性，而很少考虑门级相关设计。

TLM(事务级建模)同样在抽象级别上更进了一步，在设计与验证领域都有出现。

通过TLM, 中心放在系统级别的各种事务流的建模，而更少关心时钟级别的行为。

TLM在测试向量中已经使用多年。

通常，在产生鼓励与覆盖率检查的时候使用事务而不是用时钟级别建模，这种方式就是TLM. 为了验证RTL级别的DUT(需要测试的模块)，测试向量使用事务第 1 页发生器(transactor)(有时也称为总线功能模型(BFM))，将RTL 级与事务级进展转换。

在UVM中，此事务发生器也被叫做驱动(driver)或者收集器(collector)。

TLM中，事务通过方法调用与类对象来建模。

使用事务级而不是信号级别来建模有几个显著的好处：•TLM比RTL更简洁，仿真速度快。

•TLM模型的抽象级别更高，更加契合验证工程师或设计工程师对内部功能的考虑，从而使得建模更简单，并且更容易被其他工程师理解。

•TLM模型将不符合复用的局部移到模型之外，因此TLM很适合复用。

并且，TLM使用面向对象的技术，比方继承、实现与接口别离的技术。

UVM寄存器篇之一：寄存器模型概览（上）

UVM寄存器篇之一：寄存器模型概览（上）对于硬件有了解的读者，都知道寄存器是模块之间互相交谈的窗口。

一方面可以通过读出寄存器的状态，获取硬件当前的状况，另外一方面也可以通过配置寄存器，使得寄存器工作在一定的模式下。

而在验证的过程中，寄存器的验证也排在了验证清单的前列，因为只有首先保证寄存器的功能正确，才会使得硬件与硬件之间的交谈是“语义一致”，否则如果寄存器配置的结果与寄存器配置内容不同，那么硬件无法工作在想要的模式下，同时寄存器也可能无法正确反映硬件的状态。

本章我们关于UVM寄存器模型的介绍中，会将之前的设计MCDF 中的寄存器模块简化出来，通过硬件的寄存器模型、访问的总线UVC 以及寄存器模型之间建立一个小的验证环境，以此贯穿本章的内容：•寄存器有关的工业流程。

•寄存器模型的UVM类和类之间的关系。

•如何将寄存器模型集成到现有环境，与总线UVC桥接，与DUT 模型绑定。

•寄存器模型的常用方法和预定义的sequence。

•寄存器测试和功能覆盖率的实际用例。

硬件中的各个功能模块都可以由处理器来配置功能以及访问状态，而与处理器的对话即是通过寄存器的读写来实现的。

寄存器的硬件实现是通过触发器，而每一个比特位的触发器都相应代表了寄存器功能描述（function specification）表上的一位。

一个寄存器一般由32个比特位构成，将单个寄存器拆分之后，又可以分为多个域（field），不同的域往往代表着某一项独立的功能。

单个的域可能由多个比特位构成，也可能由单一比特位构成，这取决于该域的功能模式可配置的数目。

而不同的域，对于外部的读写而言，又大致可以分为WO （write-only，只写），RO（read-only，只读）和RW（read andwrite，读写），除过这些常见的操作属性以外，还有一些特殊行为（quirky）的寄存器，例如写后擦除模式（clean-on-read，RC），只写一次模式（write-one-to-set，W1S）。

UVM实战指南——第3部分

UVM实战指南——第3部分第3部分：UVM实战在前两部分中，我们介绍了UVM框架的基本概念和基本用法。

在这一部分，我们将进一步探讨UVM的实际应用，并提供一些实战技巧和建议。

1.重要性分析在开始UVM实战前，首先需要进行重要性分析。

这包括确定哪些功能是需要覆盖的，哪些功能是必要的，以及哪些可能引发错误的功能需要特殊关注。

这些分析可以帮助您确定测试计划的优先级，并在测试开发过程中更好地分配资源。

2.测试计划开发根据重要性分析的结果，您可以开始开发测试计划。

测试计划应该详细描述实施哪些测试以及对每个测试的期望结果。

它还应包括测试开发和验证团队的人员分配和时间表安排。

通过制定清晰的测试计划，您可以确保测试开发工作有条不紊地进行，并及时识别和解决问题。

3.环境开发在开发测试计划后，您可以开始开发UVM环境。

环境是UVM中最关键的部分之一，它包含了用于模拟验证环境的各种组件和接口。

在环境开发过程中，您需要根据测试计划中的需求，选择和实例化适当的UVM组件，并将它们连接在一起以形成完整的验证环境。

4.测试用例开发测试用例是验证过程中的核心功能。

在开发测试用例时，您需要通过实例化适当的测试类，指定测试目标，并配置测试环境。

您还需要定义测试封包，设置或生成输入数据，以及从模拟输出中提取和分析结果。

测试用例的开发应该遵循UVM的最佳实践，并确保测试覆盖范围广泛且有效。

5.仿真运行和调试一旦测试用例开发完成，您可以开始运行仿真并进行调试。

在仿真过程中，您可能会遇到各种问题，如信号不正确、仿真停滞、错误输出等。

为了有效解决这些问题，您可以使用UVM提供的调试功能，如消息和日志记录、波形查看和追踪。

通过运用这些工具，您可以更快地找到问题所在，并采取适当的措施进行修复。

6.结果分析和测试报告当仿真运行完成后，您需要对结果进行分析，并生成测试报告。

在UVM中，您可以通过访问测试类中的结果和统计信息来执行结果分析。

您还可以使用UVM提供的报告和日志功能，将结果以易于阅读和理解的方式呈现给项目团队和其他相关人员。

UVM学习报告

UVM学习报告UVM学习报告 (1)UVM结构图 (1)1. transaction (2)2. sequence (2)3. drive (4)4. monitor (5)5. input_agent/output_agent (6)6. reference_model (6)7. scoreboard (7)8. interface (7)9. env (8)1. UVM结构图1.transaction①定义成员变量，以及变量类型；②在constraint中对随机的数据增加限制条件；③使用`uvm_object_utils系列宏实现factory机制,调用uvm_filed_int函数，传入的第一个参数是要操作的对象的指针，第二个参数表明这是一个什么操作，还可以通过某些参数把某个字段的相应功能去除。

2.sequence在sequence中最关键的是body。

在body中有调用了10次`uvm_do宏。

这个宏每执行一次就会向uvm_sequencer发送一个数据，uvm_sequencer收到数据就传给uvm_drive。

在UVM的组件中，drive，monitor，reference_model和scoreboard 的main_phase或run_phase都是无限循环的，要想让整个仿真停止，就要调用$finish函数。

在UVM中调starting_phase.raise_objection(this)告诉UVM要开始发包了，在发送完之前不能调用$finish。

在包发送完毕后，调用starting_phase.drop_objection(this)来告诉UVM可以调用$finish了。

当调用drop_objection时，UVM会检查一下其他的component的objection是否已经被drop了，当所有的objection已经被drop了，才会调用$finish。

3.driveUVM验证平台使用drive来发送数据，在drive中：①new函数定义时一般都要写上（name, parent）这一句，意思是执行父类的new函数。

UVM序列篇之一：新手上路

UVM序列篇之一：新手上路有了UVM的世界观，知道这座城市的建筑设计理念，也跟着码师们（实在不忍心用码农……）一起修建了各成独立环境的组件群落。

读者们在经过一番实践，经过上一章讲的组件之间的通信方式，开辟了各个建筑之间的道路、桥梁和河道以后，就可以进入紧张繁忙的物流期了。

如果城市里面没有交通，那么显然不会有多热闹。

在本章中，我们将主要围绕下面几个核心词来阐述它们的作用、主要分类以及之间的互动关系：•sequence item•sequence•sequencer•driver如果按照交通道路的车流来打比方，sequence就是道路，sequence item是道路上行驶的货车，sequencer是目的地的关卡，而driver便是最终目的地卸货的地方。

从软件实施的层面来讲，这里的货车是从sequence一端出发的，再经过了sequencer，最终抵达了driver，经过driver的卸货，每一辆的货车也就完成了它的使命。

而driver对每一件到站的货物，经过它的扫面处理，将它分解为更小的信息量，提供给DUT。

在这个过程中，不同的角色中有下面的这些软件互动：1.sequence对象自身会产生目标数量的sequence item对象。

借助于SV的随机化和sequence item对随机化的支持，使得产生的每个sequence item对象中的数据内容都不相同。

2.产生的sequence item会经过sequencer再流向driver。

3.driver得到了每一个sequence item，经过数据解析，再将数据按照与DUT的物理接口协议写入到接口上，对DUT形成有效激励。

4.如果有必要的时候，driver在每解析并且消化完一个sequenceitem，它也会将最后的状态信息同sequence item对象本身再度返回给sequencer，最终抵达sequence对象一侧。

这么做的目的在于，有的时候sequence需要得知driver与DUT互动的状态，这就需要driver仍然有一个回路再将处理了的sequence item对象和状态信息写回到sequence一侧。

uvm 基础知识

UVM（Universal Verification Methodology）是一种用于硬件验证的标准方法学。

它是由Accellera组织开发的，旨在提供一种统一的验证方法学，以加快硬件设计验证的速度和效率。

以下是UVM的一些基础知识：
1. UVM构建在SystemVerilog语言的基础上，利用了SystemVerilog的各种特性，如类、继承、多态等。

2. UVM采用了基于类的面向对象编程方法，通过创建各种类来描述和模拟硬件设计中的各个组件和行为。

3. UVM提供了一套丰富的验证组件，包括顶层环境（uvm_env）、测试用例（uvm_test）、代理（uvm_agent）、驱动器（uvm_driver）、监视器（uvm_monitor）等，这些组件可以根据设计的需求进行组合和扩展。

4. UVM采用了基于事务的验证方法，通过定义和交换事务来模拟和验证设计中的数据传输和交互。

5. UVM提供了一套丰富的验证功能，如随机性、覆盖率、
错误注入、消息传递等，可以帮助验证工程师更好地设计和执行验证计划。

6. UVM还提供了一套强大的报告和调试机制，可以帮助验证工程师快速定位和解决验证中的问题。

总之，UVM是一种用于硬件验证的标准方法学，通过利用SystemVerilog的特性和提供丰富的验证组件和功能，可以帮助验证工程师更高效地进行硬件设计验证。