weixin_40634003的博客

关于加快验证收敛的一些方法一、自动生成uvm验证环境uvm_gen二、自动生成agent(UVC/VIP)agent_gen三、模块化设计Clock以及reset的产生clock_agent四、后台磁盘管理并且定期清理logreset_agent五、仿真信息记入数据库（问题追溯）testnamechangelist(tag/label)seeddaterun timestatus六、自动建立fail case的testlist（Regression Fai

文章目录一、基本介绍二、在实践中学习1.接口interface2.待测设计DUT3.传输数据包transaction4.序列sequence5.序列器sequencer6.驱动器driver7.监视器monitor8.代理agent9.记分板scoreboard10.仿真环境env11.测试用例test12.顶层top13.参考模型reference mode和直接编程接口（DPI）14.简单的makefile代码附件一、基本介绍通用验证方法学UVM（Un

译者按 ：当今硬件设计变得愈加复杂，如何创建出足够的测试来保证设计的正确性是每个硬件工程师需要面对的问题。Accellera的可移植激励测试规范（PSS、又称便携激励标准）[1]旨在希望能够提供一个独立的测试来源，从而实现跨层级的验证复用，即无论是IP级别、子系统、还是SoC级都使用同样的测试来源，他们也希望提供一系列功能来解决不同级别对于验证测试的不同要求，从而达到真正意义上的复用。然而，即使是像Java和C++这样拥有强大的面向对象特性的编程语言，都不能直接保证我们能得到高质量的可复用的代码，PSS本.

一、寄存器模型概览寄存器是模块之间互相交谈的窗口，一方面可以通过读出寄存器的状态，获取硬件当前的状况，另外一方面也可以通过配置寄存器，使得寄存器工作在一定的模式下。在验证的过程中，寄存器的验证也排在了验证清单的前列，只为只有首先保证寄存器的功能正确，才会使得硬件与硬件之间的交谈是“语义一致”的。如果寄存器配置结果与寄存器配置内容不同，那么硬件无法工作在想要的模式下，同时寄存器也可能无法正确反映硬件的状态。硬件中的各个功能模块可以由处理器来配置功能以及访问状态，而与处理器的对话即是通过寄存器的读写来实现

一、序列组件的互动sequence对象会产生目标数量的sequence item对象。借助于SV的随机化和sequence item对随机化的支持，使得产生的每个sequence item对象中的数据内容都不相同。产生的sequence item会经过sequencer再流向driver。driver陆续得到每一个sequence item，经过数据解析，将数据按照与DUT的物理接口协议写入到接口上，对DUT形成有效激励。当有必要时，driver在每解析并消化完一个sequence item后，

一、概述就水平复用而言，在MCDF各个子模块的验证环境中，它指的是如何利用已有资源，完成高效的激励场景创建。而就垂直复用来看，它指的是在MCDF子系统验证中，可以完成结构复用和激励场景复用两个方面。无论是水平复用还是垂直复用，激励场景的复用很大程度上取决于如何设计sequence，使得底层的sequence实现合理的粒度，帮助完成水平复用，进一步依托于底层激励场景，最终可以实现底层到高层的垂直复用。二、Hierarchical Sequence介绍在验证MCDF的寄存器模块时，将SV验证环境进化到了

一、sequence和item发送实例class bus_trans extends uvm_sequence_item; rand int data; `uvm_object_utils_begin(bus_trans) `uvm_field_int(data, UVM_ALL_ON) `uvm_object_utils_end ...endclassclass child_seq extends uvm_sequence; `uvm_object_utils(child_seq);

一、概述driver同sequencer之间的TLM通信采取了get模式，即由driver发起请求，从sequencer一端获得item，再由sequencer将其传递至driver。作为driver，永远停不下来，只要它可以从sequencer获取item，它就一直工作。sequencer和item只应该在合适的时间点产生需要的数据，而至于怎么处理数据，则会由driver来实现。为了便于item传输，UVM专门定义了匹配的TLM端口供sequencer和driver使用：uvm_seq_item_p

一、概述sequence指的是uvm_sequence类，而item指的是uvm_sequence_item类。对于激励生成和场景控制，是由sequence来编织的，而对于激励所需要的具体数据和控制要求，则是从item的成员数据得到的。二、Sequence Item介绍item是基于uvm_object类，这表明了它具备UVM核心基类所必要的数据操作方法，例如copy()、clone()、compare()、record()。item根据数据成员的类型，将划分为：控制类。例如总线协议上的读写

一、概述SV用来做线程同步的几种元件，它们分别是semaphore、event、mailbox。在UVM中，需要同步线程不再只局限于同一个对象中，还需要解决不同组件之间的线程同步问题。一旦线程同步要求发生在不同组件，这就要求组件之间可以通过某种方法来实现同步。考虑到UVM组件封闭性原则，最好不要通过层次索引的形式在组件中索引公共的event或者semaphore，UVM为了解决封闭性的问题，定义了如下的类来满足组件之间的同步要求：uvm_eventuvm_event_pooluvm_even

