#UVM# UVM 验证方法学之 仿真生态系统的创建、消耗和完结

目录

一、基于UVM 验证方法学的验证平台概述

二、仿真阶段划分   

三、静态实例域

四、动态实例域

结束

---

        随着当今IC设计规模的越来越庞大，对于涉及IC的验证需求越来越高。公司不惜花费重金，聘请专业的验证工程师，来尽可能降低设计bug 的存在，给公司带来的经济损失。

故此，对于验证工程师来讲，掌握UVM和Systemverilog 相结合的验证方案，可以说是一项必备技能。常言道：活到老，学到老。。。。

少扯淡，言归正传。

    

一、基于UVM 验证方法学的验证平台概述

        业界主要大的IC设计公司，如今都采用了或者说完成了各种旧的验证平台到基于UVM方法学的验证平台迁移。在搭建UVM的测试平台中，每个公司都有自己的特色，处于各种考虑，或多或少的，每个UVM平台不全一样。但是，万变不离其中，只要你有耐心，总归可以拨开云雾见青天，最最就基本的骨架，都是基于UVM验证方法学的那几家公司的力推的雏形框架。

从最初的基于verilog ->systemverilog-> UVM 的一路走来，对于验证工程师来讲，要大脑清晰的明白一件事情：每个变量、模块、结构体的创建、消亡、再创建、再消亡的真个过程，了然于胸，才能少走弯路，平台也能足够robust。

整个平台，有我们待验证的dut， 有我们的UVM OOP 环境，还有用来完成两者连接的interface/virtual interface 。今天，我们一起来来了解两个不同“实例领域”之间的差异以及创建事物的顺序。

二、仿真阶段划分   

        提到仿真工具，日常接触到的最多工具便是VCS, 其仿真包含三个步骤或阶段：compilation, elaboration and run-time。

Compilation：是解析和分析代码的地方。

Elaboration：是将设计组件绑定在一起的过程。除其他外，Elaboration包括创建实例化，计算参数值，解析分层名称和连接nets。通常在引用compilation and elaboration阶段时，它们不会被区分，但通常直接被称为compilation。换句话说，“编译时错误”可能指的是run-time阶段之前的任何时间的错误。

Run-time：仿真实际执行或运行过程执行、仿真时间提前等。

诸如“prior to simulation”或“before simulation”之类的短语通常用于指代在run-time之前，然而，“during simulation”发生的编译和细化步骤，以指代run-time步骤或阶段。

三、静态实例域

        在仿真开始之前，在elaboration期间会创建许多组件实例。一旦仿真开始，这些组件的实例既不会再次被创建也不会被破坏，而是会在整个仿真过程中被保持。我们将此称为静态实例领域。属于这个领域的组件是:模块实例(moudle)，接口实例（interface），checker instances，primitive instances和设计层次结构的顶层模块实例。

四、动态实例域

在仿真期间可能创建和销毁的组件实例属于所谓的动态实例领域；属于这个领域的常见组件是class。
但是有一个例外：声明为static的Class methods and properties 在runtime之前创建，而在静态领域的组件实例之后创建的。（举例：用户自定义单例对象、interface 中内嵌的class类定义等）
这个例外通常用于在仿真之前创建和初始化 class properties（包括class objects）：称为静态初始化。UVM factory是静态初始化的对象的一个示例。

两个实例领域的组件按以下顺序创建：

结束