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 基础知识
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的特性和提供丰富的验证组件和功能,可以帮助验证工程师更高效地进行硬件设计验证。
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(Universal Verification Methodology)是一种验证方法学,用于验证集成电路设计的正确性。
UVM的目标是提供一种可重用的、可扩展的、可配置的验证框架,可以适用于不同规模和复杂度的设计。
以下是UVM相关的要点。
1.UVM基本概念:UVM基于SystemVerilog语言,结构化验证环境,采用面向对象的设计方法。
它提供了一套验证组件,包括验证环境(env),顶层测试(test),驱动(driver),监视器(monitor),事务(transaction)等。
通过配置和连接这些组件,可以创建一个完整的验证环境。
2.UVM构建模块:3.UVM构建方法:UVM采用构建块方法构建验证环境。
首先,创建UVC,对外部接口进行建模,并实现相应的驱动和监视器。
然后,创建UVM Testbench,配置和连接UVC,并实现顶层测试。
最后,创建UVM Testcase,定义测试数据和验证规则。
4.UVM验证过程:UVM的验证过程包括四个阶段:创建、配置、运行和收尾。
在创建阶段,实例化UVM Testbench和UVM Testcase,并配置UVC。
在配置阶段,连接组件,设置参数和启动模拟器。
在运行阶段,执行测试,并生成日志和报告。
在收尾阶段,清理资源,关闭模拟器。
5.UVM核心概念:UVM的核心概念包括交易、序列、驱动、监视器和函数。
交易是验证过程中传递的数据包,包含信号、地址、数据和控制信息。
序列是交易的序列化表示,可以定义多个交易之间的顺序关系。
驱动是产生和驱动交易的组件,负责发送交易到被测对象。
监视器是接收和监视交易的组件,负责检查交易的正确性。
函数是UVM中的工具函数,用于处理和操作交易和序列。
6.UVM高级特性:UVM提供了一些高级特性,如配置管理、消息传递、注解和覆盖率。
配置管理是通过配置文件和命令行参数来配置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学习笔记(⼀)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基础总结——基于《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实战指南-第四章
% irun -uvm myfile.sv
使用非仿真器自带的 UVM 库,使用命令行:
% irun -uvmhome $UVM _HOME myfile.sv
4.2 基本类
实例 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 参考手册。
4
Design IC
/
electron64@
4.3.2 uvm_object 定义指南
建议从 uvm_sequence_item 继承对象,此方式能够给对象增加一些额外的域,同时允许对象成 为 uvm_sequence 随机的一部分。
Design IC
/
electron64@
UVM 实战指南第四章
UVM 是功能验证的第一个最佳实践和方法学。如之前提到,UVM 实现了成熟的高级验证方法。尽管其类 库可以任意使用,我们强烈建议按照后续章节描述的方式来使用,因为这些方式源自于成功经验。
UVM_知识点测试
UVM_知识点测试UVM(Universal Verification Methodology)是由电子设计自动化(EDA)工具供应商提出的一种验证方法学,用于开发和验证硬件描述语言(HDL)模型的正确性。
UVM为测试工程师提供了一种结构化和可重用的验证环境,使他们可以更简单地编写,管理和执行测试。
UVM使用SystemVerilog作为验证环境和测试用例开发的语言。
UVM 提供了一种面向对象的验证方法学,它基于Verilog和VHDL等语言的验证方法学,同时引入了诸如高级配置,事务和重用性等新概念。
UVM的主要特点包括以下几个方面:1. 四个部分组成:UVM由四个主要部分组成,分别是顶层环境(top-level environment),顺序性容器(sequence container),交易级模型(transaction-level model)和测试用例(testcase)。
这四个部分组合在一起,为测试工程师提供了一个用于创建和管理验证环境的框架。
2.面向对象:UVM使用面向对象的方法编写验证环境和测试用例。
验证环境的构建是通过创建各种类和对象来实现的,这些类和对象之间可以进行继承和组合。
测试用例也是通过继承的方式创建的,使得可以重用已有的验证环境和测试用例。
3.事务级建模:UVM引入了交易级模型的概念,通过使用事务建模语法,可以描述信号和数据的传输。
这样可以更简单地描述和操作设计的功能,并且减少验证环境和测试用例的复杂度。
4.高级配置和重用性:UVM提供了一种灵活的配置机制,使测试工程师可以根据需要灵活配置验证环境。
此外,UVM还支持验证组件的重用,通过创建可重用的验证组件,可以提高验证环境的开发效率和测试用例的复用性。
UVM的工作原理如下:1.创建验证环境:首先,测试工程师需要创建一个验证环境,该环境包含了待验证模块的所有必要信号和接口。
验证环境可以通过继承和组合各种验证组件来创建,其中包括信号生成器,响应生成器,监视器等。
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实战》读书笔记思维导图
第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中各种端 口的互连
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 ⾼⼀个级别,但是依然是⽐较⼩的单位。
UVM验证实习经历
UVM验证实习经历
通用验证方法学(Universal Verification Methodology, UVM)是一个以SystemVerilog类库为主体的验证平台开发框架,验证工程师可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境。
过来最开始的一周主要是熟悉环境。
正好赶上7月入职的培训,跟着一起参加基础培训,内容是SV的绿皮书和UVM的白皮书。
实习过程中的主要工作是读spec,然后根据需求写相应的case。
关于具体的工作内容就不透露了。
整个实习的收获非常多,除了基本的验证工程师技能SV、UVM这些,在实习过程中接触了VCS、verdi等工具,其次熟悉了一些脚本语言。
最重要的,我个人觉得是对整个芯片行业有了一个初步的了解。
在实习的期间还是比较愉快的,有每周的羽毛球团建活动,有节日的团建聚餐,有小伙伴的生日活动等,过得还是挺有意思的。
最后是非常感谢在快结束实习时毫无保留地说了很多中肯的意见,谈了一下关于职业发展的方向等东西。
如果打算留下来,在临近最后一周左右,会有一个HRD的面试,再综合主管的意见决定offer。
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函数。
- 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 做了很多扩展,但是如果我们自己写的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)对于2)对于对于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中实现的。
上述代码的打印结果如下:This should be i_agt. my_agent's name is uvm_test13.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✍print bit5✍no_printbit6✍record bit7✍no_record bit8✍pack bit9✍no_packUVM_ALL_ON是‘UVM_ALL_ON|UVM_NO_PACK 这样就会忽略掉pack bit这个ps:我觉得这个地方代码其实写成像3.3.3里的有一个crc_error的rand bit的更合理一些。
然后crc_error是UVM_ALL_ON|UVM_NOPACK,而crc是UVM_ALL_ON3.4 UVM打印信息控制get_report_verbosity_level()set_report_verbosity_level(UVM_HIGH) 只对当前调用的component起作用set_report_verbosity_level_hier(UVM_HIGH) 对当前及下面所有的component起作用simv +UVM_VERBOSITY=UVM_HIGH 命令行方式------ 我觉得用这个就可以了重载打印信息:set_report_severity_override(UVM_WARNING,UVM_ERROR);上述函数都是在connect_phase及后面的phase使用设置UVM_ERROR到达一定数量结束仿真set_report_max_quit_count(int) 设成0就是无论多少error都不退出get_report_max_quit_count() 返回如果是0,说明无论多少error都不退出设置在main_phase前调用。
simv +UVM_MAX_QUIT_COUNT=103.4.4 3.4.5 3.4.6 3.4.7 我觉得应该用不大到,就不做笔记了3.5 config_db机制uvm_config_db#(类型)::set/get(component指针,”…”,”变量名字”,para4)都是4个参数:第一个参数是一个component指针,如果是null的话,相当于uvm_root::get()第二个参数是个路径字符串,第一和第二两个参数组和成一个完整的路径第三个参数对于set、get要完全一致,是变量名字set的para4是数值,get的para4是变量component中的成员变量如果:1)component用uvm_component_utils宏注册2)变量用field-automation宏注册3)component的build_phase函数里有super.build_phase(phase)那么可以省略get语句跨层次多重set的时候,看set的第一个参数,层级越高,优先级越高。
调用set的时候,第一个参数尽量使用this同层次设置的时候是时间优先非直线设置的时候注意第一和第二参数的使用,如果需要parent指针,则要用this.m_parent config_db机制支持通配符,但是作者不推荐使用通配符。