Factory机制是产生通用代码的一种典型的软件设计思路。在功能验证中，引入的类经常需要变化。例如，在许多测试中我们可能需要给事务增加更多的约束或字段，或者想在整个环境中或仅仅一个单接口中使用新的派生类。UVM 提供了一个内建的工厂机制，促进环境重用和调整预定义的验证 IP。工厂机制最大的优点之一是，其对于测试人员简单、透明， 并且减少了开发者和用户对面向对象知识的需求。利用 factory 机制，我们可以方便快捷地更换验证环境中的任何一个组件。
Phase 机制UVM 将 testbench 建立、仿真启动到最后仿真结束分为不同的阶段，各个阶段称为不同的phase。在正式运行仿真的阶段称之为run_phase，在 run_phase 之前有 build_phase、connect_phase 等，在run_phase 之后有 check_phase、report_phase等。各个 phase 都有自己需要完成的动作。 UVM 中的 phase 根据是否消耗仿真时间分为 task phase 和 function phase。只有 run_phase 是 task phase。 在 UVM1.0 时代， run_phase 是其中唯一的一个 task_phase。当 UVM 进化到1.1 版 本 后，又 增 加 了 configure_phase、pre_main_phase、main_phase、post_main_phase 等 12 个 task_phase,同时为了兼容以前的 1.0 版本保留了run_phase。这 12 个 phase 共同实现了 run_phase 的功能，通过这 12 个 task_phase可以实现对仿真过程更精细化的控制。 phase 的执行是有先后顺序的，是按照整个 testbench 的建立顺序依次执行。 对于 task_phase 来说， UVM 中不同 component 的同一个 phase 的执行顺序是并行执行。
Field_automation 机制Field_automation 机制用于产生 transaction。使用该机制，我们能够很方便的用 transaction 的成员函数，比如 print()、compare()（这个在 scoreboard 用的比较多）、pack()（这个函数在 driver 用的比较多）、unpack()（这个在 monitor 用的比较多）等等，简化了很多工作。
Sequence 机制sequence 机制不能不说是 UVM 的一大创新， sequence 使得激励的产生和驱动相互分离，我们通过定义不同的 sequence 来使得 testbench 代码可重用，增加了激励产生的灵活性。 引入 sequence 之后，在不同的 case 中将不同的 sequence设置成 sequencer 中 main_phase 的 default_sequence，这样就完成了不同激励的加载。同时 sequence 能够通过 starting_phase 来控制验证平台的开启。
Config 机制Config 机制用于在整个验证环境中传递变量，通过 config 机制，可以在验证平台的顶层设置任何一个 component 或者某些指定 component 中的参数。在验证平台中 driver和 monitor 的虚接口和实体接口的连接就是通过 config 机制实现的。
Callback 机制Callback 机制也是为了提高验证平台的可重用性，其原理类似于 phase 机制，但是不同于 phase 机制的是，其仅仅提供了 callback 的接口函数，函数中全部为空，需要开发者自己去填写，通过对 callback 接口函数中填充不同的内容，来适应不同测试的需求。
