本文轉自：http://www.eetop.cn/blog/html/28/1561828-437264.html

基於複用IP的設計方法學已經被廣泛應用在SOC設計中，複用IP數量的增多使得IP的驗證與整合變為一個不小的挑戰，在本篇論文中，我們將介紹一種通用的搭建複用IP驗證環境的方法，這種方法有兩個特點:一是通用性強，適用於絕大部分的IP驗證，二是我們的IP驗證環境除了在IP層面可用，還可以被整合到頂層驗證環境中繼續發揮驗證作用。

下面我們將以AMD的power管理的IP DVR（digital voltage regularor）為例從四個方面來進行闡述:DUT分析，設計驗證模組，構建IP驗證環境，整合驗證環境到頂層。

第一步：DUT分析

DVR被整合在SOC和CPU中的一些功能模組中，負責管理經過這個功能模組的電壓，頻率，溫度以便於整個晶片可以更有效率的工作，減少功耗，下面是DVR的簡圖:

從驗證角度來看，

• DVR有兩個介面可以配置內部的暫存器，分別是Jtag介面和AMD平行匯流排介面(parallel interface)

• DVR的輸入是一些用於驅動內部計算邏輯的電壓訊號（voltage input）和驅動內部狀態機的控制訊號（control signals），它們可以放在一組介面中

• 在驗證環境中有一個行為模型模擬電壓感測器，它是RTL的設計者提供的

第二步：設計驗證模組

邏輯上看，DVR模組有三組介面，我們將會設計三個代理（agent）來分別與它們互動，每一個代理都分別有一個sequencer，driver，monitor，每個driver和monitor都會拿到虛擬介面的控制代碼進行驅動和採數，每個sequence（資料和控制資訊）會通過代理中的sequencer被髮送到driver中去，driver負責把接收到的sequence順序驅動到介面上去，下圖展示了我們針對DVR的整個驗證框架

在另一方面，當有讀寫暫存器的操作發生時，我們會利用UVM中driver和sequencer的"item_done(tx)"和"get_response(tx)"的互動機制進行暫存器的讀寫檢查，driver負責把資料驅動到DUT的輸入，然後讀回DUT的輸出，這樣我們可以在一個sequence中對暫存器的讀寫訪問許可權進行檢查而不用依賴scoreboard中的暫存器模型。

另外在驗證環境中例化了一個scoreboard，它包含一個預測器(predictor)和一些做比較的邏輯(cmpr)，代理中的monitor把採集回來的DUT的輸入和輸出資料分別送給預測器(predictor)和比較邏輯(cmpr)的輸入，然後cmpr負責把它的兩個輸入(DUT的輸出和predictor的輸出)做比較，如果不一樣則會打印出錯誤資訊。

在驗證環境中我們還有一個功能覆蓋率的模組和一個負責配置驗證環境的模組，功能覆蓋率模組包含一些針對這個IP的需要覆蓋到的測試點，它的控制代碼會被傳給monitor中負責收集覆蓋率的函式，用以保證收集功能覆蓋率的函式可以訪問到任何一個覆蓋率的點，這些被連結在monitor的環境中收集功能覆蓋率的函式每當在有事務(transaction)被建立且傳送出去時，就會被呼叫用來收集覆蓋率的資訊，最後收集到的覆蓋率資訊會被放在一個數據庫中，通過一些指令碼處理成HTML的格式，由驗證人員去分析，配置模組負責配置驗證環境中的所有的變數，例如bus的寬度，Jtag的開關，以及各個agent工作模式的變化，由於我們IP驗證環境比較小，所以只有一層的配置模組，在各個agent內部沒有子的配置模組，另外是我們的配置模組中有一些"ifdef"的開關去控制一些變數，這些變數最終會被傳到一些component的類中去，可以實現整個驗證環境的模式配置(模組級別中的主動模式(active mode)和頂層中的被動模式(passive mode))。

第三步：構建IP驗證環境

我們的驗證模組會提供所有的驗證激勵，而TB負責把DUT和驗證模組以一個靈活的結構連在一起，我們把TB定義為了一個模組，其中包含驗證模組，介面，時鐘/復位，SV的行為模組，如下圖

驗證模組中的所有的介面都被例化在TB中的SV介面中，TB的埠訊號都被定義成"inout"型別，介面中的訊號定位"logic"型別，TB的埠和介面訊號都被以雙向型別連線起來，這樣如果DUT的埠方向有所改變，TB中的埠型別也可以繼續使用，clk/rst模組負責為DUT和驗證環境中的SV行為模組提供clk和rst訊號，它也是可以配置的，可以在驗證模組時開啟，驗證頂層時關閉，模組的基礎測試激勵通過驗證環境的指標來對訪問驗證環境中的各個代理(agent)，來發送代理中的sequence，其他的激勵基於基礎測試激勵進行擴充套件。

第四步：整合驗證環境到頂層

當一個IP被整合到頂層環境中時，我們最關心的是IP能不能被以正確的方式去使用，對於模組中的測試激勵已經無法在複用了，我們在頂層環境可以複用的只有monitor和checker，有兩種方法去複用:一是把它們直接連結到頂層環境，二是把整個IP驗證環境連結到頂層，然後配置引數，如下圖

為了能夠更簡單的複用驗證環境，我們把整個IP的TB用SV的bind方法連結到DUT下面，這樣，無論DUT在哪裡例化，那TB的環境也會被一起帶進去，我們要做的改變是通過配置模組關掉TB中的agent，sequence等等，只留下monitor和scoreboard，並把介面中的訊號連向上一層的RTL輸出，這樣頂層的驗證人員不需要對被bind上去的TB環境做任何改動，就可以實現對IP DUT的驗證，下面是bind的程式碼

如果想再減少IP整合時環境的改動，我們可以在一開始就定義好TB和驗證模組以及介面的被動模式，這樣就只需要改變配置檔案，無需做其他改動。在頂層的測試激勵中，將會有一個假的測試激勵用於啟動所有UVM的component，由於頂層驗證人員想最大程度的隔絕屬於IP級別的事情，我們會僅僅把例化在TB模組中的驗證模組的控制代碼傳到頂層測試激勵，無論頂層測試激勵是基於C/C++或是UVM，這樣就可以時刻對IP模組的使用方式進行監測。

總結

我們闡述了一種構建複用IP的驗證環境的方法，這種方法最大的好處是，我們不僅可以在模組級別對IP設計進行驗證，還能夠把我們模組級別的驗證環境最大程度的複用到頂層驗證環境中去，這樣，我們就實現了水平(驗證環境可配置適用於絕大部分IP)和垂直(在頂層環境中複用模組級別的驗證資源)兩個維度上的複用，以最大程度迎合我們複用的驗證理念。