一、概述SV用来做线程同步的几种元件，它们分别是semaphore、event、mailbox。在UVM中，需要同步线程不再只局限于同一个对象中，还需要解决不同组件之间的线程同步问题。一旦线程同步要求发生在不同组件，这就要求组件之间可以通过某种方法来实现同步。考虑到UVM组件封闭性原则，最好不要通过层次索引的形式在组件中索引公共的event或者semaphore，UVM为了解决封闭性的问题，定义了如下的类来满足组件之间的同步要求：uvm_eventuvm_event_pooluvm_even

一、概述TLM是一种为了构建更高级抽象模型的传输方式。虽然SV语言本身没有原生的TLM传输方式，但是TLM在UVM很好地集成进来，并且在组件传输中得到了充分运用。伴随着SystemC模型的广泛引用，SystemC通信机制TLM2.0业发展起来，成为SystemC模型之间的核心传输方式。TLM协议本身并不依赖于某一种语言，而是可以跨语言来实现其传输标准。与TLM1.0相比，TLM2.0提供了更丰富更强大的传输特性，主要包括：双向的阻塞或者非阻塞接口、时间标记、统一的数据包。通过这些特性，TLM2.0

一、概述TLM通信的实现方式有一个共同的地方即都是端对端的，同时target一段需要实现传输方法，例如put()或者get()。对于monitor、coverage collector等组件在传输数据时，会存在一端到多端的传输。二、TLM_FIFO在一般TLM传输过程中，无论是initiator给target发起一个transaction，还是initiator从target获取一个transaction，transaction最终都会流向consumer中。consumer在没有分析transa

一、概述多向通信这种方式服务的仍然是两个组件之间的通信，而不是多个组件之间的通信，毕竟多个组件的通信r仍然可以由基础的两个组件的通信方式来构建。多向通信指的是，如果initiator与target之间的相同TLM端口数目超过一个时的处理解决办法。comp1有两个uvm_blocking_put_port，而comp2有两个uvm_blocking_put_imp端口。对于端口例化可以给不同名字，连接也可以通过不同名字来索引，但问题在于comp2中需要实现两个task put(itrans t)，

一、概述单向通信指的是从initiator到target之间的数据流向是单一方向的，或者说initiator和target只能扮演producer和consumer中的一个角色。在UVM中，单一数据流向的TLM端口有很多类型：uvm_blocking_put_PORTuvm_nonblocking_put_PORTuvm_put_PORTuvm_blocking_get_PORTuvm_nonblocking_get_PORTuvm_get_PORTuvm_blocking_peek_P

一、概述在芯片开发流程中，系统原型和芯片验证对项目的助推起到了关键作用。系统原型一般是通过硬件功能描述文档来模拟硬件行为，而行为要求不同于RTL模型。系统原型可以提供一个准确到硬件比特级别、按照地址段访问、不依赖于时钟周期的模型，该模型通常基于SystemC语言，而系统原型中各个模块通过TLM可以实现宽松时间范围内的数据包传输。芯片验证是在RTL模型初步建立之后，通过验证语言和方法学来构建验证平台。该平台的特点是验证环境整体基于面向对象开发，组件之间的通信基于TLM，而在driver与硬件接口之间需

一、环境构建的四要素在发送测试序列之前，首先需要创建一个结构化的环境，将环境建立的核心要素拆解开来，可以分为四个部分：单元组件的自闭性回归创建通信端口连接顶层配置二、单元组件的自闭性自闭性指的是单元组件(例如uvm_agent或者uvm_env)自身可以成为独立行为、不依赖于其它并行的组件。举例来说，driver同sequencer之间，虽然driver需要获取sequencer的transaction item，但是它本身可以独立例化，而它们之间的通信也是基于TLM端对端的连接实现的。这

一、uvm_topuvm_top是uvm_root类的唯一实例，它由UVM创建和管理，它所在的域是uvm_pkg。uvm_top是所有test组件的顶层，所有验证环境中的组件在创建时都需要指明它的父一级，如果某些组件在创建时指定父级的参数为null，那么它将直接隶属于uvm_top。uvm_top提供一系列的方法来控制仿真，例如phase机制、objection防止仿真退出机制等。二、uvm_testtest类是自定义类的顶层结构。所有的test类都应该继承于uvm_test，否则uvm_

一、概述SV验证环境中的验证组件按照功能需要，被称之为激励器、监测器和检查器，这三个核心组件与验证环境的三个关键特性对应，即激励、监测和检查，并且有与其对应的组件(component)。UVM组件家族是从UVM基类继承的一个核心分支即uvm_component类。从uvm_component类继承的类都可以构成验证环境，这是因为它们都从uvm_component类继承了phase机制，也都会经历各个phase阶段。在UVM模块中，主要的构成验证环境的常见组件类包括：uvm_driver、uvm_monit

