UVM里的phase机制

UVM中的phase，按照其是否消耗仿真时间（$time打印出的时间）的特性，可以分成两大类，一类是function phase，一类是task phase。就像task和function一样，task phase消耗仿真时间。

如图所示灰色的phase是task phase其他均为function phase

 

上述所有的phase都会按照图中的顺序自上而下自动执行。使用频率最高的是build_phase、connect_phase和main_phase

 

• 对于function phase来说，在同一时间只有一个phase在执行；但是task phase中，run_phase和pre_reset_phase等12个小的phase并行运行。后者称为动态运行（run-time）的phase。

 

• run phase可以和其他12个小phase 的关系是可以在run phase里执行12个小phase的功能，也可以在12个小phase中分步进行。run phase和其他12个phse是一个并行关系，而12个phase是顺序执行的。

 

对于task phase，从全局的观点来看其顺序大致如下：

fork begin      run_phase();  end  begin      pre_reset_phase();    reset_phase();    post_reset_phase();      pre_configure_phase();      configure_phase();      post_configure_phase();      pre_main_phase();      main_phase();      post_main_phase();      pre_shutdown_phase();      shutdown_phase();      post_shutdown_phase();    end join

 

• 12个小phase存在意义：分成小的phase是为了实现更加精细化的控制。reset、configure、main、shutdown四个phase是核心，这四个phase通常模拟DUT的正常工作方式，在reset_phase对DUT进行复位、初始化等操作，在configure_phase则进行DUT的配置，DUT的运行主要在main_phase完成，shutdown_phase则是做一些与DUT断电相关的操作。

   假设要在运行过程中对DUT进行一次复位（reset）操作，在没有这些细分    的phase之前，这种操作要在scoreboard、reference model等加入一些额    外的代码来保证验证平台不会出错。但是有了这些小的phase之后，那么只    要通过phase的跳转，就会自动跳转回reset_phase。

 

• bulid phase的执行顺序是自上而下，即先执行test case的bulid phase然后执行env，在执行monitor和driver的build phase，而同级的monitor和driver的build phase执行顺序是按照字典序的,这里的字典序的排序依据new时指定的名字。

   UVM的uvm_component及其派生类变量的实例化在build_phase中做实       例化工作，如果是uvm_object的实例化，可以是任何的phase。

 

• 除了build_phase之外，所有不耗费仿真时间的phase（即function phase）都是自下而上执行的。connect phase执行顺序是自下而上的，如对于connect_phase即先执行driver和monitor的connect_phase，再执行agent的connect_phase。

 

• 无论是自上而下（build_phase）还是自下而上（connect_phase）的phase，其执行顺序都与实例化的顺序无关，而是严格按照实例化时指定名字的字典序

 

审核编辑 ：李倩