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

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

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

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

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

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

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

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

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

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

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

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

代碼段4：

　　class dly_test extends ovm_test;

　　 virtual function void build()

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

　　 …..

　　 endfunction

　　…

　　endclass

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者：鐘文楓

　　應(yīng)用工程師

　　Mentor Graphics

　　ahan.mail@g mail.com