uvm实战学习笔记
- 格式:docx
- 大小:41.96 KB
- 文档页数:24
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继承关系的使用是每个资深创作者的必备技能之一。
(*)题外话: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实战指南——第3部分第3部分:UVM实战在前两部分中,我们介绍了UVM框架的基本概念和基本用法。
在这一部分,我们将进一步探讨UVM的实际应用,并提供一些实战技巧和建议。
1.重要性分析在开始UVM实战前,首先需要进行重要性分析。
这包括确定哪些功能是需要覆盖的,哪些功能是必要的,以及哪些可能引发错误的功能需要特殊关注。
这些分析可以帮助您确定测试计划的优先级,并在测试开发过程中更好地分配资源。
2.测试计划开发根据重要性分析的结果,您可以开始开发测试计划。
测试计划应该详细描述实施哪些测试以及对每个测试的期望结果。
它还应包括测试开发和验证团队的人员分配和时间表安排。
通过制定清晰的测试计划,您可以确保测试开发工作有条不紊地进行,并及时识别和解决问题。
3.环境开发在开发测试计划后,您可以开始开发UVM环境。
环境是UVM中最关键的部分之一,它包含了用于模拟验证环境的各种组件和接口。
在环境开发过程中,您需要根据测试计划中的需求,选择和实例化适当的UVM组件,并将它们连接在一起以形成完整的验证环境。
4.测试用例开发测试用例是验证过程中的核心功能。
在开发测试用例时,您需要通过实例化适当的测试类,指定测试目标,并配置测试环境。
您还需要定义测试封包,设置或生成输入数据,以及从模拟输出中提取和分析结果。
测试用例的开发应该遵循UVM的最佳实践,并确保测试覆盖范围广泛且有效。
5.仿真运行和调试一旦测试用例开发完成,您可以开始运行仿真并进行调试。
在仿真过程中,您可能会遇到各种问题,如信号不正确、仿真停滞、错误输出等。
为了有效解决这些问题,您可以使用UVM提供的调试功能,如消息和日志记录、波形查看和追踪。
通过运用这些工具,您可以更快地找到问题所在,并采取适当的措施进行修复。
6.结果分析和测试报告当仿真运行完成后,您需要对结果进行分析,并生成测试报告。
在UVM中,您可以通过访问测试类中的结果和统计信息来执行结果分析。
您还可以使用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实战(卷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:下一代验证方法学Mark Glasser,方法学建构师2011年2月4日UVM是验证业界为自身研发的一种新验证方法学。
UVM代表着验证技术的最新进展,使用它可创建坚实、可重用、具互操作性的验证IP和测试流程(testbench)组件。
UVM最新奇、最令人兴奋的方面之一却是它是如何被开发的。
UVM不是由一家EDA供应商开发的,也并非作为营销活动的一部分而推出,它是由众多业内专家联合开发的,他们来自微处理器公司、网络公司、验证顾问机构以及EDA供应商。
UVM的全部开发工作是在Accellera(一个标准化组织,致力于开发电子设计自动化领域里的标准和开放接口)架构下完成的。
在一个标准组织的旗帜下,各家公司(其中一些是市场上的对手)才能够在协作的环境中携起手来,以迎战建构一个先进验证方法学所面临的技术挑战。
每位代表为这一协同努力都贡献了他们所在行业的专业知识和视角。
其结果是为建构验证环境贡献出一个强大、多维的软件层和方法学。
当然,UVM已经在主要EDA供应商的所有模拟器上都进行了测试。
UVM的确是种真正的行业创举,Mentor以亲历其中而自豪。
UVM并非从天而降。
它集许多独立验证方法学的成果之大成。
其承继的资产包括AVM、URM,VMM和OVM。
图1. UVM的继承UVM承继的这些方法学提供了UVM得以建立其上的丰富的方法学库。
最值得注意的是,OVM-2.1.1是UVM的“起点”,是UVM得以孕育成功的种子代码库。
因此,UVM与OVM最相近,且大体上向后兼容OVM。
作为VMM一部分的RAL 包被转化为UVM的寄存器功能。
虽然上面提到的一系列方法学是UVM得以成就的种子,但UVM并非其前辈代码的简单叠加。
UVM为测试流程(testbench)建构提供了新功能和新的使用模式,从而将验证方法学提升到一个新高度。
寄存器在现代SoC设计中,寄存器集合是作为设计的接口。
通过寄存器——器件得以复位和配置;数据得以接收和发送。
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上,进行仿真。
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(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(Universal Verification Methodology)是一种用于验证集成电路设计和系统级设计的方法学。
它提供了一种强大的框架,可以加速和规范验证过程,提高设计的质量和效率。
在《UVM实战》这本书中,通过讲解一系列示例,向读者介绍了UVM的基础知识和使用方法。
本书首先介绍了UVM的基本概念和工作原理。
UVM使用一种基于对象和类的面向对象方法来描述和组织验证环境。
它将验证环境划分为几个层次,包括顶层、环境、代理、驱动器、监视器等。
每个层次都包含不同的类和方法,用于实现不同的功能。
通过继承和实例化这些类,可以快速构建一个完整的验证环境。
接下来,本书介绍了UVM中的一些重要概念和方法。
例如,本书详细讲解了UVM的组件和接口。
组件是UVM中最基本的单元,用于实现特定的功能。
接口定义了组件之间的通信和数据交换方式。
UVM使用一种称为TLM(Transaction Level Modeling)的方法来进行通信,通过事务的方式传递数据。
本书还介绍了UVM中的一些重要机制,例如配置和工厂。
配置机制用于配置和管理验证环境中的各个组件和接口的参数。
它可以实现灵活的参数化配置,以适应不同的测试需求。
工厂机制用于管理对象的创建和销毁。
通过注册和继承,可以快速生成对象,并实现对象的多态。
本书还详细介绍了UVM中的测试用例和事务。
测试用例是验证环境中的最高层次,用于描述和控制验证过程。
测试用例可以包括多个事务,每个事务描述一个特定的操作或数据传输过程。
通过编写测试用例和事务,可以实现不同的功能和覆盖率要求。
最后,本书还介绍了一些高级的UVM特性和技术。
例如,本书介绍了UVM中的随机性和约束,用于实现随机的测试用例和事务。
本书还介绍了UVM中的一些重用机制,例如组件和测试用例的复用,以提高测试效率和质量。
通过《UVM实战》这本书的学习,我深入了解了UVM的基础知识和使用方法。
《UVM实战(卷1)》学习笔记看了第1/2/3/4/5/6/8/ 这几个章节。
第一章是综述,第二章是一个具体的例子,学习笔记从第三章相关内容开始。
我个人觉得UVM重要的部分(特点的部分):1)factory机制(override config_db)2)TLM传递3)phase机制4)sequence-sequencer 以及virtual seq/sqr内容中的截图基本来自于 UVM源代码、书自带的例子和《应用指南及源代码分析》这个PDF里的。
需要结合书(《UVM实战(卷1)》第1版)来看这个笔记。
第3章 UVM基础uvm_component和uvm_object常用的类名字:这个图是从作者张强的《应用指南及源代码分析》里截得,不如书上里的图好。
uvm_sequencer也是代码里必须有的,所以我加了uvm_sequencer uvm_void是一个空的虚类。
在src/base/中定义:红框的是我们搭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/)monitor/scoreboard 派生自 uvm_monitor和uvm_scoreboard,但是uvm_monitor和uvm_scoreboard并没有在uvm_component基础上做扩展。
src/comps/sequencer要派生自uvm_sequencer. 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/所有的test都要派生自uvm_test或者它的派生类。
uvm_test也没扩展src/comps/uvm_object和uvm_component的macromacro非常重要,事关把这些类的对象注册到factory机制中去。
uvm_object macro1)对于uvm_sequence_item就统一用(假设不用parameter):2可能还需要`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()的数值(必须加(phase))---- 也就是不用写 uvm_config_db#()::get()注意: field_automation的macro的类型要和uvm_config_db的参数类型一致:如下示例代码, field_int vs uvm_config_db#(bit[47:0]) 这个时候()是不起作用的。
想要起作用的话,需要用clone = new + copy 源代码中可以看到clone函数一上来会做一次create,然后调copy函数src/base/UVM的树形结构uvm_component的new/create要注意第一个参数是名字,第二个参数是parent指针。
UVM真正的树根是“uvm_top”. 根据上面这个树结构,可以看出一个个component的parent是什么。
uvm_top的parent是null。
当一个component在实例化的时候,如果parent参数设成null,那么parent参数会被仿真器自动设置成uvm_root的实例uvm_top.在章节里也提到了,sequence在uvm_config_db#()::get()的时候,第一个参数设成“null”,实际就是uvm_root::get() 章节也提到了这个层次结构函数: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两种情况应用参考代码如下(改动的例子中的):注意:上述代码是在connet_phase中实现的。
上述代码的打印结果如下:This should be i_agt. my_agent's name is uvm_test1field automation 机制注意数组类型的field macro比一般的要少real和event的macro. 一般的对于enum类型有3个参数,而数组的只有2个参数。
联合数组的macro 比较多常用函数需要注意 pack unpack pack_bytes unpack_bytes pack_ints unpack_ints 返回值都是bit个数。
field-automation标记位17bit中 bit0copy bit1no_copy bit2compare bit3no_compare bit4print bit5no_print bit6record bit7no_record bit8pack bit9no_packUVM_ALL_ON是‘UVM_ALL_ON|UVM_NO_PACK 这样就会忽略掉pack bitfield-automation的macro可以和if结合起来,参考的代码或非vlan ps rand bitcrc是起上述函数都是在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=10我觉得应该用不大到,就不做笔记了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函数里有(phase)那么可以省略get语句跨层次多重set的时候,看set的第一个参数,层级越高,优先级越高。
调用set的时候,第一个参数尽量使用this同层次设置的时候是时间优先非直线设置的时候注意第一和第二参数的使用,如果需要parent指针,则要用config_db机制支持通配符,但是作者不推荐使用通配符。
但是在对sequence的成员set的时候需要用通配符(章节)。
使用如下函数调试 config_dbcheck_config_usage() print_config(1/0) 这两个函数在connect_phase 函数中调simv +UVM_CONFIG_DB_TRACE注意:第二个参数设置错误不会报错!!------- config_db机制务必要注意参数的书写。
第4章 UVM中的通信TLM 是Transaction Level Modeling缩写这章要搞清楚 port export imp fifo以及几种操作function/task 和对应component中要实现的function/task下面的箭头方向都是控制流的方向,不是数据流方向。
我觉得作为一个VMM用户会觉得TLM有点难理解,总想用VMM_CHANNEL去套,结果把自己搞晕。
像port等其实是调imp所在component的task/function.我看UVM源代码里有一个uvm_seq_item_pull_port的class,它的基类是uvm_port_base. 在uvm_driver的成员seq_item_port就是这个类型的。