uvm实战-学习笔记
UVM实战指南-第四章
4.1.2 UVM 库使用指南
为了避免命名冲突,避免在全局环境中导入 uvm_pkg. 其他的 package 也同样适用此原则(避免 全局环境中导入)
顶层文件一般如下格式
`ifndef <FILE _NAME>_SVH `define <FILE _NAME>_SVH ... 文件内容 `endif 这种方式允许 UVM 库被多个地方引用而避免重复声明,一起编译的时候仅编译一次。建议用户在自己的 UVM 文件中也使用此方式。
上面简单的例子包含了一个几乎所有交易(transaction)都有的 print()方法。 大部分数据项都需要打印,复 制,比较,打包,解包以及其他功能。如果让开发者去自已去定义这些功能将不便于复用。环境整合者将
3Байду номын сангаас
Design IC
/
electron64@
这一章讲解库的结构以及基本功能,重点放在大多数验证环境所需要的基本特征上。 注意:为了简化,例子并没有完全遵循 UVM 建议的架构和方法学。 这一章主要包括:
使用 UVM 库 基本类 TLM 端口 工厂模式 消息和汇报 配置机制
4.1 使用 UVM 库
为了使用 UVM 库,用户需要:
实例 4–1: 非 UVM 类定义 1 typedef enum bit { APB _READ, APB_WRITE} apb _direction _enum; 2 class apb_transfer; 3 rand bit [ 31:0] addr; 4 rand bit [ 31:0] data; 5 rand apb _direction _enum direction; 6 function void print(); 7 $display("%s transfer: addr=%h data=%h", (), addr, data); 8 endfunction : print 9 endclass : apb_transfer
UVM实战指南——第3部分
UVM实战指南——第3部分第3部分:UVM实战在前两部分中,我们介绍了UVM框架的基本概念和基本用法。
在这一部分,我们将进一步探讨UVM的实际应用,并提供一些实战技巧和建议。
1.重要性分析在开始UVM实战前,首先需要进行重要性分析。
这包括确定哪些功能是需要覆盖的,哪些功能是必要的,以及哪些可能引发错误的功能需要特殊关注。
这些分析可以帮助您确定测试计划的优先级,并在测试开发过程中更好地分配资源。
2.测试计划开发根据重要性分析的结果,您可以开始开发测试计划。
测试计划应该详细描述实施哪些测试以及对每个测试的期望结果。
它还应包括测试开发和验证团队的人员分配和时间表安排。
通过制定清晰的测试计划,您可以确保测试开发工作有条不紊地进行,并及时识别和解决问题。
3.环境开发在开发测试计划后,您可以开始开发UVM环境。
环境是UVM中最关键的部分之一,它包含了用于模拟验证环境的各种组件和接口。
在环境开发过程中,您需要根据测试计划中的需求,选择和实例化适当的UVM组件,并将它们连接在一起以形成完整的验证环境。
4.测试用例开发测试用例是验证过程中的核心功能。
在开发测试用例时,您需要通过实例化适当的测试类,指定测试目标,并配置测试环境。
您还需要定义测试封包,设置或生成输入数据,以及从模拟输出中提取和分析结果。
测试用例的开发应该遵循UVM的最佳实践,并确保测试覆盖范围广泛且有效。
5.仿真运行和调试一旦测试用例开发完成,您可以开始运行仿真并进行调试。
在仿真过程中,您可能会遇到各种问题,如信号不正确、仿真停滞、错误输出等。
为了有效解决这些问题,您可以使用UVM提供的调试功能,如消息和日志记录、波形查看和追踪。
通过运用这些工具,您可以更快地找到问题所在,并采取适当的措施进行修复。
6.结果分析和测试报告当仿真运行完成后,您需要对结果进行分析,并生成测试报告。
在UVM中,您可以通过访问测试类中的结果和统计信息来执行结果分析。
您还可以使用UVM提供的报告和日志功能,将结果以易于阅读和理解的方式呈现给项目团队和其他相关人员。
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 修改测试。
(完整版)uvm实战-学习笔记
《UVM实战(卷1)》学习笔记看了第1/2/3/4/5/6/8/9.1 这几个章节。
第一章是综述,第二章是一个具体的例子,学习笔记从第三章相关内容开始。
我个人觉得UVM重要的部分(特点的部分):1)factory机制(override config_db)2)TLM传递3)phase机制4)sequence-sequencer 以及virtual seq/sqr内容中的截图基本来自于UVM源代码、书自带的例子和《uvm1.1应用指南及源代码分析》这个PDF里的。
需要结合书(《UVM实战(卷1)》第1版)来看这个笔记。
第3章UVM基础3.1 uvm_component和uvm_object常用的类名字:这个图是从作者张强的《uvm1.1应用指南及源代码分析》里截得,不如书上3.1.1里的图好。
uvm_sequencer也是代码里必须有的,所以我加了uvm_sequenceruvm_void是一个空的虚类。
在src/base/uvm_misc.svh中定义:红框的是我们搭testbench的时候用的比较多的基类。
常用的uvm_object派生类:sequencer给driver的transaction要派生自uvm_sequence_item,不要派生自uvm_transaction所有的sequence要派生自uvm_sequence或者uvm_sequence的派生类,可以理解为sequence是sequence_item的组合(集合)。
driver向sequencer索要item,sequencer检查是否有sequence要发送item,当发现有item待发送时,就把这个item发给driver.常用的uvm_component派生类:所有的driver要派生自uvm_driver. driver用来把sequence_item中的信息驱动到DUT端口上,从transaction-level向signal-level的转换。
uvm system verilog总结
uvm system verilog总结### UVM System Verilog 总结#### 导语UVM(Universal Verification Methodology)与System Verilog的结合,为芯片设计验证领域带来了革新。
这种方法论不仅提高了验证效率,还增强了验证的可重用性和覆盖率。
本文将全面总结UVM与System Verilog的相关概念、特点以及应用。
---#### 一、UVM与System Verilog概述**1.1 UVM简介**UVM是建立在System Verilog基础上的一个标准化验证方法论,旨在提供一种通用的、模块化的验证平台。
它通过将验证环境分层,实现了环境的可重用性和易于维护性。
**1.2 System Verilog简介**System Verilog是一种硬件描述和验证语言,结合了Verilog和VHDL的优点,并增加了面向对象编程的特性。
它在芯片设计和验证中广泛应用。
---#### 二、UVM的核心特点**2.1 面向对象**UVM采用面向对象的设计思想,将验证环境分为不同的类和层次,便于管理和重用。
**2.2 模块化**UVM的模块化设计使得验证环境可以根据不同的测试需求灵活组合和配置。
**2.3 自动化**UVM支持自动化测试,包括自动生成测试序列、自动检查和报告错误等。
---#### 三、System Verilog在UVM中的应用**3.1 非阻塞赋值**System Verilog的非阻塞赋值在UVM中用于描述硬件行为。
**3.2 面向对象编程**System Verilog的面向对象编程特性使得UVM可以定义基类和派生类,实现代码的复用。
**3.3 功能覆盖**利用System Verilog的功能覆盖(Functional Coverage)特性,UVM 可以全面检查设计功能的覆盖率。
---#### 四、UVM与System Verilog的结合优势**4.1 提高验证效率**UVM与System Verilog的结合使得验证人员可以快速搭建验证环境,提高验证效率。
uvm验证方法学的理解
uvm验证方法学的理解摘要:1.UVM简介2.UVM信息级别3.UVM冗余度控制4.如何应用UVM进行验证5.总结正文:UVM(Universal Verification Methodology)是一种验证方法学,广泛应用于电子设计自动化(EDA)领域。
UVM旨在提供一种统一、可重用的验证环境,以提高验证效率和可靠性。
本文将详细介绍UVM的基本概念、信息级别、冗余度控制以及如何应用UVM进行验证。
1.UVM简介UVM起源于1995年,由Mentor Graphics公司的David Flannery首次提出。
它是一种面向对象的验证方法学,基于组件架构,可以轻松地集成到现有的验证环境中。
UVM提供了一套丰富的库,包括常用的验证组件、传输层协议和消息机制等,使得验证工程师可以快速构建复杂的验证环境。
2.UVM信息级别UVM信息级别分为以下几种:- uvmNone:最低级别,不输出任何信息。
- uvmLow:输出较少的信息,主要用于错误诊断。
- uvmMedium:默认级别,输出较为详细的信息。
- uvmHigh:输出详细的信息,用于调试和问题定位。
- uvmDebug:最高级别,输出极为详细的信息,适用于深入分析。
通过设置不同的信息级别,UVM可以控制输出的日志信息,帮助我们专注于关心的内容。
3.UVM冗余度控制UVM通过冗余度级别的设置,提高了仿真日志的可读性。
在打印信息之前,UVM会比较要显示信息的冗余度级别与默认的冗余度阈值。
如果小于等于阈值,就会显示,否则不会显示。
默认的冗余度阈值为uvmMedium,所有低于等于uvmMedium的信息都会被打印出来。
4.如何应用UVM进行验证应用UVM进行验证的基本步骤如下:- 创建UVM环境:定义UVM域、组件和消息类型。
- 编写测试序列:针对待验证的IP(Intellectual Property)编写测试用例,生成激励。
- 应用激励:将测试序列应用到待验证的IP上,进行仿真。
《UVM实战》代码示例
《UVM实战》代码⽰例⾸先是top_tb:`timescale 1ns/1ps`include "uvm_macros.svh"import uvm_pkg::*;`include "my_if.sv"`include "my_transaction.sv"`include "my_sequencer.sv"`include "my_driver.sv"`include "my_monitor.sv"`include "my_agent.sv"`include "my_model.sv"`include "my_scoreboard.sv"`include "my_env.sv"`include "base_test.sv"`include "my_case0.sv"`include "my_case1.sv"module top_tb;reg clk;reg rst_n;reg[7:0] rxd;reg rx_dv;wire[7:0] txd;wire tx_en;my_if input_if(clk, rst_n);my_if output_if(clk, rst_n);dut my_dut(.clk(clk),.rst_n(rst_n),.rxd(input_if.data),.rx_dv(input_if.valid),.txd(output_if.data),.tx_en(output_if.valid));initial beginclk = 0;forever begin#100 clk = ~clk;endendinitial beginrst_n = 1'b0;#1000;rst_n = 1'b1;endinitial beginrun_test();endinitial beginuvm_config_db#(virtual my_if)::set(null, "uvm_test_top.env.i_agt.drv", "vif", input_if);uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.env.i_agt.mon", "vif", input_if);uvm_config_db#(virtual my_if)::set(null, "uvm_test_top.env.o_agt.mon", "vif", output_if);endendmodule定义了时钟频率,传递了接⼝以链接TB,和⼀个run_test()。
《UVM实战》读书笔记PPT模板思维导图下载
6.5 virtual sequence...
6.6 在 sequence中使
用conf...
6.7 response 的使用
6.8 sequence library
第7章 UVM中的寄存器模型
7.1 寄存器模型 简介
7.2 简单的寄存 器模型
7.3 后门访问与 前门访问
7.4 复杂的寄存 器模型
7.5 寄存器模型 对DUT的模拟
7.6 寄存器模型 中一些内建的 seque...
7.7 寄存器模型 的高级用法
7.8 寄存器模型 的其他常用函数
第8章 UVM中的factory机制
8.1 S y s t e m Ve r i l o g
对重载...
8.2 使用 factory机制进
行重载
8.3 常用的重载
第1章 与UVM的第一次接触
1.1 UVM是 什么
1.2 学了 UVM之后能 做什么
第2章 一个简单的UVM验证 平台
2.1 验证平台 1
的组成
2.2 只有
2
driver的验
证平台
3 2.3 为验证平
台加入各个组 件
4 2.4 UVM的
终极大作: sequenc...
5 2.5 建造测试
用例
感谢观看
读
书
笔
记
08 第8章 UVM中的 factory机制
09Leabharlann 第9章 UVM中代码 的可重用性
011
第11章 OVM到 UVM的迁移
010
第10章 UVM高级应 用
附录A
012 SystemVerilog使 用简...
目录
013 附录B DUT代码清单
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实战指南——第3部分
(*)题外话: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(需要测试的模块),测试向量使用事务发生器(transactor)(有时也称为总线功能模型(BFM)),将RTL级和事务级进行转换。
在UVM中,此事务发生器也被叫做驱动(driver)或者收集器(collector)。
TLM中,事务通过方法调用和类对象来建模。
使用事务级而不是信号级别来建模有几个显著的好处:∙TLM比RTL更简洁,仿真速度快。
∙TLM模型的抽象级别更高,更加契合验证工程师或设计工程师对内部功能的考虑,从而使得建模更简单,并且更容易被其他工程师理解。
∙TLM模型将不符合复用的部分移到模型之外,因此TLM很适合复用。
并且,TLM使用面向对象的技术,比如继承、实现和接口分离的技术。
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实战指南范文
UVM实战指南范文UVM(Universal Verification Methodology)是一种用于硬件验证的标准化方法学,它提供了一种强大的框架来设计和验证复杂的芯片和系统。
本文将介绍UVM的基本概念和使用方法,并提供一些实战指南,帮助读者深入了解和应用UVM。
UVM的基本框架包括四个主要组件:环境(Environment)、代理(Agent)、序列(Sequence)和驱动(Driver)。
环境是验证组件的容器,在其中实例化并连接各个代理,还负责配置和管理验证环境。
代理是验证环境中的一个子模块,负责实现和模拟芯片中的接口和功能。
序列是生成器和监控器之间的通信通道,用于生成和检查输入数据。
驱动是一个接口模块,负责向被测单元(DUT)发送序列。
UVM的使用方法可以分为以下几个步骤:1. 创建环境:首先,在UVM中创建一个环境(即testbench),并在其中实例化各个代理和其他必要的组件。
环境还负责配置和管理验证环境中的各个模块。
2.实例化代理和DUT:在环境中实例化代理和DUT,将它们连接起来。
代理模块负责实现和模拟芯片中的接口和功能,而DUT是待验证的芯片。
3.编写序列和生成器:根据测试需求,编写序列和生成器,用于生成输入数据和控制测试流程。
序列是生成器和监控器之间的通信通道,用于生成和检查输入数据,根据指定的顺序发送。
4.实现驱动和监控器:编写驱动和监控器代码,用于向DUT发送和接收数据。
驱动负责将序列中的数据发送给DUT,监控器负责检查和采集来自DUT的输出数据。
5. 运行仿真:通过调用uvm_config_db和uvm_top函数来完成对整个验证环境的配置和管理,并调用run_test函数来运行验证。
在实战中,我们需要注意以下几个关键点:1.数据驱动:UVM基于数据驱动的方法,即通过输入数据来驱动测试流程。
因此,在设计测试用例时,需要考虑各种可能的输入组合,并确保测试覆盖所有的边界条件。
【UVM源码学习】uvm-comparer
【UVM源码学习】uvm_comparer uvm_comparer是个基类,提供了对象object⽐较的策略,⽐较结果(⽐较次数、成功与否)保存在comparer object中。
uvm_object::compare及uvm_object::do_compare即调⽤了uvm_comparer对两个uvm_object类型的参数进⾏⽐较。
uvm_comparer 中主要实现了以下⼏个⽅法:序号⽅法描述1compare_feild ⽐较两个uvm_bitstream_t类型的object lhs & rhs,两个object相同返回1,失败返回0并打印两个⽐较对象(打印严重性可设置)。
可指定⽐较size,size⼩于64采⽤compare_feild_int进⾏⽐对,否则直接⽐对,⽐对时可指定⽐较对象的mask,对应⽐特mask为1才进⾏⽐对,默认mask全1。
2compare_feild_int⽐较两个int类型的object 3compare_feild_real⽐较两个real类型的object4compare_object ⽐较两个uvm_object类型的object 。
若policy为UVM_REFERENCE,直接⽐较两个handle,否则调⽤pare(rhs, this)进⾏⽐较。
lhs或rhs任意⼀个为null都会⽐较失败5compare_string⽐较两个string类型的object,直接⽐较6print_msg ⽐较失败时会调⽤该函数打印两个⽐较的对象信息,此外还会记录miscompare的次数并把打印信息添加保存⾄字符串miscompares中。
7print_rollup 当⽐较的对象为uvm_object类型时,print_msg⽆法打印uvm_object的信息,print_rollup打印uvm_object类型的⽐较对象信息。
该⽅法为uvm库内部⽅法,不记录⽐较信息,也不建议⽤户直接调⽤。
路科验证uvm总结
路科验证uvm总结UVM(Universal Verification Methodology)是一种用于验证硬件设计的方法学。
它提供了一个结构化的框架,使工程师能够更高效地开发和执行验证环境。
以下是对UVM验证方法学的验证过程进行的路科验证的总结。
在进行UVM验证时,首先需要创建一个UVM验证环境。
这个环境包括顶层测试模块、DUT(Device Under Test)模块、以及与DUT交互的代理模块。
通过这种模块化的设计,我们可以更好地管理和控制验证过程。
在UVM验证环境中,我们使用UVC(UVM Verification Component)来验证DUT。
UVC是独立且可重用的验证组件,它包含了验证DUT所需的信号生成、数据采集和功能检查等功能。
UVC还提供了一组事务级别接口,用于与顶层测试模块进行通信。
为了验证DUT的功能和正确性,我们需要创建一系列的测试用例。
这些测试用例在顶层测试模块中实现,并通过驱动器(driver)和监控器(monitor)进行信号的生成和采集。
驱动器将测试数据转换为信号并发送给DUT,而监控器则监听DUT的输出信号并进行数据采集和分析。
通过UVM提供的事务级别接口,测试用例可以轻松地向UVC发送事务。
这些事务可以包括读取和写入的操作,以及对DUT内部寄存器的访问。
通过执行不同的测试用例,我们可以覆盖不同的DUT功能,并验证其正确性。
另外,UVM还提供了一组强大的约束机制,用于指定信号的时序和约束条件。
这些约束条件可以确保DUT在各种不同的工作条件下都能正确工作。
总的来说,路科验证uvm是一种高效且可重用的验证方法学。
它提供了一个结构化的框架和一组强大的工具,用于验证硬件设计的正确性和功能性。
通过使用UVM,工程师可以更好地管理和控制验证过程,并提高验证效率。
uvm面试知识点
uvm面试知识点嘿,朋友们!咱今天来聊聊 UVM 面试那些知识点。
UVM 啊,就像是一座神秘的城堡,要想进去探秘,就得先把钥匙找对。
先说 UVM 中的 factory 机制吧,这就好比一个神奇的魔法工厂。
在这个工厂里,你可以按照自己的想法创造各种组件,而且还能灵活替换。
比如说,你原本设计了一个普通的士兵,可突然情况有变,你就能瞬间把他换成超级战士,是不是很厉害?这 factory 机制不就是给咱提供了这种神奇的能力嘛!再看看 UVM 的 sequence 机制,想象一下这是一场精彩的舞蹈表演。
sequence 就像是舞蹈的编排,它决定了各个动作的顺序和节奏。
你得精心设计,才能让整个表演流畅又精彩。
要是编排得不好,那这场“舞蹈”可就乱套啦!还有那 UVM 的 objection 机制,这简直就是交通信号灯。
它控制着整个验证环境的运行和停止。
就像马路上的车,得看着信号灯走,不然不就乱成一锅粥了嘛!UVM 的 callback 机制呢,就像是给你的作品来了个锦上添花。
它能在关键的时刻,按照你的想法来做点特别的事情,让整个验证工作更加完美。
说到 UVM 的 TLM 端口,这就像一条条高速公路,数据在上面快速地跑着。
不同的端口就像不同方向的道路,你得搞清楚它们,才能让数据准确无误地到达目的地。
对于 UVM 中的 phase 机制,这就像一场精心安排的演出流程。
每个阶段都有它独特的任务和重要性,少了哪个环节都不行。
在面试中,面试官可会深挖这些知识点哦。
他们会问你 factory 机制怎么实现高效的组件管理,sequence 怎么编排才能发挥最大作用,objection 怎么控制好流程,callback 怎么巧妙运用,TLM 端口怎么保证数据传输的准确和高效,phase 机制又如何确保整个流程的顺利进行。
所以啊,朋友们,要想在 UVM 面试中脱颖而出,这些知识点可得牢牢掌握,反复琢磨。
可别等到面试的时候,才发现自己像个迷路的小孩,找不到方向。
6.小白学uvm验证-寄存器模型
6.⼩⽩学uvm验证-寄存器模型 写过 verilog 硬件代码的同学应该都知道 DUT 会包含很多寄存器,它们是模块间交互的接⼝,其⽤途⼤致可以分为两类: a. 通过读出寄存器当前的值获取 DUT 当前的状态,该类寄存器称为状态寄存器; b. 通过对寄存器进⾏配置,可以使得 DUT ⼯作在⼀定模式下,该类寄存器称为配置寄存器。
在验证过程中,寄存器的验证是最新开始的,只有保证寄存器的配置正确,才能使得硬件之间的“交互”正确。
在验证寄存器配置是否正确的过程中,我们需要频繁的对 DUT 内部的寄存器进⾏读写操作,如 reference model 需要获取指定 reg 的参数值,在验证平台中我们获取DUT 内部寄存器的值的⽅式主要有两种: 前门访问(FRONTDOOR):启动 sequence 产⽣待操作寄存器的读写控制和地址,在 driver 中通过总线(Bus)驱动⾄DUT,并在 monitor 中采集 Bus 输出数据,该⽅式需要消耗仿真时间; 后门访问(BACKDOOR):在仿真环境中通过 DUT 实例名进⾏点操作,直接访问 DUT 内部的寄存器,该⽅式的缺点是,点操作需要通过绝对路径操作,如果寄存器数量庞⼤,会导致验证环境臃肿繁杂,容易出错。
因为上述操作的不利因素,才导致寄存器模型 ( RAL Model ) 产⽣。
1. 什么是寄存器模型 RAL Model 对应于 DUT 中的寄存器,RAL Model 中有 DUT 每⼀个寄存器的副本,它是真实硬件寄存器在软件环境中的⾏为模型;硬件寄存器的⼀个或多个 bit 的拼接称为⼀个域 ( field );多⼀个 field 形成⼀个 reg;多个 reg 构成⼀个块 ( block )。
uvm library 已经为我们定义好了上述⼏个概念,我们在使⽤时只需继承即可。
uvm_reg_field:这是寄存器模型中的最⼩单位。
uvm_reg:它⽐ uvm_reg_field ⾼⼀个级别,但是依然是⽐较⼩的单位。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
《UVM实战(卷1)》学习笔记看了第1/2/3/4/5/6/8/9.1 这几个章节。
第一章是综述,第二章是一个具体的例子,学习笔记从第三章相关内容开始。
我个人觉得UVM重要的部分(特点的部分):1)factory机制(override config_db)2)TLM传递3)phase机制4)sequence-sequencer 以及virtual seq/sqr内容中的截图基本来自于UVM源代码、书自带的例子和《uvm1.1应用指南及源代码分析》这个PDF里的。
需要结合书(《UVM实战(卷1)》第1版)来看这个笔记。
第3章UVM基础3.1 uvm_component和uvm_object常用的类名字:这个图是从作者张强的《uvm1.1应用指南及源代码分析》里截得,不如书上3.1.1里的图好。
uvm_sequencer也是代码里必须有的,所以我加了uvm_sequenceruvm_void是一个空的虚类。
在src/base/uvm_misc.svh中定义:红框的是我们搭testbench的时候用的比较多的基类。
常用的uvm_object派生类:sequencer给driver的transaction要派生自uvm_sequence_item,不要派生自uvm_transaction所有的sequence要派生自uvm_sequence或者uvm_sequence的派生类,可以理解为sequence是sequence_item的组合(集合)。
driver向sequencer索要item,sequencer检查是否有sequence要发送item,当发现有item待发送时,就把这个item发给driver.常用的uvm_component派生类:所有的driver要派生自uvm_driver. driver用来把sequence_item中的信息驱动到DUT端口上,从transaction-level向signal-level的转换。
uvm_driver需要参数(REQ RSP),比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.svhsequencer要派生自uvm_sequencer. sequencer做了很多扩展,但是如果我们自己写的因为sequencer在agent中例化,所以一般写在agent类文件里。
reference_model派生自uvm_component.agent要派生自uvm_agent. uvm_agent里多了一个is_active的成员。
一般根据这个active 来决定是否实例化driver和sequencer. is_active变量的数值需要在env的build_phase里设置完成(可以直接设置,也可以用uvm_config_db#(int)::set)。
env要派生自uvm_env. uvm_env没有对uvm_component扩展。
src/comps/uvm_env.svh所有的test都要派生自uvm_test或者它的派生类。
uvm_test也没扩展src/comps/uvm_test.svhuvm_object和uvm_component的macromacro非常重要,事关把这些类的对象注册到factory机制中去。
uvm_object macro1)对于uvm_sequence_item就统一用(假设不用parameter):2)对于uvm_sequence,要加上`uvm_object_utils(sequence 类名)可能还需要`uvm_declare_p_sequencer(sequencer类名)的声明uvm_component macro对于driver monitor reference_model scoreboard sequencer case agent env这些uvm_component派生类都要加上:`uvm_component_utils(类名)uvm_component里的成员也可以像uvm_object里成员一样,用field_automation机制。
field_automation机制:对于uvm_object派生类来说,field_automation机制让对象自动有的copy compare print pack unpack等函数,简化了实现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_int vs uvm_config_db#(bit[47:0]) 这个时候super.build_phase()是不起作用的。
想要起作用的话,需要用clone = new + copy 源代码中可以看到clone函数一上来会做一次create,然后调copy函数src/base/uvm_object.svh3.2 UVM的树形结构uvm_component的new/create要注意第一个参数是名字,第二个参数是parent指针。
UVM真正的树根是“uvm_top”. 根据上面这个树结构,可以看出一个个component 的parent是什么。
uvm_top的parent是null。
当一个component在实例化的时候,如果parent参数设成null,那么parent参数会被仿真器自动设置成uvm_root的实例uvm_top.在6.6.1章节里也提到了,sequence在uvm_config_db#()::get()的时候,第一个参数设成“null”,实际就是uvm_root::get() 3.5.1章节也提到了这个层次结构函数:get_parent() get_child(string name) 这两个分别获取parent指针和指定名字的child指针。
get_children(ref uvm_component children[$]) 获取所有的child指针get_num_children() 获取child个数get_first_child(ref string name) get_next_child(ref string name) 获取child的名字(反映到string name上),返回值是0/1两种情况应用参考代码如下(改动的2.5.2例子中的my_agent.sv):注意:上述代码是在connet_phase中实现的。
上述代码的打印结果如下:my_agent's name is uvm_test_top.env.i_agt, parent's full path is uvm_test_top.env, children num is 3uvm_test_top.env.i_agt 0 child: drv --> full path:uvm_test_top.env.i_agt.drvuvm_test_top.env.i_agt 1 child: mon --> full path:uvm_test_top.env.i_agt.monuvm_test_top.env.i_agt 2 child: sqr --> full path:uvm_test_top.env.i_agt.sqrThis should be i_agt. my_agent's name is uvm_test_top.env.i_agtuvm_test_top.env.i_agt first child name is drvuvm_test_top.env.i_agt next child name is monuvm_test_top.env.i_agt next child name is sqrmy_agent's name is uvm_test_top.env.o_agt, parent's full path is uvm_test_top.env, children num is 1uvm_test_top.env.o_agt 0 child: mon --> full path:uvm_test_top.env.o_agt.mon UVM_WARNING /tools/synopsys/vcs/G-2012.09/etc/uvm/src/base/uvm_component.svh(1846) @ 0: uvm_test_top.env.o_agt [NOCHILD] Component with name 'drv' is not a child of component 'uvm_test_top.env.o_agt'This should be o_agt. my_agent's name is uvm_test_top.env.o_agtuvm_test_top.env.o_agt first child name is mon3.3 field automation 机制注意数组类型的field macro比一般的要少real和event的macro. 一般的对于enum类型有3个参数,而数组的只有2个参数。
联合数组的macro比较多常用函数需要注意pack unpack pack_bytes unpack_bytes pack_ints unpack_ints 返回值都是bit个数。
field-automation标记位17bit中bit0→copy bit1→no_copy bit2→compare bit3→no_compare bit4→printbit5→no_print bit6→record bit7→no_record bit8→pack bit9→no_packUVM_ALL_ON是‘b000000101010101UVM_ALL_ON|UVM_NO_PACK 这样就会忽略掉pack bit这个is_vlan变量可以在sequence里约束成0或1,来实现vlan或非vlanps:我觉得这个地方代码其实写成像3.3.3里的有一个crc_error的rand bit的更合理一些。