【宇宙混沌】UVM验证平台仿真生态系统的创建和消亡

目录

一、UVM 验证方法学下的验证平台

二、VCS仿真阶段的划分

2.1  two steps

2.2  three steps

三、静态实例域

四、动态实例域

---

一、UVM 验证方法学下的验证平台

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

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

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

二、VCS仿真阶段的划分

2.1  two steps

a) compilation :  % vcs + [compile options] -sverilog .... 

b) simulation : % vcs simv + [simv options] ....

2.2  three steps

a) compilation

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

b) elaboration

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

c) 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之前创建，而在【声明为static的class methods和properties】是在静态领域的组件实例之后创建的。
这个例外通常用于在仿真之前创建和初始化 class properties（包括class objects）：称为静态初始化。UVM factory是静态初始化的对象的一个示例。

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