UVM基础之------uvm phases机制

代码的书写顺序会影响代码的实现，在不一样的时间作不一样的事情，这是UVM phase的设计哲学，UVM phase提供了一个通用的TB phase 解决方案。支持显示的隐式的同步方案，运行时刻的线程控制和跳转。只要把代码填入对应的phase，这些代码就会自动执行。 phase 的引入在很大程度上解决了代码顺序杂乱可能会引起的问题。它本质上是 经过把代码顺序强制固定来实现这个目的的，如 build_phase 的代码必定在 connect_phase以前执行 ，而 connect_phase的代码必定在 end_of_elaboration_phase之 前执行等等。遵循 UVM 的这种代码顺序划分原则，能够在很大程度上减小验证平 台开发者的工做量，让其从一部分杂乱的工做中解脱出来。 在本篇里面主要介绍在uvm phase里面的一些基本的概念。

首先要区分一下仿真时间和运行时间：

   仿真时间是使用$time函数等到的时间，而运行时间则是CPU的时间。

类继承层次：

 

这里面跟phasing相关的类介绍以下：

   1. uvm_phase: 基本的类，定义一个phase的行为，状态，内容

   2. uvm_domain：phasing的进度节点，表明进度的一个独立分支

   3. uvm_bottemup_phase: 实现bottem up 函数

   4. uvm_topdown_phase:实现topdown 函数

   5. uvm_task_phase：实现task phase

uvm中的phase，按照其是否消耗仿真时间特性，能够分红两大类：

     1. function phase不消耗仿真时间，而function phase也分红两大类：

             a. 继承自uvm_bottemup_phase的自下而上的执行function

             b. 继承自uvm_topdown_phase的自上而下执行的function

     2. 只有run_phase是task phase，消耗仿真时间的，自上而下启动，同时在运行。

UVM中同一phase的执行顺序：

      phase是和uvm_componet相伴相生的一个概念，对于每个uvm_component来讲，都有所有的phase，而 验证平台中的component是分层次的。

      1. UVM使用自上而下执行build_phase，在build_phase中作component的实例化工做，若是在其余phase实例化一个uvm_component的话，系统会报错的。若是uvm_object的实例化，则能够在任何phase完成。

      2. 除了build_phase以外，全部的不耗仿真时间的phase都是自下而上执行。

      3. 对于同一层次的uvm_component按照new时指定名字的字典顺序执行

UVM中的动态运行run_time phase:

       1.  UVM把 run_phase又分割成了 12 个小的phase，这 12 个小的 phase各自在执行 顺序方面与run_phase彻底相同，即自下而上的启动，同时运行。这里有两个问题， 第一个问题是为何要分红小的 phase？第二个问题是这 12 个小的 phase 与 run_phase之间关系如何？

UVM把run_phase又分割成12个小的phase：

1. 为啥要分红小phase，精细化控制 reset/configure/main/shutdown是核心

一个大的chip里面有不少功能性比较独立的模块，这些功能性独立意味着一个模块A在run的时刻另外一个模块B能够不run，也能够run，B运行不运行和A运行不运行关联度不大甚至没有关联，好比A是只负责处理发通路的而B只负责收通路；可是另外一方面，功能性独立并不意味着什么都独立，举例来讲，A模块和B模块功能性很独立，好比A是一个clock generation模块，B是一个processor模块，那在A没有正常work的前提下B是不能正常工做的。

       1. 分红小的phase是为了实现更加精细的控制，其中核心的四个phase是（reset，configure，main，shutdown），这四个phase模拟了DUT的正常的工做方式

       2. 实现跳转操做

       3. 12 个小的 phase之间并非这样顺序执行，而是每当一个小的phase 执行完成的时候要看看其它component的同名的小 phase有没有执行完，等全部的都执行完后，才会进入下一个小的phase，也就是说有一个同步的过程。

      由此咱们至少能够提出两点需求:

      (1)能不能让B的reset phase发生在A的reset phase以后，这样等待clock都稳定了再对B作reset操做或者release reset操做？

      (2)能不能让A的main phase和B的main phase异步的运行？

      上面两点至少须要用到UVM中的的以下机制：新建一个domain、给不一样的component设置不一样的domain、不一样的domain之间phase的同步和异步。

      再如，功能更复杂的tb可能须要新建一个user-defined的phase，让它在某一须要个时刻点运行，能够是function性质的或者task性质的。

2. 12个小phase于run_phase之间的关系？

每当一个小的phase执行完成时候，要等到全部component的同名的小phase有没有执行完，等全部执行完了，才进入下个小phase。

UVM中的objection： UVM中，经过objection机制来控制验证平台的关闭。

在进入到某一phase的时候，UVM会收集此phase提出的全部的objection，而且实时监测全部的objection是否已经drop了，当发现全部的都已经drop后，那么就会关闭此phase，开始进入下一个phase。当全部的phase都执行完毕后，就会调用$finish来把整个的验证平台关掉。

若是想执行一些耗费时间的代码，那么至少也要在此phase下raise一次objection。 这个结论只适用于run_time的phase。对于run_phase则不适用。

phase的引入是为了解决什么时候结束仿真的问题

上例中，只要把pkt_num设置成要发送的transaction的数量就能够了。这种设置能够经过config的形式，读者能够参照config机制的相关章节。

另一种方法就如在第一章的例子中那样，在sequence中把sequencer的objection给raise起来，当sequence完成后，再drop此objection。这种方法相对上一种方法的好处就是没必要设置要发送的包的数量。不过，这种方法的限制是，此sequence必需要作为sequencer的某个phase（好比main_phase）的default_sequence，这个一般是比较容易的，通常都使用这种方法。

domain：

domain把两块时钟域隔开，以后两个时钟域内的各个动态运行(run_time)的phase就能够没必要同步。注意，这里domain只能把run_time的phase给隔离开来，对于其它的phase，其实仍是同步的，即两个domain的run_phase依然是同步的，其它的function phase也是同步的。

多domain与单domain的区别主要体如今phase和objection上

来自为知笔记(Wiz)