UVM

UVM

1.通用驗證方法學(Universal Verification Methodology, UVM)是一個以SystemVerilog類庫為主體的驗證平台開發框架,驗證工程師可以利用其可重用組件構建具有標準化層次結構和接口的功能驗證環境。 2. 美國佛蒙特大學(The University of Vermont)英文縮寫。

發展歷史

摩爾定律指出集成晶片可容納的電晶體數目,每隔約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 中所有的類,其有一個共同的基類 uvm_void 。它沒有數據成員,也沒有成員函式。由 uvm_void 類擴展得到了兩個子類,分別為 uvm_object類和 uvm_port_base 類。其中 uvm_object類是 UVM中所有的實體的基類。 uvm_port_base 是 UVM 中各種通信連線埠的基類。

具體繼承關係如圖所示 。

樹型組織結構

UVM UVM

UVM的樹型組織結構如圖所示 。

phase機制

UVM 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 的存在就是為了確保覆蓋率而設定的, 收集的位置包括了計分板和監視器。

相關詞條

熱門詞條

聯絡我們