UVM Phases
所有testbench的组件都是继承uvm_component来的，每一个组件都包括一些预定义的同名phase，在没有执行完所有组件的当前phase之前绝对不会去执行所有组件的下一个phase ，这就保证了所有组件之间是同步的！UVM就是利用phase机制实现了各个组件之间的同步！
因为所有的phase都被定义为回调（callback）方法，因此各个组件可以自动执行回调phase方法.
phase机制存在的意义在于：传统的硬件设计模型在仿真开始之前就已经完成了例化和连接，而SV的软件部分对象例化则在仿真开始之后执行。在SV中对象例化通过new()来实现，但是简单的new无法解决的一个重要问题就是验证环境在实现层次化时如何保证例化的先后关系，以及各个组件在例化之后的连接。此外，如果要实现高级功能，例如在顶层到底层的配置时，SV也无法在底层组件例化之前完成对底层的配置。所以，UVM在验证环境构建时引入了phase机制，通过该机制我们可以很清晰的将UVM仿真阶段层次化。这里的层次化，不仅仅是指各个phase的先后执行顺序，处于同一phase中的层次化组件之间的phase也有先后关系。
在定义了各个phase虚方法后，UVM环境会按照phase的顺序分别调用这些方法。首先来看phase主要分为哪些：
总的来说，phase可以分为3大类，如上图：
（1）build time phase
（2）run time phase
（3）clean-up phase
3大类中每一类又包括几种phase，总共的phase为9种，如下表所示：
前4种属于build time phase；第5中为run time phase；后4种属于clean-up phase；在testbench中9种phase按上表的顺序依次执行。
逻辑上，首先要创建各个组件的对象，所以最先执行的就是build_phase，只有先创建高层次的组件才会有空间来容纳低层次的组件，所以它的执行顺序是自顶向下的；然后要进行各个组件的连接，所以执行connect_phase，首先要进行底层组件的连接，所以它的执行顺序是自底向上的；build time phase的后两种phase基本不会用到，主要用来显示UVM的层次结构信息；测试激励在run_phase被发送到DUT中，run_phase和其他run time phase之间都是并行的；
在所有的phase中，只有run_phase是一个可以消耗时间的任务，这意味该phase可以完成一些等待、激励、采样的任务；其他的的phase都是函数，必须立即返回（0耗时）.
在run_phase中，用户如果要完成测试，通常需要组织下面的激励序列：
（1）上电和复位
（2）寄存器配置
（3）发送测试的内容
（4）等待DUT完成测试
用户发送激励的一种简单方式是在run_phase中完成上面所有的激励；另一种方式是将上面的几种序列划分到不同的区间，让对应的激励按区间顺序发送，则可以让测试更有层次。因此，run_phase又划分为12个phase：
reset_phase主要对DUT进行复位、初始化等操作；configure_phase主要是对DUT中的进行配置；main_phase中完成DUT的运行；shutdown_phase完成对DUT的断电相关操作；
请注意，run_phase与这12个phase之间是并行执行的，12个phase是顺序执行的！！顺序执行也仅仅是在单个组件当中，也就是说在一个组件当中这12个phase是顺序执行的，但是这并不意味着是立刻执行；例如，存在组件A和组件B，组件A的main_phase在100ns时完成，而组件B的main_phase在200ns时完成，此时A和B的post_main_phase都是在200ns后开始执行的！
Creating user-defined phases
UVM中允许用户自定义phase，下表示自定义phase与UVM phase的执行顺序：
使用自定义phase的步骤：
（1）创建并定义一个新phase类；
（2）将新创建的phase加入到schedule；
（3）在支持该phase的组件中使用这个phase；
未完待续...