目录
一.Phase机制的意义？
二.Phase图表
三.phase的执行顺序
1.UVM中不同phase的执行顺序
2.兄弟关系component的phase执行顺序
3.叔侄关系component的phase执行顺序
4. task phase的执行顺序
四.phase的其他知识
1.super.phase
2.uvm_error
3.phase的跳转
4.phase的调试
5.超时退出
五.objection机制
1.概述
2.run phase与动态运行的phase
动态运行的phase中有objection提起，run phase可自动执行（受控）
run phase主动提起objection，动态运行的phase不会自动执行（主控）
其实不用过分纠结phase的提起与落下，objection机制主要针对的是task phase，其他function phase没有必要提起或落下objection（但是不代表不可以，只是没有意义）。
3.set_drain_time
4.objection的调试
六.domain机制
概述
一.Phase机制的意义？
在不同的时间做不同的事儿，是UVM中phase的设计哲学。phase的自动执行功能极大方便了用户，很大程度上解决了因代码顺序杂乱可能会引发的问题。引入phase机制，清晰地将UVM仿真阶段层次化引入phase机制，清晰地将UVM仿真阶段层次化。
二.Phase图表
主要分为9大phase，其中run_phase又与其他12个小phase并行执行。
常用的phase有build_phase,connect_phase,run_phase,report_phase.
除了run_phase,其他都是function，不消耗时间；
除了build_phase和final_phase,其余function phase都是自底向上的执行顺序；
引入12个小phase是为了实现更精细的控制；
reset 复位、初始化
config DUT配置
main DUT运行
shutdown 断电
（背就完事了，多看几遍就记住了）
三.phase的执行顺序
1.UVM中不同phase的执行顺序
从时间上讲，各个phase严格按照图表中的顺序，自上而下执行；
example：先执行build_phase,再执行connect_phase;
从空间来看，按照UVM树形结构，一层层往下执行；
example：先执行my_case的build_phase，再执行env的build_phase。
2.兄弟关系component的phase执行顺序
执行顺序按照字典序；
example：
agent下的driver与monitor属于同一层次，若monitor在new时指定名字“aaa”，driver指定名字“bbb”，则先执行monitor的build_phase，再执行driver的build_phase。
3.叔侄关系component的phase执行顺序
执行顺序为深度优先；
example：
此处结合第2点。env下的agent与scoreboard属于同一层次，若agent在new时指定名字“aaa”，scoreboard指定名字“bbb”，则先执行agent的build_phase，然后执行agent下driver及monitor的build_phase，最后再执行scoreboard的build_phase。
4. task phase的执行顺序
(1).task phase会消耗时间。对于父子关系的run_phase，启动顺序仍然是自下而上，但是同时以fork_join none的形式在运行；
(2).对同一个component的12个小phase，虽然是顺序执行，但是以main_phase为例，A的main_phase结束后，不会马上跳转到post_main_phase，而会等整个验证平台的其他component的main_phase都结束之后，才会统一跳转到下一个phase；
四.phase的其他知识
1.super.phase
对于uvm_component类，除了build_phase，其他phase书写时完全不必加super。
利用super.build_phase自动获取config_db::set设置的参数。
2.uvm_error
通常利用uvm_fatal直接退出仿真；
但在end_of_elaboration_phase及之前的phase中出现uvm_error，仿真也会自动结束。
3.phase的跳转
只有uvm_pre_reset之后的所有phase才可以跳转。
向前跳转只能到该phase之前的动态运行的phase，向后跳转可以到final phase。
4.phase的调试
UVM_PHASE_TRACCE
5.超时退出
uvm_root.set_timeout(延迟时间，是否可以被后续的延时覆盖（0/1）)
默认时间为9200s，若到时间测试用例未结束，会生成uvm_fatal结束仿真。
五.objection机制
1.概述
在进入某一phase时，UVM会收集此phase提出的所有objection，当所有objection都被撤销后，就会关闭此phase，进入下一个phase。当所有phase都执行完毕后，会调用$finish来将整个验证平台关闭。
objection机制就是为了控制仿真结束，一般情况只在sequence中控制objection。
2.run phase与动态运行的phase
动态运行的phase中有objection提起，run phase可自动执行（受控）
run phase主动提起objection，动态运行的phase不会自动执行（主控）
其实不用过分纠结phase的提起与落下，objection机制主要针对的是task phase，其他function phase没有必要提起或落下objection（但是不代表不可以，只是没有意义）。
3.set_drain_time
phase.phase_done.set_drain_time(this,200)
当检测到没有objection提起时，经过延时再进入下一个phase。
一个phase对应一个drain_time，默认为0。
4.objection的调试
UVM_OBJECTION_TRACCE （和phase的有点像）
六.domain机制
概述
domain是UVM中一个用于组织不同组件的概念。
默认情况下，所有的component组件都位于一个common_domain的domain中。
图左为common_domain，图右为两个不同的domain
domain把两个时钟域隔开，之后两个domain的各个动态运行的phase 就可以不同步，只能隔离run-time phase，run_phase 和其它function phase 是同步的。（重点！！！）
domain隔开后，phase的跳转只能在当前的domain中跳转。
