第5章 UVM验证平台的运行
5.1 phase机制
phase机制_wonder_coole的博客-CSDN博客
function phase,不耗费仿真时间,通过函数来实现;
task phase,它们耗费仿真时间,通过任务来实现。
对于function phase来说,在同一时间只有一个phase在执行;
但是task phase中,run_phase和其下属12个小的phase(12个之间顺序执行)并行运行。后者称为动态运行(run-time)的phase。如下代码所示:
run_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
稍微解释一下上述代码含义,fork-join 表示两个 begin-end 是同时开始运行的,当 run_phase() 和 pre_reset_phase() 同时存在时,run_phase() 和 pre_reset_phase() 在同一个时刻点开始运行,在 run_phase() 和 pre_reset_phase() 两个 phase 均运行结束以后,主 phase 才会继续执行 extract_phase()。耗时的 phase 的运行是在 uvm_tree 中从下往上运行。
这里出现一个phase概念,与phase对应的还有domain,
前面已经说过了phase可以理解为一个动物的各个生命阶段,
domain可以理解为哪些动物是同步行动的一个范围,
这两个都是从object派生出来的类。然而phase又大体分为2种,具体见下图,一种是消耗仿真时间的task类,一种是不消耗时间的
function类,task类可以类比为什么婴儿期,青春期,更年期这类持续一段时间的东西。
function类可以类比为出生,死亡这种定义一个瞬间的东西。
当然function phase又分为自上而下执行与自下而上执行2种,只有build,final 2个是自上而下执行,其他的都是自下而上执行。所有的task phase也是自下而上启动,而后并发执行。可以看到图中run_phase与其他的task phase不同颜色表示,这是因为run_phase其实为了之前ovm的写法,代表了整个的耗时仿真过程,而uvm把这个过程进行了细分,分成12段。这里可以*选择是使用整个的run还是分别使用12个分段的过程。
上面大体介绍了各种phase,现在再说m_run_phases,当我们不定义特殊的domain关系,则系统所有的部件使用统一的domain,也就是整个系统是统一行动的,对于相对简单的系统,这样就足够了。m_run_phases调用顶层的execute_phase 然后调用tranverse遍历顶层下面所有的test,env,agent,monitor,driver等节点,依据运行时段是否task或者function型,分别执行exec_task和exec_func。然后等待所有的components执行完当下的phase,也就是等待所有的objection都已经被解除,则继续执行下一个phase,如此循环,将整个结构下所有节点的所有时段执行完成,结束仿真。
以上整个过程都是uvm内部设定好的,不需要使用者进行改动,只需要在各个phase中添加具体的行为,使得各个component安需求运行即可。
动态运行(run-time)的phase
但是有了这些小的phase之后,分别在scoreboard、reference model及其他部分(如driver、monitor等)的reset_phase写好相关代码,之后如果想做一次复位操作,那么只要通过phase的跳转,就会自动跳转回reset_phase。
phase的执行顺序
(1)有直系关系的component
空间上的自上而下:先agent后driver
UVM的设计哲学就是在build_phase中做实例化的工作,driver和monitor都是agent的成员变量,所以它们的实例化都要在agent的build_phase中执行。
空间上的自下而上:先driver后agent
事实上,除了build_phase之外,所有不耗费仿真时间的phase(即function phase)都是自下而上执行的。如对于connect_phase即先执行driver和monitor的connect_phase,再执行agent的connect_phase。
(2)于同一层次的、具有兄弟关系的component
现执行顺序是按照字典序的。依据new时指定的名字。假如monitor在new时指定的名字为aaa,而driver的名字为bbb,那么将会先执行monitor的build_phase。无论是自上而下(build_phase)还是自下而上(connect_phase)的phase,其执行顺序都与实例化的顺序
无关,而是严格按照实例化时指定名字的字典序。
UVM树的遍历
build_phase的执行顺序_wonder_coole的博客-CSDN博客
UVM中采用的是深度优先的原则:对于在UVM树中具有叔侄关系的节点的创建顺序,并不能保证谁先谁后。
如果i_agt的build_phase执行完毕后,它接下来执行的是其孩子的build_phase,如果孩子还有孩子,那么再继续执行下去,一直到整棵以i_agt为树根的UVM子树的build_phase执行完毕,之后再执行i_agt的兄弟的build_phase。
super.phase的内容
于build_phase来说,uvm_component对其做的最重要的事情就是3.5.3节所示的自动获取通过config_db::set设置的参数。
除build_phase外,在写其他phase时,完全可以不必加上super.xxxx_phase语句
build阶段出现UVM_ERROR停止仿真
uvm_fatal是UVM内部自定义的。在end_of_elaboration_phase及其前的phase中,如果出现了一个或多个UVM_ERROR,那么UVM就认为出现了致命错误,会调用uvm_fatal结束仿真。给出的uvm_fatal是UVM内部自定义的。在end_of_elaboration_phase及其前的phase中,如果出现了一个或多个UVM_ERROR,那么UVM就认为出现了致命错误,会调用uvm_fatal结束仿真。
phase的跳转
实现main_phase到reset_phase的跳转。假如在验证平台中监测到reset_n信号为低电平,则马上从main_phase跳转到reset_phase。reset_phase主要做一些清理工作,并等待复位完成。
跳转中最难的地方在于跳转前后的清理和准备工作。如上面的运行结果中的警告信息就是因为没有及时对objection进行清理。
对于scoreboard来说,这个问题可能尤其严重。在跳转前,scoreboard的expect_queue中的数据应该清空,同时要容忍跳转后DUT可能输出一些异常数据。
jump函数的参数必须是一个uvm_phase类型的变量。
9大phase:建立、链接、运行、检查、报告等
run_phase包括12小phase( 1、 上电 2、复位(reset)3、寄存器配置(config)4、发送主要测试内容(main)5、等待DUT完成测试(shutdowm))
那么哪些phase可以作为jump的参数呢?在代码清单5-14中,uvm_pre_reset_phase::get()后的所有phase都可以。红框内不可以