在高級驗證方法學(AVM)和通用可重用驗證方法學(URM)的基礎上，Mentor Graphics和Cadence共同推出了業界第一個通用、開放的驗證方法學OVM；OVM為驗證工程師提供了豐富的類庫和高級驗證技術，實現驗證平臺從模塊級到系統級的重用，公司內外的重用，并且可以在多個廠家的仿真驗證平臺上運行。

可重用的驗證平臺

搭建一個高級的驗證平臺有很多要求，其中一個主要的要求就是要讓驗證平臺可重用。驗證平臺的可重用性體現在以下幾個方面：模塊級驗證到系統級驗證的重用，同一個項目下不同測試環境的重用，在公司內部不同項目之間的重用，在不同公司之間的重用；從重用對象的角度來看，存在著驗證組件的可重用、事務激勵和產生算法的可重用等等。

OVM提供了事務交易級的架構，借助這些事務交易級的接口，可以搭建模塊化，可重用的驗證組件；它的類庫可以幫助使用者創建約束隨機的激勵和序列，搜集和分析功能覆蓋信息，包括斷言在內的可配置和層次性管理的驗證環境；其中基于Factory Pattern的對象生成方式，驗證平臺架構的動態構建，動態的參數配置，激勵產生與驗證架構分離和測試作為驗證的頂層等高級技術使得可重用的驗證平臺更易實現。

驗證平臺架構的動態構建

在驗證中經常遇到一個可重用性的難題就是需要及時調整特定的驗證平臺環境，對DUT應用一系列新的功能測試。通常，我們通過修改已有驗證平臺中特定的驗證組件源代碼，得到一個新的驗證環境。例如，通過用一個注錯功能的驅動器去替換通用的驅動器。這很容易就可以通過面向編程語言的技術，在例化原驅動器的位置上添加代碼，例化一個注錯功能的驅動器，從而擴展基類環境到一個新的環境。假如兩個驅動器接口都是兼容的，那么驗證環境的其他部分的代碼便可以保持不變。

傳統上，基于類的層次化對象產生創建是通過對象的構造函數new()來實現的。高層次的組件通過調用低層次組件的構造函數，創建低層次組件的對象。這種方法限制了創建對象的靈活性，因為對象的類型在編譯的時候就已經確定了。另外，我們需要維護兩個不同的驗證環境，雖然我們可以通過面向編程技術使原有的代碼得到重用，但是我們更加希望整個驗證架構也能夠重用；也就是說，我們希望可以不改動任何原有的代碼，而調整其內容從而實現一個驗證架構的重用。在OVM中我們可以通過Factory Pattern的方法來實現的。

Factory Pattern是一個很出名的面向對象的編程技巧，Factory是一個可以動態創建對象的類。它的主要好處是可以在特定的時刻創建特定的對象。Factory不是層次化驗證架構中的一部分，而是處于層次化結構之外。OVM提供了一個Factory可以創建任何類型的事務交易或者任何驗證組件，只要事前他們在Factory做過注冊。Factory提供類型重寫可以動態的改變所創建對象的類型。在OVM中我們通過ovm_factory來實現，見代碼段1：

　　class my_env extends ovm_env;

　　 drv d1,d2;

　　…..

　　 function void build();

　　　　…… //build the rest of the environment

　　　　d1=new(“d1”,this); //explicit constructor:new()

assert($cast(d2,create_component(“drv”, “d2”))); // factory method: create_component //create an object of drv type

endfunction

　　…

　　endclass

我們從上面的代碼可以看到d1和d2采用不同的例化和構造方式。d1這個對象是通過調用其構造函數來實現的，這限制了可重用性。相反，Factory的create_component()方法返回了一個drv類的對象并且賦給了d2。這兩段代碼都是一個drv的例化對象被創建，但是Factory提供了更大的靈活性，因為它可以在my_env類以外對其進行控制，也就是其上層的ovm_test例化中進行操作，從而可以從Factory中返回一個期望類型的組件給drvier的例化對象，如代碼段2：

class err_test extends ovm_test;

my_env env;

function void build();

ovm_facotry::set_type_override(“drv”,“err_driv”); //factory type override meotod

env=new(“env”);

….

endfunction

…

endclass

set_type_override()方法告訴Factory：一旦驗證環境通過create_component()要求一個drv基類對象的時候，請為其返回一個err_drv類的例化對象。在Factory中也可以針對特定的例化對象做類型修改。這個機制使得一個相同的驗證環境類可以被例化到多個測試中，每一個測試都可能要求一個不同類型的driver的擴展，但是環境的代碼沒有改變。這個環境本身是一個可重用和上下文相關的(取決于測試如何控制Factory去生成相應類型的對象)。當在各個層次的build()階段都采用這種的方式，每個上層的組件通過Factory去創建一個子組件的例化對象，那么任何一個組件就可以通過類似的方式來指定需要的類型。

動態的配置機制

傳統的基于類的層次化驗證環境中使用構造函數的參數來配置驗證平臺。例如驗證平臺的架構，參數設置(數組的大小和常數)，操作模式(錯誤注入和調試)是可以通過這個方法來配置的；但是在層次復雜的結構中，這種方法使用起來變得困難而且很難添加新的參數。

OVM支持內置動態的配置機制，來實現結構化屬性和運行時參數的配置，從而避免通過構造函數的參數來傳遞信息。一個高層次的組件可以設置配置信息，這些信息被對應的低層組件的獲取后使用。每個可配置的組件負責在合法的時刻去獲取自己的配置信息：結構化配置信息，例如多少個子模塊可以被例化，可以通過build()這個階段來控制；運行時的信息，例如在總線周期之間需要等待多少個狀態才注錯，可以通過組件的build()或者configure()階段來實現，他們也可以在run()這個階段來實現。OVM提供了一個API來實現這個配置信息的設置和獲取的過程。如代碼段3：

