目录
随着当今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是静态初始化的对象的一个示例。
两个实例领域的组件按以下顺序创建: