Future Chaser的博客

uvm中，仿真的结束主要依赖于uvm_phase中 一个 uvm_objection类型的 test_done 实例，通过它来raise_objection，以及drop_objection，这些方法具体做了什么。在每次创建一个component的时候， 我们都会定义 build_phase， connect_phase，run_phase...这些是怎么被调用起来的？uvm_event：在分离的object，component中可以共享同一个uvm_event/barrier，实现object间的同步。

execute_phase的详细内容，根据图结构中的phase顺序执行，phase node的状态跟随特定事件进行变更，并执行相应的内容。比如，执行某个节点的imp对应的父类的traverse方法，调用其中execute，再执行imp的exec_func。traverse中递归component中分为topdown，bottomup两种形式，task的execute是通过fork join_none进行，所以执行run_phase的component不分先后。

否则，如果添加的phase 是UVM_PHASE_SCHEDULE或UVM_PHASE_DOMAIN，即添加一个已经创建的phase schedule node，则begin_node设置为当前要添加的phase，end_node设置为添加phase的m_end_node，要添加的phase的parent设置为当前调用的phase（如果是在uvm_domain中添加uvm_schedule，则设置为uvm_domain；在uvm_root创建的时候，就已经创建了m_common_domain实例。

我们都知道uvm环境是通过在tb顶层调用run_test方法来启动的，但它具体完成了什么呢？怎么样启动整个环境的呢？本专题则是围绕这两点学习源码，主要是m_run_phase方法，该方法按照设定的phase节点顺序调用了各个组件的phase。本文主要介绍run_test。

uvm_callback源码 分析

systemverilog中介绍了semapahore，event和mailbox，以进行线程间的通信，而它们的实例需要同处一个对象中。而在uvm中，涉及多个组件，组件间的同步线程不再只局限于在同一个对象中。hierarchy name索引的方式与tb间的耦合极为紧密，为将来环境变动，环境复用带来很大的麻烦。为此，uvm定义了uvm_event和uvm_barrier来解决此问题。