發展歷史
摩爾定律指出集成晶片可容納的電晶體數目，每隔約18 個月便會增加一倍，性能也將提升一倍。大規模 SOC 和多核設計出現，專用集成晶片(ASIC)設計的複雜度以指數增長，這使得驗證工作成為晶片設計中的關鍵瓶頸 。
為了解決驗證這一難題，出現了商用的硬體驗證語言，包括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版，是現在的最新版本。
UVM類庫結構
以下列出了通用驗證方法學的類庫結構 ，注意這與驗證平台中實例的層次關係有所不同。
UVM對於 UVM 中所有的類，其有一個共同的基類 uvm_void 。它沒有數據成員，也沒有成員函式。由 uvm_void 類擴展得到了兩個子類，分別為 uvm_object類和 uvm_port_base 類。其中 uvm_object類是 UVM中所有的實體的基類。 uvm_port_base 是 UVM 中各種通信連線埠的基類。
具體繼承關係如圖所示 。
樹型組織結構
UVMUVM的樹型組織結構如圖所示 。
phase機制
UVM在 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 的存在就是為了確保覆蓋率而設定的， 收集的位置包括了計分板和監視器。
