精华内容
下载资源
问答
  • UVM实战 卷 I pdf

    2017-09-27 09:28:10
    UVM实战 卷 I pdf UVM实战 卷 I pdf UVM实战 卷 I pdf UVM实战 卷 I pdf UVM实战 卷 I pdf UVM实战 卷 I pdf UVM实战 卷 I pdf
  • UVM实战教程

    2017-07-06 10:54:15
    UVM实战教程
  • UVM实战笔记

    2018-08-27 11:00:24
    UVM实战的笔记总结。内容中的截图基本来自于 UVM源代码、书自带的例子和《uvm1.1应用指南及源代码分析》这个PDF里的。 需要结合书(《UVM实战(卷1)》第1版)来看这个笔记。
  • UVM实战,UVM书籍

    2016-08-08 17:18:38
    UVM实战,有一定的价值,入门的资源
  • UVM实战 张强

    2019-07-12 16:19:13
    UVM实战》主要介绍UVM的使用。全书详尽介绍了UVM的factory机制、sequence机制、phase机制、objection机制及寄存器模型等的使用。本书主要面向UVM的初学者及想对UVM追根寻底的中级用户。针对没有面向对象编程基础的...
  • UVM实战以及源代码

    2018-08-30 08:20:56
    本书是张强编著的《UVM实战卷1》,是国内UVM验证方法学书籍类的始祖,压缩包内包含了《UVM实战卷1》高清图书,带有目录,以及配套的源代码。还有作者之前的书籍《UVM1.1应用指南及源码分析》,需要学习UVM验证方法学...
  • uvm实战源码.rar

    2019-07-12 16:21:56
    uvm实战源码,附带uvm1.1d库,可以对照着书籍,直接用源码来进行书上的实验
  • UVM实战 第一卷

    热门讨论 2016-02-23 06:51:56
    UVM实战书籍 网络版,主要讲解UVM验证,内容较为详细
  • UVM实战示例代码

    热门讨论 2015-05-31 20:54:48
    UVM实战example_and_uvm_source_code.tar.gz 资源是从华章出版社官网下载的
  • UVM实战代码例子

    2016-01-10 20:36:40
    UVM实战》是国内目前唯一一本用研究的眼光解读如何基于UVM搭建验证平台的著作。 作者历时3年钻研UVM源代码和使用UVM经验的系统总结。 实例丰富,步步清晰地引导读者掌握UVM的精髓和实用技巧。 本书脱胎于网络上...
  • UVM实战(卷1)

    2019-03-28 20:27:02
    UVM实战(卷1) 目录: 第一章:与UVM的第一次接触 第二章:一个简单的UVM验证平台 第三章:UVM基础 第四章:UVM中的TLM1.0通信 第五章:UVM验证平台的运行 第六章:UVM中的sequence 第七章:UVM中的寄存器模型 第八...
  • uvm实战卷1 芯片验证圣书

    热门讨论 2015-08-15 19:29:35
    uvm实战卷1 芯片验证圣书 电子与嵌入式系统设计丛书 UVM实战 张强 著
  • UVM实战第一卷

    2017-10-13 09:48:58
    UVM实战》主要介绍UVM的使用。全书详尽介绍了UVM的factory机制、sequence机制、phase机制、objection机制及寄存器模型等的使用。此外,本书还试图引导读者思考UVM为什么要引入这些机制,从而使读者知其然,更知其...
  • uvm实战env设置

    2021-03-12 13:18:54
    uvm实战env设置 env环境变量设置 #!/bin/csh source /cad/release/etc/cshrc.mentor setenv QUESTA_HOME /cad/release/mentor/questasim/10.2/questasim setenv UVM_HOME ~/uvm/uvm-1.1d setenv WORK_HOME `pwd` ...

    uvm实战env设置
    env环境变量设置

    #!/bin/csh
    
    source /cad/release/etc/cshrc.mentor
    setenv QUESTA_HOME /cad/release/mentor/questasim/10.2/questasim
    setenv UVM_HOME ~/uvm/uvm-1.1d
    setenv WORK_HOME `pwd`
    setenv SIM_TOOL QUESTA 
    set path = (/cad/release/mentor/questasim/10.2/questasim/bin ${WORK_HOME}/bin $path)
    #setenv UVM_HOME /cad/release/mentor/questasim/10.2/questasim/verilog_src/uvm-1.1c
    #setenv UVM_DPI_DIR /cad/release/mentor/questasim/10.2/questasim/uvm-1.1c/linux
    setenv UVM_DPI_DIR $WORK_HOME/uvm_dpi
    mkdir $UVM_DPI_DIR -p
    g++ $UVM_HOME/src/dpi/uvm_dpi.cc -D QUESTA -I$UVM_HOME/src/dpi -I$QUESTA_HOME/include -shared -Bsymbolic -o $UVM_DPI_DIR/uvm_dpi.so
    
    
    展开全文
  • UVM实战(卷Ⅰ).pdf

    2019-05-23 16:20:54
    UVM实战(卷Ⅰ),uvm验证方法学,很有用的一本书,希望对大家有帮助
  • 阅读张强老师的白皮书《UVM实战》做的一些总结笔记~主要是总结书中后面几章的内容 具体讲解部分代码 可对着白皮书进行学习
  • UVM实战(卷I)张强著,内容清晰,内含书签,IC验证必备书籍
  • UVM实战(卷Ⅰ) - 张强

    2016-09-08 23:57:26
    UVM实战(卷Ⅰ) - 张强
  • UVM实战(卷Ⅰ)

    2019-02-28 17:43:36
    UVM实战pdf版,自带目录可以复制文档内内容 验证使用的语言五花八门,很难统计出到底有多少种语言曾经被用于验证,且验证这个词是从什么时候开始独立出现的也有 待考证。验证是服务于设计的,目前来说,有两种通用的...
  • UVM实战作者:张强出版日期:2014年08月文件大小:6.20M支持设备:¥50.00在线试读适用客户端:言商书局iPad/iPhone客户端:下载 Android客户端:下载PC客户端:下载更多详情:查看?对图书下载、阅读卡购买有疑问:...

    UVM实战

    作者:张强

    出版日期:2014年08月

    文件大小:6.20M

    支持设备:

    ¥50.00在线试读

    适用客户端:

    言商书局

    iPad/iPhone客户端:下载 Android客户端:下载PC客户端:下载更多详情:查看

    ?对图书下载、阅读卡购买有疑问:立即进入帮助中心>>

    图书简介

    目录

    本书主要介绍uvm的使用。全书详尽介绍了uvm的factory机制、sequence机制、phase机制、objection机制及寄存器模型等的使用。此外,本书还试图引导读者思考uvm为什么要引入这些机制,从而使读者知其然,更知其所以然。本书以一个完整的示例开篇,使得读者一开始就对如何使用uvm搭建验证平台有总体的概念。本书提供大量示例代码,这些代码都经过实际的运行。全书内容力求简单易懂,尽量将uvm中的概念与读者已有的概念联系起来。在第11章还专门介绍了ovm与uvm的区别,为那些从ovm迁移到uvm的用户提供很大帮助。

    前言

    第1章 与UVM的第一次接触

    1.1 UVM是什么

    1.1.1 验证在现代IC流程中的位置

    1.1.2 验证的语言

    1.1.3 何谓方法学

    1.1.4 为什么是UVM

    1.1.5 UVM的发展史

    1.2 学了UVM之后能做什么

    1.2.1 验证工程师

    1.2.2 设计工程师

    第2章 一个简单的UVM验证平台

    2.1 验证平台的组成

    2.2 只有driver的验证平台

    *2.2.1 最简单的验证平台

    *2.2.2 加入factory机制

    *2.2.3 加入objection机制

    *2.2.4 加入virtual interface

    2.3 为验证平台加入各个组件

    *2.3.1 加入transaction

    *2.3.2 加入env

    *2.3.3 加入monitor

    *2.3.4 封装成agent

    *2.3.5 加入reference model

    *2.3.6 加入scoreboard

    *2.3.7 加入field_automation机制

    2.4 UVM的终极大作:sequence

    *2.4.1 在验证平台中加入sequencer

    *2.4.2 sequence机制

    *2.4.3 default_sequence 的使用

    2.5 建造测试用例

    *2.5.1 加入base_test

    *2.5.2 UVM中测试用例的启动

    第3章 UVM基础

    3.1 uvm_component与uvm_object

    3.1.1 uvm_component派生自uvm_object

    3.1.2 常用的派生自uvm_object的类

    3.1.3 常用的派生自uvm_component的类

    3.1.4 与uvm_object相关的宏

    3.1.5 与uvm_component相关的宏

    3.1.6 uvm_component的限制

    3.1.7 uvm_component与uvm_object的二元结构

    3.2 UVM的树形结构

    3.2.1 uvm_component中的parent参数

    3.2.2 UVM树的根

    3.2.3 层次结构相关函数

    3.3 field automation机制

    3.3.1 field automation机制相关的宏

    3.3.2 field automation机制的常用函数

    *3.3.3 field automation机制中标志位的使用

    *3.3.4 field automation中宏与if的结合

    3.4 UVM中打印信息的控制

    *3.4.1 设置打印信息的冗余度阈值

    *3.4.2 重载打印信息的严重性

    *3.4.3 UVM_ERROR到达一定数量结束仿真

    *3.4.4 设置计数的目标

    *3.4.5 UVM的断点功能

    *3.4.6 将输出信息导入文件中

    *3.4.7 控制打印信息的行为

    3.5 config_db机制

    3.5.1 UVM中的路径

    3.5.2 set与get函数的参数

    *3.5.3 省略get语句

    *3.5.4 跨层次的多重设置

    *3.5.5 同一层次的多重设置

    *3.5.6 非直线的设置与获取

    *3.5.7 config_db机制对通配符的支持

    *3.5.8 check_config_usage

    3.5.9 set_config与get_config

    3.5.10 config_db的调试

    第4章 UVM中的TLM1.0通信

    4.1 TLM1.0

    4.1.1 验证平台内部的通信

    4.1.2 TLM的定义

    4.1.3 UVM中的PORT与EXPORT

    4.2 UVM中各种端口的互连

    *4.2.1 PORT与EXPORT的连接

    *4.2.2 UVM中的IMP

    *4.2.3 PORT与IMP的连接

    *4.2.4 EXPORT与IMP的连接

    *4.2.5 PORT与PORT的连接

    *4.2.6 EXPORT与EXPORT的连接

    *4.2.7 blocking_get端口的使用

    *4.2.8 blocking_transport端口的使用

    4.2.9 nonblocking端口的使用

    4.3 UVM中的通信方式

    *4.3.1 UVM中的analysis端口

    *4.3.2 一个component内有多个IMP

    *4.3.3 使用FIFO通信

    4.3.4 FIFO上的端口及调试

    *4.3.5 用FIFO还是用IMP

    第5章 UVM验证平台的运行

    5.1 phase机制

    *5.1.1 task phase与function phase

    5.1.2 动态运行phase

    *5.1.3 phase的执行顺序

    *5.1.4 UVM树的遍历

    5.1.5 super.phase的内容

    *5.1.6 build阶段出现UVM_ERROR停止仿真

    *5.1.7 phase的跳转

    5.1.8 phase机制的必要性

    5.1.9 phase的调试

    5.1.10 超时退出

    5.2 objection机制

    *5.2.1 objection与task phase

    *5.2.2 参数phase的必要性

    5.2.3 控制objection的最佳选择

    5.2.4 set_drain_time的使用

    *5.2.5 objection的调试

    5.3 domain的应用

    5.3.1 domain简介

    *5.3.2 多domain的例子

    *5.3.3 多domain中phase的跳转

    第6章 UVM中的sequence

    6.1 sequence基础

    6.1.1 从driver中剥离激励产生功能

    *6.1.2 sequence的启动与执行

    6.2 sequence的仲裁机制

    *6.2.1 在同一sequencer上启动多个sequence

    *6.2.2 sequencer的lock操作

    *6.2.3 sequencer的grab操作

    6.2.4 sequence的有效性

    6.3 sequence相关宏及其实现

    6.3.1 uvm_do系列宏

    *6.3.2 uvm_create与uvm_send

    *6.3.3 uvm_rand_send系列宏

    *6.3.4 start_item与finish_item

    *6.3.5 pre_do、mid_do与post_do

    6.4 sequence进阶应用

    *6.4.1 嵌套的sequence

    *6.4.2 在sequence中使用rand类型变量

    *6.4.3 transaction类型的匹配

    *6.4.4 p_sequencer的使用

    *6.4.5 sequence的派生与继承

    6.5 virtual sequence的使用

    *6.5.1 带双路输入输出端口的DUT

    *6.5.2 sequence之间的简单同步

    *6.5.3 sequence之间的复杂同步

    6.5.4 仅在virtual sequence中控制objection

    *6.5.5 在sequence中慎用fork join_none

    6.6 在sequence中使用config_db

    *6.6.1 在sequence中获取参数

    *6.6.2 在sequence中设置参数

    *6.6.3 wait_modified的使用

    6.7 response的使用

    *6.7.1 put_response与get_response

    6.7.2 response的数量问题

    *6.7.3 response handler与另类的response

    *6.7.4 rsp与req类型不同

    6.8 sequence library

    6.8.1 随机选择sequence

    6.8.2 控制选择算法

    6.8.3 控制执行次数

    6.8.4 使用sequence_library_cfg

    第7章 UVM中的寄存器模型

    7.1 寄存器模型简介

    *7.1.1 带寄存器配置总线的DUT

    7.1.2 需要寄存器模型才能做的事情

    7.1.3 寄存器模型中的基本概念

    7.2 简单的寄存器模型

    *7.2.1 只有一个寄存器的寄存器模型

    *7.2.2 将寄存器模型集成到验证平台中

    *7.2.3 在验证平台中使用寄存器模型

    7.3 后门访问与前门访问

    *7.3.1 UVM中前门访问的实现

    7.3.2 后门访问操作的定义

    *7.3.3 使用interface进行后门访问操作

    7.3.4 UVM中后门访问操作的实现:DPI+VPI

    *7.3.5 UVM中后门访问操作接口

    7.4 复杂的寄存器模型

    *7.4.1 层次化的寄存器模型

    *7.4.2 reg_file的作用

    *7.4.3 多个域的寄存器

    *7.4.4 多个地址的寄存器

    *7.4.5 加入存储器

    7.5 寄存器模型对DUT的模拟

    7.5.1 期望值与镜像值

    7.5.2 常用操作及其对期望值和镜像值的影响

    7.6 寄存器模型中一些内建的sequence

    *7.6.1 检查后门访问中hdl路径的sequence

    *7.6.2 检查默认值的sequence

    *7.6.3 检查读写功能的sequence

    7.7 寄存器模型的高级用法

    *7.7.1 使用reg_predictor

    *7.7.2 使用UVM_PREDICT_DIRECT功能与mirror操作

    *7.7.3 寄存器模型的随机化与update

    7.7.4 扩展位宽

    7.8 寄存器模型的其他常用函数

    7.8.1 get_root_blocks

    7.8.2 get_reg_by_offset函数

    第8章 UVM中的factory机制

    8.1 SystemVerilog对重载的支持

    *8.1.1 任务与函数的重载

    *8.1.2 约束的重载

    8.2 使用factory机制进行重载

    *8.2.1 factory机制式的重载

    *8.2.2 重载的方式及种类

    *8.2.3 复杂的重载

    *8.2.4 factory机制的调试

    8.3 常用的重载

    *8.3.1 重载transaction

    *8.3.2 重载sequence

    *8.3.3 重载component

    8.3.4 重载driver以实现所有的测试用例

    8.4 factory机制的实现

    8.4.1 创建一个类的实例的方法

    *8.4.2 根据字符串来创建一个类

    8.4.3 用factory机制创建实例的接口

    8.4.4 factory机制的本质

    第9章 UVM中代码的可重用性

    9.1 callback机制

    9.1.1 广义的callback函数

    9.1.2 callback机制的必要性

    9.1.3 UVM中callback机制的原理

    *9.1.4 callback机制的使用

    *9.1.5 子类继承父类的callback机制

    9.1.6 使用callback函数/任务来实现所有的测试用例

    9.1.7 callback机制、sequence机制和factory机制

    9.2 功能的模块化:小而美

    9.2.1 Linux的设计哲学:小而美

    9.2.2 小而美与factory机制的重载

    9.2.3 放弃建造强大sequence的想法

    9.3 参数化的类

    9.3.1 参数化类的必要性

    *9.3.2 UVM对参数化类的支持

    展开全文
  • UVM实战》——1.1节UVM是什么

    千次阅读 2019-06-15 21:27:53
    目录 第1章 ...本节书摘来自华章社区《UVM实战》一书中的第1章,第1.1节UVM是什么,作者 张 强 第1章 与UVM的第一次接触 1.1 UVM是什么 1.1.1 验证在现代IC流程中的位置 现代IC(Inte...

    目录

    第1章

    1.1 UVM是什么

    1.1.1 验证在现代IC流程中的位置

    1.1.2 验证的语言

    1.1.4 为什么是UVM

    1.1.5 UVM的发展史


     

    本节书摘来自华章社区《UVM实战》一书中的第1章,第1.1节UVM是什么,作者 张 强

    第1章

    与UVM的第一次接触

    1.1 UVM是什么

    1.1.1 验证在现代IC流程中的位置

            现代IC(Integrated circuit,集成电路)前端的设计流程如图1-1所示。通常的IC设计是从一份需求说明书开始的,这份需求说明书一般来自于产品经理(有些公司可能没有单独的职位,而是由其他职位兼任)。从需求说明书开始,IC工程师会把它们细化为特性列表设计工程师根据特性列表,将其转化为设计规格说明书,在这份说明书中,设计工程师会详细阐述自己的设计方案,描述清楚接口时序信号,使用多少RAM资源,如何进行异常处理等。验证工程师根据特性列表,写出验证规格说明书。在验证规格说明书中,将会说明如何搭建验证平台,如何保证验证完备性,如何测试每一条特性,如何测试异常的情况等。

    当设计说明书完成后,设计人员开始使用Verilog(或者VHDL,这里以Verilog为例)将特性列表转换成RTL代码,而验证人员则开始使用验证语言(这里以SystemVerilog为例)搭建验证平台,并且着手建造第一个测试用例(test case)。当RTL代码完成后,验证人员开始验证这些代码(通常被称为DUT(Design Under Test),也可以称为DUV(Design Under Verification),本书统一使用DUT)的正确性。
    验证主要保证从特性列表到RTL转变的正确性,包括但不限于以下几点:

    • DUT的行为表现是否与特性列表中要求的一致。
    • DUT是否实现了所有特性列表中列出的特性。
    • DUT对于异常状况的反应是否与特性列表和设计规格说明书中的一致,如中断是否置起。
    • DUT是否足够稳健,能够从异常状态中恢复到正常的工作模式。

    1.1.2 验证的语言

            验证使用的语言五花八门,很难统计出到底有多少种语言曾经被用于验证,且验证这个词是从什么时候开始独立出现的也有待考证。验证是服务于设计的,目前来说,有两种通用的设计语言:Verilog和VHDL。伴随着IC的发展,Verilog由于其易用性,在IC设计领域占据了主流地位,使用VHDL的人越来越少。

    基于Verilog的验证语言主要有如下三种:


    1)Verilog:Verilog是针对设计的语言。Verilog起源于20世纪80年代中期,并在1995年正式成为IEEE标准,即IEEE Standard 1364TM—1995。其后续版本是2001年推出的,与1995版差异比较大。很多Verilog仿真器中都会提供一个选项来决定使用1995版还是2001版。目前最新的标准是2005年推出的,即IEEE Standard 1364TM—2005,它与2001版的差距不大。验证起源于设计,在最初的时候是没有专门的验证的,验证与设计合二为一。考虑到这种现状,Verilog在其中还包含了一个用于验证的子集,其中最典型的语句就是initialtaskfunction纯正的设计几乎是用不到这些语句的。通过这些语句的组合,可以给设计施加激励,并观测输出结果是否与期望的一致,达到验证的目的。

           Verilog在验证方面最大的问题是功能模块化、随机化验证上的不足,这导致更多的是直接测试用例(即direct test case,激励是固定的,其行为也是固定的),而不是随机的测试用例(即random test case,激励在一定范围内是随机的,可以在几种行为间选择一种)。笔者亲身经历过一个使用Verilog编写的设计,包含有6000多个测试用例。假如使用SystemVerilog,这个数字至少可以除以10。



    2)SystemC:IC行业按照摩尔定律快速发展,晶体管的数量越来越多,整个系统越来越复杂。此时,单纯的Verilog验证已经难以满足条件。1999年,OSCI(Open SystemC Initiative)成立,致力于SystemC的开发。

    通常来说,可以笼统地把IC分为两类:

           一类是算法需求比较少的,如网络通信协议;

            另一类是算法需求非常复杂的,如图形图像处理等。

          那些对算法要求非常高的设计在使用Verilog编写代码之前,会使用C或者C++建立一个算法模型,即参考模型(reference model),在验证时需要把此参考模型的输出与DUT的输出相比,因此需要在设计中把基于C++/C的模型集成到验证平台中。SystemC本质上是一个C++的库,这种天然的特性使得它在算法类的设计中如鱼得水。当然,在非算法类的设计中,SystemC也表现得相当良好。SystemC最大的优势在于它是基于C++的,但这也是它最大的劣势。在C++中,用户需要自己管理内存,指针会把所有人搞得头大,内存泄露是所有C++用户的噩梦。除了内存泄露的问题外,SystemC在构建异常的测试用例时显得力不从心,因此现在很多公司已经转向使用SystemVerilog。



    3)SystemVerilog:它是一个Verilog的扩展集,可以完全兼容Verilog。它起源于2002年,并在2005年成为IEEE的标准,即IEEE 1800TM—2005,目前最新的版本是IEEE 1800TM—2012。SystemVerilog刚一推出就受到了热烈欢迎,它具有所有面向对象语言的特性:封装、继承和多态,同时还为验证提供了一些独有的特性,如约束(constraint)功能覆盖率(functional coverage)。由于其与Verilog完全兼容,很多使用Verilog的用户可以快速上手,且其学习曲线非常短,因此很多原先使用Verilog做验证的工程师们迅速转到SystemVerilog。

            在与SystemC的对比中,SystemVerilog也不落下风,它提供了DPI接口,可以把C/C++的函数导入SystemVerilog代码中,就像这个函数是用SystemVerilog写成的一样。与C++相比,SystemVerilog语言本身提供内存管理机制,用户不用担心内存泄露的问题。除此之外,它还支持系统函数$system,可以直接调用外部的可执行程序,就像在Linux的shell下直接调用一样。用户可以把使用C++写成的参考模型编译成可执行文件,使用$system函数调用。因此,对于那些用Verilog写成的设计来说,SystemVerilog比SystemC更受欢迎,这就类似于用C++来测试C写成的代码显然比用Java测试更方便、更受欢迎。无论是对算法类或者非算法类的设计,SystemVerilog都能轻松应付。

    1.1.3 何谓方法学

            有了SystemVerilog之后,是不是足以搭建一个验证平台呢?这个问题的答案是肯定的,只是很难。就像汉语是很优秀的语言一样,自古以来,无数的名人基于它创作出很多优秀的篇章。有很多篇章经过后人的浓缩,变成了一个又一个的成语和典故。在这些篇章的基础上,作家写作的时候稍微引用几句就会让作品增色不少。而如果一个成语都不用,一点语句都不引用,也能写出优秀的文章,但是相对来说比较困难。这些优秀的作品就是汉语的库。同样,SystemVerilog是一门优秀的语言,但是如果仅仅使用SystemVerilog来进行验证显然不够,有很多直接的问题需要考虑,比如:

    1. 验证平台中都有哪些基本的组件,每个组件的行为有哪些?
    2. 验证平台中各个组件之间是如何通信的?
    3. 验证中要组建很多测试用例,这些测试用例如何建立、组织的?
    4. 在建立测试用例的过程中,哪些组件是变的,哪些组件是不变的?
    5. 同时,也有一些更高层次的问题需要考虑:
    6. 验证平台中数据流与控制流如何分离?
    7. 验证平台中的寄存器方案如何解决?
    8. 验证平台如何保证是可重用的?

          读者可以尝试自己回答这些问题,回答的时候不要空想,要把真正的代码写出来。
         何谓方法学?方法学这个词是一个很抽象、很宽泛的概念,很难用简单的词语把它描绘出来。当然了,即使是一本专业讲述方法学的书籍,几百多页,看过之后可能依然会觉得不知所云。
    在对方法学的理解上,有三个层次
    第一个层次,在刚刚接触到这个概念时,很容易把方法学和世界观、人生观、价值观等词语联系到一起,认为它是一个哲学的词汇。这种想法是不可避免的,而且,从根本上来说,它是正确的。只是这种理解太过浅显,因为方法学的真谛不在于概念本身,而在于其背后所表示的东西。
    第二个层次,当初步学习完本书后,读者会觉得自己以前的想法太天真:方法学怎么会有那么神秘?至少从UVM的角度来说,方法学只是一个库。这种理解基本上没错。无论任何抽象的概念,一个程序员要使用它,唯一的方法是把其用代码实现。就如同上面的那些问题,如果能够把它们都完整地规划清楚,那么这就是属于读者自己的验证方法学;如果把思考结果用代码实现,那就是一个包含了验证方法学的库,是读者自己的UVM!
    第三个层次,当读者从事验证工作几年之后,对UVM的各种用法信手拈来,就会发现方法学又不仅仅是一个库,库只是方法学的具体实现。从理论上来说,用一个东西表达另外一个东西的时候,只要两者不是一一对应的关系,那么一般会有很多遗漏。自然语言尚且无法完全地表述清楚方法学,而比自然语言更加简单的编程语言,则更加不可能表述清楚了。所以,一个库不能完全地表述清楚一种方法学。在这个阶段,读者再回过头来仔细想想上面的那些问题,想想它们在UVM中的实现,就会为UVM的优秀而拍案叫绝。
    关于什么是方法学这个问题,读者可以不必太过于纠结,因为它属于相对高级的东西,在开始的时候追究这个问题只会增加自己学习UVM的难度。把这个问题放在一边,只把它当成一个库,等初步学完本书后再来回味这个问题。

    1.1.4 为什么是UVM

          在基于SystemVerilog的验证方法学中,目前市面上主要有三种。
    (1)VMM(Verification Methodology Manual),这是Synopsys在2006年推出的,在初期是闭源的。当OVM出现后,面对OVM的激烈竞争,VMM开源了。VMM中集成了寄存器解决方案RAL(Register Abstraction Layer)。

    (2)OVM(Open Verification Methodology),这是CandenceMentor在2008年推出的,从一开始就是开源的。它引进了factory机制,功能非常强大,但是它里面没有寄存器解决方案,这是它最大的短板。针对这一情况,Candence推出了RGM,补上了这一短板。只是很遗憾的是,RGM并没有成为OVM的一部分,要想使用RGM,需要额外下载。现在OVM已经停止更新,完全被UVM代替。
    (3)UVM(Universal Verification Methodology),其正式版是在2011年2月由Accellera推出的,得到了Sysnopsys、Mentor和Cadence的支持。UVM几乎完全继承了OVM,同时又采纳了Synopsys在VMM中的寄存器解决方案RAL。同时,UVM还吸收了VMM中的一些优秀的实现方式。可以说,UVM继承了VMM和OVM的优点,克服了各自的缺点,代表了验证方法学的发展方向。
    在决定一种验证方法学的命运时,有三个主要的问题:
    1)EDA厂商支持吗?得到EDA厂商的支持是最重要的。在IC设计中,必然要使用一些EDA工具,因此,EDA厂商支持什么,什么就可能获得成功。目前,三大EDA厂商synopsys、Mentor、Cadence都完美地支持UVM。UVM本身就是这三家厂商联合推出的,读者打开任意一个UVM的源文件,都能在开头看到这三家公司关于版权的联合声明。
    2)现在用的公司多了吗?一种方法学,如果本身比较差,不方便使用,那么即使得到了EDA厂商的支持,也不会受到广大验证工程师的欢迎。因此,当方法学刚开始推出时,第一个用户是要冒着很大风险的。但是幸运的是,读者肯定不是这样的“小白鼠”。因为现在市面上很多IC设计公司都已经在使用UVM,并且越来越多的公司开始转向使用UVM,UVM已经得到了市场的验证。
    3)有更好的验证方法学出现了吗?没有。UVM是2011年推出的,非常年轻,非常有活力。

    1.1.5 UVM的发展史

            UVM的前身是OVM,由Mentor和Cadence于2008年联合发布。2010年,Accellera(SystemVerilog语言标准最初的制定者)把OVM采纳为标准,并在此基础上着手推出新一代验证方法学UVM。为了能够让用户提前适应UVM,Accellera于2010年5月推出了UVM1.0EA,EA的全拼是early adoption,在这个版本里,几乎没有对OVM做任何改变,只是单纯地把ovm_前缀变为了uvm_。
    2011年2月,备受瞩目的UVM1.0正式版本发布。此版本加入了源自Synopsys的寄存器解决方案。但是,由于发布仓促,此版本中有大量bug存在,所以仅仅时隔四个月就又发布了新的版本。
    2011年6月,UVM1.1版发布,这个版本修正了1.0中的大量问题,与1.0相比有较大差异。
    2011年12月,UVM1.1a发布。
    2012年5月,UVM1.1b发布。
    2012年10月,UVM1.1c发布。
    2013年3月,UVM1.1d发布。
    从UVM1.1到UVM1.1d,从版本命名上就可以看出并没有太多的改动。本书所有的例子均基于UVM1.1d。

    转自:https://yq.aliyun.com/articles/117852?t=t1

     

    展开全文
  • 看书《UVM实战》第二章后在下载源码中添加部分注释(个人理解,仅供参考)
  • 本节书摘来自华章社区《UVM实战》一书中的第3章,第3.1节uvm_component与uvm_object,作者 张 强,更多章节内容可以访问云栖社区“华章社区”公众号查看 第3章UVM 基 础3.1 uvm_component与uvm_objectcomponent...

    本节书摘来自华章社区《UVM实战》一书中的第3章,第3.1节uvm_component与uvm_object,作者 张 强,更多章节内容可以访问云栖社区“华章社区”公众号查看

    第3章
    UVM 基 础
    3.1 uvm_component与uvm_object
    component与object是UVM中两大最基本的概念,也是初学者最容易混淆的两个概念。本节将介绍uvm_object与uvm_component的区别和联系。

    3.1.1 uvm_component派生自uvm_object
    通过对第2章搭建的验证平台的学习,读者应对UVM有了较直观的认识,不少读者会认为uvm_component与uvm_object是两个对等的概念。当创建一个类的时候,比如定义一个sequence类,一个driver类,要么这个类派生自uvm_component(或者uvm_component的派生类,如uvm_driver),要么这个类派生自uvm_object(或者uvm_object的派生类,如uvm_sequence),似乎uvm_object与uvm_component是对等的概念,其实不然。
    uvm_object是UVM中最基本的类,读者能想到的几乎所有的类都继承自uvm_object,包括uvm_component。uvm_component派生自uvm_object这个事实会让很多人惊讶,而这个事实说明了uvm_component拥有uvm_object的特性,同时又有自己的一些特质。但是uvm_component的一些特性,uvm_object则不一定具有。这是面向对象编程中经常用到的一条规律。
    uvm_component有两大特性是uvm_object所没有的,一是通过在new的时候指定parent参数来形成一种树形的组织结构,二是有phase的自动执行特点。图3-1列出了UVM中常用类的继承关系。
    从图中可以看出,从uvm_object派生出了两个分支,所有的UVM树的结点都是由uvm_component组成的,只有基于uvm_component派生的类才可能成为UVM树的结点;最左边分支的类或者直接派生自uvm_object的类,是不可能以结点的形式出现在UVM树上的。


    9917f269e7ac3c4d1478e4e905ef6891a7dbae2b

    3.1.2 常用的派生自uvm_object的类
    既然uvm_object是最基本的类,那么其能力恰恰也是最差的,当然了,其扩展性也是最好的。恰如一个婴儿,其能力很差,但是可以把其尽量培养成书法家、艺术家等。
    到目前为止uvm_object依然是一个相当抽象的类。验证平台中用到的哪些类会派生自uvm_object?答案是除了派生自uvm_component类之外的类,几乎所有的类都派生自uvm_object。换个说法,除了driver、monitor、agent、model、scoreboard、env、test之外的几乎所有的类,本质上都是uvm_object,如sequence、sequence_item、transaction、config等。
    如果读者现在依然对uvm_object很迷茫的话,那么举一个更加通俗点的例子,uvm_object是一个分子,用这个分子可以搭建成许许多多的东西,如既可以搭建成动物,还可以搭建成植物,更加可以搭建成没有任何意识的岩石、空气等。uvm_component就是由其搭建成的一种高级生命,而sequence_item则是由其搭建成的血液,它流通在各个高级生命(uvm_component)之间,sequence则是众多sequence_item的组合,config则是由其搭建成的用于规范高级生命(uvm_component)行为方式的准则。
    在验证平台中经常遇到的派生自uvm_object的类有:
    uvm_sequence_item:读者定义的所有的transaction要从uvm_sequence_item派生。transaction就是封装了一定信息的一个类,本书中的my_transaction就是将一个mac帧中的各个字段封装在了一起,包括目的地址、源地址、帧类型、帧的数据、FCS校验和等。driver从sequencer中得到transaction,并且把其转换成端口上的信号。从图3-1中可以看出,虽然UVM中有一个uvm_transaction类,但是在UVM中,不能从uvm_transaction派生一个transaction,而要从uvm_sequence_item派生。事实上,uvm_sequence_item是从uvm_transaction派生而来的,因此,uvm_sequence_item相比uvm_transaction添加了很多实用的成员变量和函数/任务,从uvm_sequence_item直接派生,就可以使用这些新增加的成员变量和函数/任务。
    uvm_sequence:所有的sequence要从uvm_sequence派生一个。sequence就是sequence_item的组合。sequence直接与sequencer打交道,当driver向sequencer索要数据时,sequencer会检查是否有sequence要发送数据。当发现有sequence_item待发送时,会把此sequence_item交给driver。
    config:所有的config一般直接从uvm_object派生。config的主要功能就是规范验证平台的行为方式。如规定driver在读取总线时地址信号要持续几个时钟,片选信号从什么时候开始有效等。这里要注意config与config_db的区别。在上一章中已经见识了使用config_db进行参数配置,这里的config其实指的是把所有的参数放在一个object中,如10.5节所示。然后通过config_db的方式设置给所有需要这些参数的component。
    除了上面几种类是派生自uvm_object外,还有下面几种:
    uvm_reg_item:它派生自uvm_sequence_item,用于register model中。
    uvm_reg_map、uvm_mem、uvm_reg_field、uvm_reg、uvm_reg_file、uvm_reg_block等与寄存器相关的众多的类都是派生自uvm_object,它们都是用于register model。
    uvm_phase:它派生自uvm_object,其主要作用为控制uvm_component的行为方式,使得uvm_component平滑地在各个不同的phase之间依次运转。
    除了这些之外,其实还有很多。不过其他的一些并不那么重要,这里不再一一列出。

    3.1.3 常用的派生自uvm_component的类
    与uvm_object相比,派生自uvm_component的类比较少,且在上一章的验证平台中已经全部用到过。
    uvm_driver:所有的driver都要派生自uvm_driver。driver的功能主要就是向sequencer索要sequence_item(transaction),并且将sequence_item里的信息驱动到DUT的端口上,这相当于完成了从transaction级别到DUT能够接受的端口级别信息的转换。与uvm_component相比,uvm_driver多了如下几个成员变量:
    代码清单 3-1
    来源:UVM源代码

      uvm_seq_item_pull_port #(REQ, RSP) seq_item_port;
      uvm_seq_item_pull_port #(REQ, RSP) seq_item_prod_if; // alias
      uvm_analysis_port #(RSP) rsp_port;
      REQ req;
      RSP rsp;
    在函数/任务上,uvm_driver并没有做过多的扩展。
    uvm_monitor:所有的monitor都要派生自uvm_monitor。monitor做的事情与driver相反,driver向DUT的pin上发送数据,而monitor则是从DUT的pin上接收数据,并且把接收到的数据转换成transaction级别的sequence_item,再把转换后的数据发送给scoreboard,供其比较。与uvm_component相比,uvm_monitor几乎没有做任何扩充。uvm_monitor的定义如下:
    代码清单 3-2
    来源:UVM源代码
     34 virtual class uvm_monitor extends uvm_component;
     …
     42   function new (string name, uvm_component parent);
     43     super.new(name, parent);
     44   endfunction
     45
     46   const static string type_name = "uvm_monitor";
     47
     48   virtual function string get_type_name ();
     49     return type_name;
     50   endfunction
     51
     52 endclass
    虽然从理论上来说所有的monitor要从uvm_monitor派生。但是实际上如果从uvm_component派生,也没有任何问题。
    uvm_sequencer:所有的sequencer都要派生自uvm_sequencer。sequencer的功能就是组织管理sequence,当driver要求数据时,它就把sequence生成的sequence_item转发给driver。与uvm_component相比,uvm_sequencer做了相当多的扩展,具体的会在第6章中介绍。
    uvm_scoreboard:一般的scoreboard都要派生自uvm_scoreboard。scoreboard的功能就是比较reference model和monitor分别发送来的数据,根据比较结果判断DUT是否正确工作。与uvm_monitor类似,uvm_scoreboard也几乎没有在uvm_component的基础上做扩展:
    代码清单 3-3
    来源:UVM源代码
     36 virtual class uvm_scoreboard extends uvm_component;
     …
     44   function new (string name, uvm_component parent);
     45     super.new(name, parent);
     46   endfunction
     47
     48   const static string type_name = "uvm_scoreboard";
     49
     50   virtual function string get_type_name ();
     51     return type_name;
     52   endfunction
     53
     54 endclass
    所以,当定义自己的scoreboard时,可以直接从uvm_component派生。
    reference model:UVM中并没有针对reference model定义一个类。所以通常来说,reference model都是直接派生自uvm_component。reference model的作用就是模仿DUT,完成与DUT相同的功能。DUT是用Verilog写成的时序电路,而reference model则可以直接使用SystemVerilog高级语言的特性,同时还可以通过DPI等接口调用其他语言来完成与DUT相同的功能。
    uvm_agent:所有的agent要派生自uvm_agent。与前面几个比起来,uvm_agent的作用并不是那么明显。它只是把driver和monitor封装在一起,根据参数值来决定是只实例化monitor还是要同时实例化driver和monitor。agent的使用主要是从可重用性的角度来考虑的。如果在做验证平台时不考虑可重用性,那么agent其实是可有可无的。与uvm_component相比,uvm_agent的最大改动在于引入了一个变量is_active:
    代码清单 3-4
    来源:UVM源代码
     39 virtual class uvm_agent extends uvm_component;
     40   uvm_active_passive_enum is_active = UVM_ACTIVE;
     …
     58   function void build_phase(uvm_phase phase);
     59     int active;
     60     super.build_phase(phase);
     61    if(get_config_int("is_active", active)) is_active = uvm_active_passive_enum' (active);
     62   endfunction
    get_config_int是uvm_config_db#(int)::get的另一种写法,这种写法最初出现在OVM中,本书将在3.5.9节详细地讲述这种写法。由于is_active是一个枚举变量,从代码清单2-35可以看出,其两个取值为固定值0或者1。所以在上面的代码中可以以int类型传递给uvm_agent,并针对传递过来的数据做强制类型转换。
    uvm_env:所有的env(environment的缩写)要派生自uvm_env。env将验证平台上用到的固定不变的component都封装在一起。这样,当要运行不同的测试用例时,只要在测试用例中实例化此env即可。uvm_env也并没有在uvm_component的基础上做过多扩展:
    代码清单 3-5
    来源:UVM源代码
     33 virtual class uvm_env extends uvm_component;
     …
     41   function new (string name="env", uvm_component parent=null);
     42     super.new(name,parent);
     43   endfunction
     44
     45   const static string type_name = "uvm_env";
     46
     47   virtual function string get_type_name ();
     48     return type_name;
     49   endfunction
     50
     51 endclass
    uvm_test:所有的测试用例要派生自uvm_test或其派生类,不同的测试用例之间差异很大,所以从uvm_test派生出来的类各不相同。任何一个派生出的测试用例中,都要实例化env,只有这样,当测试用例在运行的时候,才能把数据正常地发给DUT,并正常地接收DUT的数据。uvm_test也几乎没有做任何扩展:
    代码清单 3-6
    来源:UVM源代码
     62 virtual class uvm_test extends uvm_component;
     …
     70   function new (string name, uvm_component parent);
     71     super.new(name,parent);
     72   endfunction
     73
     74   const static string type_name = "uvm_test";
     75
     76   virtual function string get_type_name ();
     77     return type_name;
     78   endfunction
     79
     80 endclass

    3.1.4 与uvm_object相关的宏
    在UVM中与uvm_object相关的factory宏有如下几个:
    uvm_object_utils:它用于把一个直接或间接派生自uvm_object的类注册到factory中。
    uvm_object_param_utils:它用于把一个直接或间接派生自uvm_object的参数化的类注册到factory中。所谓参数化的类,是指类似于如下的类:
    代码清单 3-7

    class A#(int WIDTH=32) extends uvm_object;
    参数化的类在代码可重用性中经常用到。如果允许,尽可能使用参数化的类,它可以提高代码的可移植性。
    uvm_object_utils_begin:这个宏在第2章介绍my_transaction时出现过,当需要使用field_automation机制时,需要使用此宏。如果使用了此宏,而又没有把任何字段使用uvm_field系列宏实现,那么会出现什么情况呢?
    代码清单 3-8
    `uvm_object_utils_begin(my_object)
    `uvm_object_utils_end

    答案是不会出现任何问题,这样的写法完全正确,可以尽情使用。
    uvm_object_param_utils_begin:与uvm_object_utils_begin宏一样,只是它适用于参数化的且其中某些成员变量要使用field_automation机制实现的类。
    uvm_object_utils_end:它总是与uvm_object_*_begin成对出现,作为factory注册的结束标志。

    3.1.5 与uvm_component相关的宏
    在UVM中与uvm_component相关的factory宏有如下几个:
    uvm_component_utils:它用于把一个直接或间接派生自uvm_component的类注册到factory中。
    uvm_component_param_utils:它用于把一个直接或间接派生自uvm_component的参数化的类注册到factory中。
    uvm_component_utils_begin:这个宏与uvm_object_utils_begin相似,它用于同时需要使用factory机制和field_automation机制注册的类。在类似于my_transaction这种类中使用field_automation机制可以让人理解,可是在component中使用field_automation机制有必要吗?uvm_component派生自uvm_object,所以对于object拥有的如compare、print函数都可以直接使用。但是filed_automation机制对于uvm_component来说最大的意义不在于此,而在于可以自动地使用config_db来得到某些变量的值。具体的可以参考3.5.3节的介绍。
    uvm_component_param_utils_begin:与uvm_component_utils_begin宏一样,只是它适用于参数化的,且其中某些成员变量要使用field_automation机制实现的类。
    uvm_component_utils_end:它总是与uvm_component_*_begin成对出现,作为factory注册的结束标志。

    3.1.6 uvm_component的限制
    uvm_component是从uvm_object派生来的。从理论上来说,uvm_component应该具有uvm_object的所有的行为特征。但是,由于uvm_component是作为UVM树的结点存在的,这一特性使得它失去了uvm_object的某些特征。
    在uvm_object中有clone函数,它用于分配一块内存空间,并把另一个实例复制到这块新的内存空间中。clone函数的使用方式如下:
    代码清单 3-9

    class A extends uvm_object;
    …
    endclass
    
    class my_env extends uvm_env;
      virtual function void build_phase(uvm_phase phase);
        A a1;
        A a2;
        a1 = new("a1");
        a1.data = 8'h9;
        $cast(a2, a1.clone());
      endfunction
    endclass
    上述的clone函数无法用于uvm_component中,因为一旦使用后,新clone出来的类,其parent参数无法指定。
    copy函数也是uvm_object的一个函数,在使用copy前,目标实例必须已经使用new函数分配好了内存空间,而使用clone函数时,目标实例可以只是一个空指针。换言之,clone = new + copy。
    虽然uvm_component无法使用clone函数,但是可以使用copy函数。因为在调用copy之前,目标实例已经完成了实例化,其parent参数已经指定了。
    uvm_component的另外一个限制是,位于同一个父结点下的不同的component,在实例化时不能使用相同的名字。如下的方式中都使用名字“a1”是会出错的:
    代码清单 3-10
    class A extends uvm_component;
    …
    endclass
    
    class my_env extends uvm_env;
      virtual function void build_phase(uvm_phase phase);
        A a1;
        A a2;
        a1 = new("a1", this);
        a2 = new("a1", this);
      endfunction
    endclass

    3.1.7 uvm_component与uvm_object的二元结构
    为什么UVM中会分成uvm_component与uvm_object两大类呢?从古至今,人类在探索世界的时候,总是在不断寻找规律,并且通过寻找到的规律来把所遇到的事物、所看到的现象分类。因为世界太复杂,只有把有共性的万物分类,从而按照类别来认识万物,这样才能大大降低人类认识世界的难度。比如世界的生命有千万种,但是只有动物和植物两类。遇到一个生命的时候,人们会不自觉地判断它是一个动物还是植物,并且把动物或植物的特性预加到这种生命的身上,接下来用动物或者植物的方法来研究这个生命,从而加快对于这个生命的认知过程。
    UVM很明显吸收了这种哲学,先分类,然后分别管理。想像一下,假如UVM中不分uvm_object与uvm_component,所有的东西都是uvm_object,那是多么恐怖的一件事情?这相当于直接与分子打交道!废时废力,不易于使用。
    SystemVerilog作为一门编程语言,相当于提供了最基本的原子,其使用起来相当麻烦。为了减少这种麻烦,UVM出现了。但是假如UVM中全部都是uvm_object的话,也就是全部都是分子,分子虽然比原子好用一些,但是依然处于普通人的承受范围之外。只有把分子组合成一个又一个生命体的时候,用起来才会比较顺手。
    uvm_component那么好用,为什么不把所有的东西都做成uvm_component的形式呢?因为uvm_component是高级生命体,有其自己鲜明的特征。验证平台中并不是所有的东西都有这种鲜明的特征。一个简单的例子:uvm_component在整个仿真中是一直存在的,但是假如要发送一个transaction(激励)给DUT,此transaction(激励)可能只需要几毫秒就可以发送完。发送完了,此transaction(激励)的生命周期几乎就结束了,根本没有必要在整个仿真中一直持续下去。生命是多样化的,要既允许uvm_component这样的高级生命存在,也要允许transaction这种如流星一闪而逝的东西存在。

    展开全文
  • UVM实战》代码示例

    2020-11-04 18:05:10
    UVM实战》这本书,写的真不错,很适合新手入门,下面是这本书第二章最终的代码,贴在这里,上课的时候翻阅很方便(手动笑脸)。 如果本文对您也有用,那就好好研究吧。 dut.sv module dut(clk, rst_n, rxd, rx...
  • UVM实战-P_SEQUENCER

    2020-09-11 20:01:12
    作用: 为了能更好的在sequence中访问启动该sequence的sequencer类中的变量,我们引用了p_sequencer。 常规做法: 如果不使用p_sequencer,...详细参考张强《UVM实战》中代码 使用: 若在sequence访问启动该se
  • UVM实战》——导读

    2017-07-03 10:33:00
    本节书摘来自华章社区《UVM实战》一书中的目录,作者 张 强,更多章节内容可以访问云栖社区“华章社区”公众号查看 目 录 前言第1章 与UVM的第一次接触1.1 UVM是什么1.2 学了UVM之后能做什么第2章 一个...
  • UVM实战学习资料

    2018-08-29 12:25:52
    一本UVM入门手册,实用于做FPGA或IC 初学者,需要的下
  • 本节书摘来自华章社区《UVM实战》一书中的第1章,第1.2节学了UVM之后能做什么,作者 张 强,更多章节内容可以访问云栖社区“华章社区”公众号查看 1.2 学了UVM之后能做什么 1.2.1 验证工程师 验证工程师能够...

空空如也

空空如也

1 2 3 4 5 ... 8
收藏数 150
精华内容 60
热门标签
关键字:

uvm实战