class drv extends ovm_threaded_component;

　　local int delay;

　　virtual function void build();

　　 if(get_config_int(“numdly”,numdly)) //get the configuration from the global table

set_delay_length(numdly);

　　endfunction

　　virtual task run();

　　…

case(state)

　　 DONE:begin

　　 if(get_config_int(“numdly”,numdly))

　　 if(numdly<=10)

　　 set_delay_length(numdly);

　　 else ovm_report_error(“Driver”,”ILLEGAL length sepcification”);

　　 state=IDLE;

　　 IDLE:begin

　　 if(delay==0)

　　 state=GO;

　　 …

　　　endcase

….

endtask

　　endclass

配置信息可以通過高層的組件來指定，而常常由頂層的驗證環境或者頂層的測試來決定；通過set_config_*()，配置也可以對一個特定例化上實現；配置信息可以直接的被制定為整數或者字符串的值，但是有些比較復雜的需要封裝在一個ovm_object的對象中通過使用set_config_object()方法來實現。代碼段4是一個例子，測試將配置driver中的延遲時間：

代碼段4：

　　class dly_test extends ovm_test;

　　 virtual function void build()

　　 set_config_int(“env.d1”,”numdly”,5);

　　 …..

　　 endfunction

　　…

　　endclass

在OVM中這些配置是通過一個全局的查找表來實現的，其為驗證平臺提供了可重用性。第一，對組件的配置信息獨立于自身的構造函數，這使得測試可以更靈活的根據其他配置信息或者隨機地去為還未被例化組件配置信息。使用者還可以通過使用通配符來在多個組件中對多個參數做配置。組件自主獲取其配置信息可以讓組件保證無論在那種情況下都要被合法的配置。如果其中有不匹配的地方，組件作為一個仲裁者，會要求恰當的配置。

測試作為驗證的頂層

標準驗證平臺的結構中有一個頂層的模塊(top)，在頂層模塊中例化了DUT(alu)，DUT接口(alu_if)和一個頂層的類(test_env)；頂層的類(test_env)即驗證環境中包含了驗證平臺的所有組件，可以在這個架構中應用的SystemVerilog技術例如約束隨機數的產生和功能覆蓋率。

圖1 標準驗證平臺的頂層結構

在標準的驗證架構中，如圖1所示，頂層的對象是一個環境類，其中嵌入了激勵產生器。這限制了添加和修改測試的靈活性。

將激勵生成算法從驗證平臺的結構中分離出來，這樣可以讓我們將一個測試的類(test)作為頂層的對象而不是一個環境的類(env)。

圖2 測試作為驗證的頂層

如圖2所示，test_MAC是我們的測試，它是一個類，其中包含四個成員：

1.一個sequence(MAC_sequence)，其可以生成一系列事務交易；在這個例子中，事務交易通過sequence生成，是一個實現了乘累加算法的激勵序列。

2.一個驗證環境(t_env)，其例化包含了各種驗證組件。

3.Factory的重寫，可以為MAC的測試動態地創建一個驗證環境。

4.配置信息，可以為MAC的測試動態地配置驗證環境。

相對于標準的驗證平臺，測試作為驗證的頂層在添加和修改測試上提供了很大的靈活性。每個測試可以定義它自己特定的配置信息，在編譯完所有的測試和驗證組件之后，每個測試可以不用重新編譯就能運行，因為每個測試在它運行的時候可以動態的創建和配置驗證架構。

采用了這種方法，上述例子可以根據不同的應用被配置到特定的測試中，包括選擇特定的記分板，給測試指定一個合適的衡量機制，選擇一個特殊的事務處理器或者配置一個可預測的結果。在某些情況下，整個層次化的模塊可能被代替，例如激勵生成模塊，分析模塊和監視模塊。從而，同一個驗證環境(test_env)能夠被不同的測試(test)多次重用，動態創建和配置。

激勵產生與驗證架構分離

圖3 標準的激勵產生模塊

就如我們前面所說的激勵產生、事務交易在驗證平臺中的驗證組件――激勵產生器中創建生成；如圖3所示，在我們的例子中driver是一個事務處理器，可以接受ALU的事務交易，例如加、減操作，將其分解送入到ALU的管腳級的端口中。在DUT和事務處理器之間通過虛接口(virtual interface)來實現。

激勵生成算法被嵌入在產生器的類中：stimulus_gen，這種接口限制了修改測試的靈活性。為了添加或者修改測試，產生器的對象需要被另外一個產生器代替，從而需要重新配置和重新編譯。除了支持上述方法，OVM推薦了另外一種方法：把激勵生成的算法模塊從驗證平臺的結構中分離出來，從而在添加和修改測試上提供更大的靈活性。

圖4 層次化的激勵產生模塊

在圖4中，生成事務交易的算法包含在一個sequence對象中：MAC_sequence，這不是一個結構化的驗證組件，而是存在于驗證架構以外。OVM提供了sequence，在驗證架構以外來生成事務交易。整個激勵層次由一個sequence (MAC_sequence)，一個sequencer和一個事務交易器driver組成。sequencer同步了MAC_sequence和driver之間的通信。

作者：鐘文楓

　　應用工程師

　　Mentor Graphics

　　ahan.mail@g mail.com