从源码角度来看UVM phase

说到UVM phase我们就知道是UVM一个很重要的特性，从用户角度来讲，其实就是一些很简单的应用规则，能够极大地提升编码的效率，简化代码复杂度，提高debug的效率。至于应用可以参看zhangqiang大佬的第五章，这里就不再赘述。
本文就从源码的角度来看，UVM的phase是怎么工作的？
之前学习UVM总是从用户的角度来学习怎么使用，很多东西都只是知道，但是并不明白其中的内涵，读了源码才能从根本上理解这些使用规则背后的道理。之后我也会分析一下剩下的UVM源码，希望大家能够相互学习。
源代码的版本是UVM1.2

吐血将源码抽象了一下，保存了各个主要task function的主要功能，对整个phase进行了抽象。如果有任何问题，可以及时跟我沟通交流[email protected].

https://www.edrawmax.cn/online/share.html?code=83c3b8b8799e11ec8a7585ec8adb0e95

1. UVM phase框架

1.1 phase top

通过下面的伪代码就能清晰看到phase的top层是从哪里进入的，大体上是怎么运转的。

• 只要是你公司用的是UVM的架构，那么所有的top层的入口都是run_test()
• get_common_domain():就是默认的uvm domain；构建好整个UVM树。
• forever的get mailbox的phase.execute_phase()结构来实现各个phase的运转。
• 既然是伪代码，那么就不会有一行是浪费的，所以剩下没有提到的，我会在下面一一提及。

1.2 get_common_domain()

由于伪代码篇幅有限，所以我会提醒一些细节，这些细节还需要读者去源文件里面查找。

• get_common_domain()是static函数，m_common_domain是static local类型obj。记住这些细节提醒对后续函数的理解是有重要作用的。
• uvm_domain是继承自uvm_phase的。
• get_common_domain其实真正干活就只有第一次调用的时候，后来再次调用就会直接返回。而第一次调用就是在m_run_phase()里面。这其实也就是UVM默认的domain。
• run_phase+build_phase+....+final_phase是一波
• 12-run_time_phase是一波，包了一个壳uvm_phase_type=UVM_PHASE_SCHEDULE
• 将run_phase和12-run_time_phase并行
• add函数堆积成了一个UVM phase的框架，跟UVM tree一个道理，这里用两个数组m_predecessors[]以及m_successors[]来表示phase之间的位置关系。

• 如果add的uvm_phase_type == UVM_PHASE_IMP的话，会新实例化一个uvm_phase_type类型的UVM_PHASE_NODE。

1.3 set_domain

如果我们有需求，需要另建一个domain（12-run_time_phase）。set_domain其实就是在run_time_phase/12-run_time_phase(common_domain)的基础上再添加12-run_time_phase跟它们并行。

• get_common_domain我们前面说过只会在第一次调用的时候才有用，剩下再次调用的时候，会直接返回
• add_uvm_phase()表示的是12-run_time_phase。

different domain

2. UVM phase的执行

前面说了get_common_domain已经将UVM phase的框架摆好了，那么具体要怎么执行呢？
forever fork join_none以及mailbox共同作用，通过phase.execute_phase来实现了phase的运行

2.1 execute_phase()

uvm_phase_type

execute_phase()的调用者的phase类型包括三类

• UVM_PHASE_DOMAIN
• UVM_PHASE_SCHEDULE
• UVM_PHASE_IMP

从代码功能角度来看可以分为两类：

• UVM_PHASE_DOMAIN/UVM_PHASE_SCHEDULE
• UVM_PHASE_IMP

• 比如：extract_phase的m_predecessors[]就包括run_phase和post_shutdown_phase，这里就保证phase的先后顺序。
• sync是针对不同domain来说的，在不同domain的12-run_time_phase相互sync的时候才会用到。

2.2 UVM_PHASE_DOMAIN/UVM_PHASE_SCHEDULE call

• 其实并没有什么本质上的功能

2.3 UVM_PHASE_IMP call

所有的UVM phase的实现，最核心的部分就是这里了。

• 前面add的时候讲过如果是UVM_PHASE_IMP的时候，就会例化一个m_imp = UVM_PHASE_NODE的uvm_phase.
• m_imp.traverse()就会遍历整个UVM tree的结构调用对应的phase。
• 对于task_phase会涉及到objection的机制，伪代码的结构来看，正常情境下，如果没有raise_objection的话，fork...traverse(execute)...join_none就会直通disable_fork。所以要在第一个消耗时间的任务来之前raise_objection。

task_phase:
https://www.cnblogs.com/xuqing125/p/15791973.html
https://www.cnblogs.com/xuqing125/p/15791956.html

• 本质上是bottomup的结构。
• uvm_component的phase_started()和phase_ended()的callback函数。是function，不是task。
• execute()函数是fork...join_none,并行起来的。

uvm_topdown_phase/uvm_bottomup_phase:
https://www.cnblogs.com/xuqing125/p/15791969.html
https://www.cnblogs.com/xuqing125/p/15791959.html

• function phase是不消耗时间的。

• 将m_successors[]放入到mailbox里面，结合前面的forever整个phase就动起来了。

3. jump

• 根据jump(phase)来判断是往前还是往后跳转。

• execute_phase在处理的时候，会考虑jump的影响。
• jump会在mailbox里面的phase传入m_jump_phase。

4. 跨domain的sync

我们前面说过set_domain会将12-run_time_phase加入进来跟run_phase并行起来，两个domain的12-run_time_phase相互之间并没有先后关系。那要是有这方面的需求应该怎么做呢？
uvm_phase提供了sync的函数，用于满足这方面的需求。

• 用一个数据将两者关联起来。
• 在execute_phase中，通过wait m_sync的状态来实现相互的等待。
• 这个属于user可见的功能，会在参考读者其他文章看看这个到底是怎么用的。