摩尔定律指出集成芯片可容纳的晶体管数目，每隔约18 个月便会增加一倍，性能也将提升一倍。大规模 SOC 和多核设计出现，专用集成芯片(ASIC)设计的复杂度以指数增长，这使得验证工作成为芯片设计中的关键瓶颈[1] 。
为了解决验证这一难题，出现了商用的硬件验证语言，包括OpenVera、SystemC和e语言。验证语言的开发大大加速了验证，另一方面也使得设计人员与验证人员的沟通出现了障碍，甚至原则上出现分歧。于是，一种新的验证语言SystemVerilog被提出，并被采纳为电气电子工程师学会1800-2009标准。
虽然SystemVerilog面向对象编程的特性为解决上述问题提供了可能，但是仍然存在问题：工程师有了更灵活的语言，但是怎么用这种语言来搭建验证平台却是没有明确规范的，即缺乏一种统一的标准。
验证方法学就是提供一套基于SystemVerilog的类，验证工程师以其中预定义的类作为起点，就可以建立起具有标准结构的验证平台。
为了进行实现验证方法学的标准化，早在2009年12月，Accellera（电子设计自动化行业的一个致力于标准化的组织）内部就通过投票，决定以之前的开放验证方法学2.1.1版为基础，构建一个新的功能验证方法学。
2011年2月，Accellera通过了通用验证方法学1.0版，并得到了三大厂商（Cadence、Synopsys和Mentor Graphics）的共同支持。此后，Accellera陆续推出了UVM1.1，1.1a，1.1b，1.1c和1.1d这几个版本。2014年6月，Accellera又推出了通用验证方法学1.2版，是现在的最新版本。[2]
UVM类库结构
以下列出了通用验证方法学的类库结构[4] ，注意这与验证平台中实例的层次关系有所不同。
对于 UVM 中所有的类，其有一个共同的基类 uvm_void 。它没有数据成员，也没有成员函数。由 uvm_void 类扩展得到了两个子类，分别为 uvm_object类和 uvm_port_base 类。其中 uvm_object类是 UVM中所有的实体的基类。 uvm_port_base 是 UVM 中各种通信端口的基类。
具体继承关系如图所示[3] 。
树型组织结构
UVM的树型组织结构如图所示[3] 。
phase机制
在 UVM 中， Phase 是使 Testbench 中各种各样的 uvm_component 按照各自的需求可以阶段性执行的一种自动化的机制。 简单的说就是使验证组件能够按需自动化执行的一种机制。 Phase 这个机制是在上一代 OVM 的基础上扩展出来的，其产生的原因就是为了增加了验证平台在各个阶段可控性和复用性， 组成 UVM框架有很多的组件，要让这些组件能有序的进行，就需要 Phase 机制。如图，按仿真前后可以分为仿真前的build_phase，仿真中的 run_phase 以及仿真后的 cleanup_phase。
环境的配置和建立都放在了 build_phase 中执行，其中 build 中需要建立 UVM树的根节点和建立 UVM 整个的树，还需要对环境中参数做初始化的配置； Connect 的过程中主要就是将 UVM 中的 port 做一个连接；end_of_elaboration 这个过程中是仿真前对 Testbench 模块通信做最后的配置和调整；start_of_simulation，将仿真的一些 Testbench 拓扑结构打印出来，也包括前一个阶段的配置信息。
run_phase是仿真的运行阶段。 Reset 过程模拟了真实的 reset 行为； 这个环境中用的很少 Configure 相关的步骤主要让信号进入准备接受 testcase 的阶段， 而激励真正添加到 DUV 的阶段就是 main 相关的步骤，这个阶段会运行直到激励运行或者 testbench 停止。 Shutdown 是为了确保激励已经加完的步骤，通常可以将对寄存器的读操作放在这个阶段。
Clean_up_phase 的存在就是为了确保覆盖率而设置的， 收集的位置包括了计分板和监视器。
閱讀更多 IC驗證技術解析 的文章