一、概述一个好的验证系统应该具有消息管理特性，它们是：通过一种标准化的方式打印信息、过滤重要级别信息、打印通道。UVM中提供了一系列的类和方法来生成和过滤消息，包括消息方法、消息处理、消息机制。二、消息方法在UVM环境中或者环境外，只有引入uvm_pkg，都可以通过下面的方法来按照消息的严重级别和冗余度打印消息。function void uvm_report_info(string id, string message, int verbosity=UVM_MEDIUM, string filen

一、概述在验证环境的创建过程build_phase中，除了组件的实例化，配置也是必不可少的。为了验证环境的复用性，通过外部的参数配置，使得环境在创建时可以根据不同参数来选择创建的组件类型、组件实例数目、组件之间的连接以及组件的运行模式等。在更细致的环境调节中有更多的变量需要配置，例如for-loop的阈值、字符串名称、随机变量的生成比重等。比起重新编译来调节变量，如果在仿真中可以通过变量设置来修改环境，那么就更灵活了，而UVM的config机制正提供了这样的便利。UVM提供了uvm_config_db配

一、概述SV的验证环境构建中，传统的硬件设计模型在仿真开始前，已经完成例化和连接了，而SV的软件部分对象例化则需要在仿真开始后执行。虽然对象例化通过调用构建函数new()来实现，但是单单通过new()函数无法解决在验证环境实现层次化时，无法保证例化的先后关系，以及各个组件在例化后的连接。如果需要实现高级功能，例如在顶层到到底层的配置时，SV也无法在底层组件例化之前完成对底层的配置逻辑。因此，UVM在验证环境构建时，引入了phase机制，通过该机制可以将UVM仿真阶段层次化，不单单是各个phase的先后执行

一、uvm_object类UVM中的类最初都是从一个uvm_void根类(root class)继承而来的，而实际上这个类并没有成员变量和方法。uvm_void只是一个虚类(virtual class)，还在等待将来继承于它的子类去开垦。在继承于uvm_void的子类中，有两个类，一个为uvm_object类，另一个为uvm_port_base类。在UVM的类库地图中，除了事务接口(transaction interface)类继承于uvm_port_base，其他所有的类都是从uvm_object

一、工厂机制——覆盖(override）覆盖机制可以将原来所属的类型替换为另一个新的类型。在覆盖之后，原本原来创建原属类型的请求，将由工厂来创建新的替换类型。无需再修改原始代码，继而保证了原有代码的封装性。新的替换类型必须与被替换类型相兼容，否则稍后的句柄赋值将失败，所以使用继承。做顶层修改时非常方便，允许灵活的配置，例如可使用子类来覆盖原本的父类，可使用不同的对象来修改其代码行为。要实现覆盖的特性，原有类型和新类型都需要注册。当使用create()来创建对象时，工厂会检查是否原有类型被覆盖，如

一、工厂机制的意义工厂机制也是软件的一种典型设计模式，UVM工厂的存在就是为了更方便地替换验证环境中的实例或者注册了的类型，同时工厂的注册机制也带来了配置的灵活性。这里的实例或者类型替代，在UVM中称作覆盖(override)，而被用来替换的对象或者类型，应满足注册和多态的要求。UVM的验证环境构成可以分为两个部分。一部分构成了环境的层次，这部分代码是通过uvm_component类完成，另一部分构成了环境的属性(例如配置)和数据传输，这一部分通过uvm_object类完成。uvm_componen

一、概述在SV模块中，验证环境整体的构建，是从底层模块的验证组件搭建到通信和激励生成。这些元素无论是软件对象的创建、访问、修改、配置，还是组件之间的通信等都是通过用户自定义的方式来实现的。UVM验证方法学，就是将验证过程中可以重用和标准化的部分都规定在其方法学的类库当中。对于验证环境的需求：组件的创建和访问、环境的结构创建、组件之间的连接和运行、不同阶段的顺序安排、激励的生成传递和控制、测试的报告机制。二、UVM核心类库由于软件环境中对象的生成是动态的，验证环境中的组件也需要UVM提供底层

APB协议UVM验证环境的搭建一、编译文件只需编译这两个文件即可apb_pkg.sv里面包含了"apb.svh"，即编译apb_pkg.sv这个文件的同时，也会编译所需要的所有的头文件。`ifndef APB_PKG_SV`define APB_PKG_SVpackage apb_pkg;import uvm_pkg::*;`include "uvm_macros.svh"`include "apb.svh"endpackage : apb_pkg `endif /

一、概述对于会被经常复用的总线协议或者功能模块，可以针对其开发专用的验证IP(VIP)。对于总线VIP，需要master agent和slave agent，有时也需要Environment去构建多个主端对从端的验证环境。VIP也需要对应的配置对象，即configuration object，同时也需要对应的接口。二、主要的开发阶段阶段1(定义)功能特性提取特性覆盖率创建及映射VIP的架构阶段2(VIP基本搭建)driver、sequencer、monitor实现基本上的端到

一、什么是验证IP验证IP被用来植入到验证平台中，用来检查协议操作和接口。大多数标准协议和总线IP可以帮助检查基本的特性，例如系统启动，而VIP会做更多细致的检查。VIP的细致要求对于SoC复杂度增长所带来的验证困境相当重要。VIP可以在设计阶段的不同流程中充分应用。一个项目中，可以采取来自于不同提供商的VIP，共同构成一个完整的验证环境。二、VIP的应用优势在移动SoC时代，如上图所示，有约27个不同功能的设计模块和总线协议是标准化的，也因此可以提供VIP来加速验证环境的搭建。三、如何使用VI

一、组件更新channel master agent的driver和monitor由于总线接口信号和时序的变化，需要更新。register master agent由于总线更新为APB，需要开发完整的APB master agent。formatter slave agent由于总线信号和时序的变化，也需要进行更新。寄存器列表发生了变化，因此也需要进行寄存器模块的更新。由于寄存器访问VIP发生变化，也需要对寄存器模型与总线VIP桥接转换的adapter进行更新。二、环境更新与MCDF连

一、AMBA概述AMBA高级处理器总线架构，不同的速率需求构成了为高性能SoC设计的通信标准：AHB(advanced high-performance bus)高级高性能总线APB(advanced peripheral bus)高级外围总线AXI(advanced eXtension interface)高级可拓展接口AHBAHB主要是针对高效率、高频宽以及快速系统模块所设计的总线，它可以连接如微处理器、芯片上或者芯片外的内存模块和DMA等高效率模块。APBAPB主要用在低速且低功率

一、结构更新channel的概念由slave node替代slave node的接口发生变化register的接口发生变化formatter的接口发生变化二、接口更新slave node接口DATA(31:0)：通道数据输入。DATA_PARITY：data数据的奇偶校验位。VALID：数据有效标志信号。WAIT：暂停接收。PARITY_ERR：slave node侧发现数据或者数据校验位出错。register接口(AMBA APB标准总线)PADDR(7:0)：地址。

一、寄存器模型的完善和嵌入定义uvm_reg和uvm_reg_block的以及mcdf_rgm寄存器模块。 // Dedicated register description [write-read reg] with uvm_reg type class ctrl_reg extends uvm_reg; `uvm_object_utils(ctrl_reg) uvm_reg_field reserved; rand uvm_reg_field pkt_len;

在UVM入门实验3中，实现了monitor、reference model与checker之间的通信是通过TLM端口或者TLM FIFO来完成，相较于之前的mailbox句柄连接，更加容易定制，也使得组件的独立性提高。本次实验需要实现：将产生transaction并且发送至driver的generator组件，拆分为sequence与sequencer。在拆分的基础上，实现底层的sequence。完成sequencer与driver的连接和通信工作。构建顶层的virtual seq

一、TLM单向通信和多向通信在之前的monitor到checker的通信，以及checker与reference model之间的通信，都是通过mailbox以及在上层进行其句柄的传递实现的。这次实验则使用TLM端口进行通信，做逐步的通信元素和方法的替换。TLM通信结构框图将monitor中的用来与checker中的mailbox通信的mon_mb句柄替换为对应的uvm_blocking_put_port类型。uvm_blocking_put_port #(mon_data_t) mon_bp_p

一、验证组件和层次构建首先将各个package中的SV组件替换为UVM组件实现组件对应原则：SV的transaction类对应uvm_sequence_itemSV的driver类对应uvm_driverSV的generator类对应uvm_sequence + uvm_sequencerSV的monitor对应uvm_monitorSV的agent对应uvm_agentSV的env对应uvm_envSV的checker对应uvm_scoreboardSV的reference mode

一、工厂的注册、创建和覆盖机制UVM中只有两种用例注册的宏`uvm_component_utils(T)`uvm_object_utils(T)编译仿真factory_mechanism.sv文件object_create类 class object_create extends top; trans t1, t2, t3, t4; `uvm_component_utils(object_create) function new(string name = "obje

一、编译UVM代码编译文件uvm_compile.sv，等待正常编译结束，在work库中仿真模块uvm_compile，在命令窗口执行run -all。uvm_compile.sv代码module uvm_compile; import uvm_pkg::*; `include "uvm_macros.svh" initial begin `uvm_info("UVM", "Hello, welcome to RKV UVM training!", UVM_LOW) #1