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

可重用的驗(yàn)證平臺

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

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

驗(yàn)證平臺架構(gòu)的動態(tài)構(gòu)建

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

傳統(tǒng)上，基于類的層次化對象產(chǎn)生創(chuàng)建是通過對象的構(gòu)造函數(shù)new()來實(shí)現(xiàn)的。高層次的組件通過調(diào)用低層次組件的構(gòu)造函數(shù)，創(chuàng)建低層次組件的對象。這種方法限制了創(chuàng)建對象的靈活性，因?yàn)閷ο蟮念愋驮诰幾g的時候就已經(jīng)確定了。另外，我們需要維護(hù)兩個不同的驗(yàn)證環(huán)境，雖然我們可以通過面向編程技術(shù)使原有的代碼得到重用，但是我們更加希望整個驗(yàn)證架構(gòu)也能夠重用；也就是說，我們希望可以不改動任何原有的代碼，而調(diào)整其內(nèi)容從而實(shí)現(xiàn)一個驗(yàn)證架構(gòu)的重用。在OVM中我們可以通過Factory Pattern的方法來實(shí)現(xiàn)的。

Factory Pattern是一個很出名的面向?qū)ο蟮木幊碳记?，F(xiàn)actory是一個可以動態(tài)創(chuàng)建對象的類。它的主要好處是可以在特定的時刻創(chuàng)建特定的對象。Factory不是層次化驗(yàn)證架構(gòu)中的一部分，而是處于層次化結(jié)構(gòu)之外。OVM提供了一個Factory可以創(chuàng)建任何類型的事務(wù)交易或者任何驗(yàn)證組件，只要事前他們在Factory做過注冊。Factory提供類型重寫可以動態(tài)的改變所創(chuàng)建對象的類型。在OVM中我們通過ovm_factory來實(shí)現(xiàn)，見代碼段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采用不同的例化和構(gòu)造方式。d1這個對象是通過調(diào)用其構(gòu)造函數(shù)來實(shí)現(xiàn)的，這限制了可重用性。相反，F(xiàn)actory的create_component()方法返回了一個drv類的對象并且賦給了d2。這兩段代碼都是一個drv的例化對象被創(chuàng)建，但是Factory提供了更大的靈活性，因?yàn)樗梢栽趍y_env類以外對其進(jìn)行控制，也就是其上層的ovm_test例化中進(jìn)行操作，從而可以從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：一旦驗(yàn)證環(huán)境通過create_component()要求一個drv基類對象的時候，請為其返回一個err_drv類的例化對象。在Factory中也可以針對特定的例化對象做類型修改。這個機(jī)制使得一個相同的驗(yàn)證環(huán)境類可以被例化到多個測試中，每一個測試都可能要求一個不同類型的driver的擴(kuò)展，但是環(huán)境的代碼沒有改變。這個環(huán)境本身是一個可重用和上下文相關(guān)的(取決于測試如何控制Factory去生成相應(yīng)類型的對象)。當(dāng)在各個層次的build()階段都采用這種的方式，每個上層的組件通過Factory去創(chuàng)建一個子組件的例化對象，那么任何一個組件就可以通過類似的方式來指定需要的類型。

動態(tài)的配置機(jī)制

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

OVM支持內(nèi)置動態(tài)的配置機(jī)制，來實(shí)現(xiàn)結(jié)構(gòu)化屬性和運(yùn)行時參數(shù)的配置，從而避免通過構(gòu)造函數(shù)的參數(shù)來傳遞信息。一個高層次的組件可以設(shè)置配置信息，這些信息被對應(yīng)的低層組件的獲取后使用。每個可配置的組件負(fù)責(zé)在合法的時刻去獲取自己的配置信息：結(jié)構(gòu)化配置信息，例如多少個子模塊可以被例化，可以通過build()這個階段來控制；運(yùn)行時的信息，例如在總線周期之間需要等待多少個狀態(tài)才注錯，可以通過組件的build()或者configure()階段來實(shí)現(xiàn)，他們也可以在run()這個階段來實(shí)現(xiàn)。OVM提供了一個API來實(shí)現(xiàn)這個配置信息的設(shè)置和獲取的過程。如代碼段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

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

代碼段4：

　　class dly_test extends ovm_test;

　　 virtual function void build()

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

　　 …..

　　 endfunction

　　…

　　endclass

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

測試作為驗(yàn)證的頂層

標(biāo)準(zhǔn)驗(yàn)證平臺的結(jié)構(gòu)中有一個頂層的模塊(top)，在頂層模塊中例化了DUT(alu)，DUT接口(alu_if)和一個頂層的類(test_env)；頂層的類(test_env)即驗(yàn)證環(huán)境中包含了驗(yàn)證平臺的所有組件，可以在這個架構(gòu)中應(yīng)用的SystemVerilog技術(shù)例如約束隨機(jī)數(shù)的產(chǎn)生和功能覆蓋率。

圖1 標(biāo)準(zhǔn)驗(yàn)證平臺的頂層結(jié)構(gòu)

在標(biāo)準(zhǔn)的驗(yàn)證架構(gòu)中，如圖1所示，頂層的對象是一個環(huán)境類，其中嵌入了激勵產(chǎn)生器。這限制了添加和修改測試的靈活性。

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

圖2 測試作為驗(yàn)證的頂層

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

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

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

3.Factory的重寫，可以為MAC的測試動態(tài)地創(chuàng)建一個驗(yàn)證環(huán)境。

4.配置信息，可以為MAC的測試動態(tài)地配置驗(yàn)證環(huán)境。

相對于標(biāo)準(zhǔn)的驗(yàn)證平臺，測試作為驗(yàn)證的頂層在添加和修改測試上提供了很大的靈活性。每個測試可以定義它自己特定的配置信息，在編譯完所有的測試和驗(yàn)證組件之后，每個測試可以不用重新編譯就能運(yùn)行，因?yàn)槊總€測試在它運(yùn)行的時候可以動態(tài)的創(chuàng)建和配置驗(yàn)證架構(gòu)。

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

激勵產(chǎn)生與驗(yàn)證架構(gòu)分離

圖3 標(biāo)準(zhǔn)的激勵產(chǎn)生模塊

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

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

圖4 層次化的激勵產(chǎn)生模塊

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

作者：鐘文楓

　　應(yīng)用工程師

　　Mentor Graphics

　　ahan.mail@g mail.com