首先要区分一下仿真时间和运行时间：
仿真时间是使用$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上
