路科验证UVM入门与进阶详解实验1
Posted dangdang爱章鱼
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了路科验证UVM入门与进阶详解实验1相关的知识,希望对你有一定的参考价值。
一、工厂的注册、创建和覆盖机制
知识点:
- 覆盖机制的必要性:有时候无法直接修改验证平台的代码,比如①别人正在用,修改会影响别人使用;②验证IP你没有办法直接看到,所以也无法修改。
- 作用:为了更方便地替代验证环境中的实例或者注册类型
- 核心三要素:注册、创建、覆盖
1、注册:要用uvm_component_utils()或者uvm_object_utils()注册
- uvm_component常见的组件有:uvm_driver、uvm_monitor、uvm_sequencer、uvm_agent、uvm_scoreboard、uvm_env、uvm_test,凡是继承他们的组件都需要用
uvm_component_utils()
进行注册;
除了上述提到的组件外,几乎所有的类都派生自uvm_object,常见的有uvm_sequence_item、uvm_sequence、config等
2、创建:UVM中创建实例的方法有很多,常用xxx::type_id::create来创建;注意,如果用new()来创建则无法使用工厂的覆盖
3、覆盖
覆盖并不是工厂机制的发明,所有面向对象的语言都支持函数/任务重载。
采用工厂进行覆盖有以下条件:
- 原类型和新类型都需要注册到工厂里&#x
DP0UVM进阶第一步,先学会UML
解读Design Pattern系列
UVM进阶第一步,先学会UML
作者 @吴杉 @辉太郎
进阶的方向
首先,我们需要将该系列文章的内容,限定在UVM体系内。毕竟,验证工程师,在工作的方方面面,如需求分解、时间管理、配置管理、项目沟通等诸多方面都需要进阶。而UVM的进阶,仅仅是这诸多方面中的一个方向。
然后,UVM的进阶本身,也包含诸多方向,验证平台架构设计也仅是其中一个方向。但基于设计模式的理解,可能是UVM进阶的诸多方向中,最迷人的一个。
进阶的工具
软件工程师,为了相互沟通的方便,定义了一套语言体系,称为UML(Unified Modeling Language统一建模语言)。
在《UML用户指南(第2版)》中,作者给出了建模要达到的4个目的:
1、模型有助于安装实际情况或按照所需要的样式对系统进行可视化;
2、模型能够规约系统的结构或行为;
3、模型给出了指导构造系统的模板;
4、模型对做出的决策进行文档化。
这里,我们可以先从可视化入手,看看UVM是怎么利用这套语言体系,来介绍UVM的。当然,我们默认你手边有《Universal Verification Methodology (UVM) 1.1 Class Reference》或《Universal Verification Methodology (UVM) 1.2 Class Reference》,本系列文章,不特别声明时,以UVM-1.2版本为例。
以下,介绍UML静态结构的实例,尽量以UVM中的结构为例。UVM中没有的结构,会给出语法示例。
UML静态结构:泛化
1、泛化(继承关系)
上图代表了继承关系,在UML的语境中,被称为泛化(Generalization)。
泛化的标识为:带三角箭头的实线,箭头指向父类。
上面的例子为uvm_object派生自uvm_void,uvm_report_object派生自uvm_object。
UML静态结构:实现
2、实现(接口的实现)
在UML的语境中,类与接口的关系,被称为实现。
实现的标识为:带三角箭头的虚线,箭头指向接口。
UVM中,没有使用interface的实例,此处仅以IEEE1800-2012的代码为例。其中,类B称为接口类A的实现,因此,为从B到A的带三角箭头的虚线。而C和B为泛化关系,C继承了B,所以为C到B的带三角箭头的实线。
UML静态结构:关联
3、关联(成员变量)
在UML的语境中,拥有关系被称为关联(Association)
关联的标识为:带普通箭头的实心线,指向被拥有者。
uvm_root拥有uvm_component,以及uvm_phase的成员变量。
解释1(虚线框):
虚线框代表不能直接实例化。
解释2(n..*):
n..*为n个到多个。图中uvm_root拥有1个到多个uvm_component,拥有8个到多个uvm_phase。
uvm_root中包含top_levels的队列:
至于uvm_root中包含8个到多个uvm_phase的源码,没有明确显示。
UML静态结构:聚合
4. 聚合(成员变量)
在UML的语境中,聚合关系(Aggregation)是关联关系的一种,是一种强的关联关系。关联和聚合在语法上无法区分,必须考察具体的逻辑关系。
普通关联关系的两个类处于同一层次上,而聚合关系的两个类处于不同的层次,一个是整体,一个是部分。同时,是一种弱的“拥有”关系。此时整体与部分之间是可分离的,他们可以具有各自的生命周期, 部分可以属于多个整体对象,也可以为多个整体对象共享;比如计算机与CPU、公司与员工的关系等。
聚合标识为:带空心菱形的实心线,菱形指向整体。
而在UVM-1.2中,并没有特别使用“带空心菱形的实心线”,我们可以假设UVM-1.2并没有区分“关联”和“聚合”。
UML静态结构:组合
5、组合(成员变量)
在UML的语境中,组合关系(Composition)是关联关系的一种,是比聚合关系还要强的关系,它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。
是整体与部分的关系,但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系,没有公司就不存在部门。
组合的标识为:带实心菱形的实线,菱形指向整体。
UVM-1.2的示例为uvm_component与uvm_phase,以及uvm_domain的关系。uvm_phase,uvm_domain是uvm_component的成员变量。uvm_phase、uvm_domain不能独立存在,它们必须借助于uvm_component存在。
UML静态结构:依赖
6、依赖(Dependency)
在UML的语境中,依赖关系是一种使用的关系,即一个类的实现需要另一个类的协助,所以要尽量不使用双向的互相依赖。
代码表现为:局部变量、方法的参数或者对静态方法的调用。
组合的标识为:带箭头的虚线,指向被使用者。
UVM-1.2的示例为transaction recording。uvm_tr_database被uvm_tr_stream包含(关联),uvm_tr_stream被uvm_recorder包含(关联)。而EDA厂商基于uvm_tr_database、uvm_tr_stream、uvm_recorder产生的类<tool>_tr_database、<tool>_tr_stream、<tool>_recorder则相互为依赖关系。<tool>_tr_database、<tool>_tr_stream、<tool>_recorder并不是后者的成员变量,但是,后者要实现,需要前者的定义。
实战演练
至此,六种关系:泛化(继承)、实现(接口类实现)、关联(成员变量)、聚合(不关心)、组合(成员变量)、依赖都已经介绍完了。我们可以用下面两个案例,做一下实战,看看掌握的情况。
纵向:uvm_report_object继承uvm_object,uvm_component继承自uvm_report_object,user-defined component继承自uvm_component;
横向:1个和多个uvm_report_object都包含1个uvm_report_handler,而多个uvm_report_handler都包含1个uvm_report_server。
uvm_reg、uvm_reg_field、uvm_reg_file、uvm_reg_block、uvm_reg_map、uvm_mem都继承与uvm_object;
my_reg继承与uvm_reg,my_block继承于uvm_reg_block、my_regfile继承于uvm_reg_file;
my_reg包含0到多个uvm_reg_field;my_regfile包含0个到多个my_reg,以及0个到多个my_regfile;uvm_reg_map包含0个到多个uvm_reg;uvm_mem包含uvm_mam(Memory allocation manager);
my_block为集大成者,包含0个到多个my_reg,0个到多个my_regfile、0个到多个uvm_reg_map,0个到多个uvm_mem,以及0个到多个my_block。
总结
泛化:继承关系,带三角箭头的实线,箭头指向父类;
实现:实现关系,带三角箭头的虚线,箭头指向接口;
关联:拥有关系,带普通箭头的实心线,指向被拥有者;
聚合:暂不使用;
组合:强拥有关系,带实心菱形的实线,菱形指向整体;
依赖:使用关系,带箭头的虚线,指向被使用者。
以上是关于路科验证UVM入门与进阶详解实验1的主要内容,如果未能解决你的问题,请参考以下文章
从零开始学习 UVM6.4UVM 激励产生 —— uvm_do 宏详解