基于隨機測試的SoC系統(tǒng)級功能驗證方法的研究

目前，基于RTL級（Register Transfer Level）的SoC（System-on-Chip）驗證技術存在著許多局限性。這是因為：(1)SoC硬件部分的結構越來越復雜，致使在RTL級進行SoC驗證的時間開銷越來越大[1-2]; (2)在RTL級，SoC的硬件和軟件部分需要分別采用硬件描述語言和高級語言進行描述，這不僅增加了軟、硬件設計和驗證人員間在交流上的困難，而且增加了系統(tǒng)設計人員對軟、硬件劃分方案進行評估的困難[3];(3)設計完成SoC硬件系統(tǒng)的RTL級模型后，才能進行SoC軟、硬件系統(tǒng)的協(xié)同仿真和驗證，增加了SoC系統(tǒng)產(chǎn)生功能性錯誤的可能性，延長了系統(tǒng)的開發(fā)周期[4-5]。因此，使SoC的驗證工作從更高抽象級的系統(tǒng)級開始進行，從而盡早地發(fā)現(xiàn)功能性錯誤，縮短SoC系統(tǒng)的開發(fā)周期是十分必要的。

在SoC的驗證工作中，最重要的問題是構建測試平臺TB(Test Bench)，而構建測試平臺的核心則是設計測試向量TC(Test Case)。因此，較短的測試向量的生成時間以及較高的測試向量的功能覆蓋率就成為驗證工作中最為關鍵的問題。目前，采用隨機測試向量的驗證方法被認為是解決這一問題最便捷和最有效的驗證方法[2]，該方法的特征就是隨機地從被驗證對象DUV(Design Under Verification)測試激勵輸入域中任意地或適當加以控制地選取測試向量。因此，如何隨機地生成測試向量是進行隨機驗證的關鍵。

SCV(SystemC Verification Standard)是OSCI(Open SystemC Initiative)組織公布的系統(tǒng)級驗證標準，是一種基于SystemC類庫的公開源代碼的C++類庫，SCV驗證庫可以提供直接隨機測試、帶權重的隨機測試和帶約束的隨機測試三種向量的生成方法。因此，SCV標準允許用戶在較高的抽象級上構建測試平臺并允許用戶隨機地寫入測試程序，具有靈活性高、測試平臺可復用、驗證周期短等特點。

本文將基于SystemC和SCV驗證庫來創(chuàng)建系統(tǒng)級的測試平臺，通過對一個具有4×4包交換功能的系統(tǒng)級模型的驗證，來研究基于隨機向量的SoC系統(tǒng)級的功能驗證方法。

1 系統(tǒng)級功能測試平臺

SoC系統(tǒng)級的功能驗證是針對SoC系統(tǒng)級的功能模型進行的驗證，其目的是驗證SoC系統(tǒng)級功能模型是否符合功能規(guī)范說明的要求。在進行功能驗證前，首先應根據(jù)功能規(guī)范說明建立測試平臺，其核心內(nèi)容是設計測試向量。測試平臺不僅能夠?qū)y試向量輸入到被驗證對象上，而且能夠獲取被驗證對象產(chǎn)生的結果，該結果可以用來判定被驗證對象功能的正確性，如圖1所示。

為了驗證隨機測試在SoC系統(tǒng)級進行功能驗證的有效性，在系統(tǒng)級構建以AMBA總線為核心、以CPU為主設備、以存儲器和4×4包交換模塊為從設備的SoC功能模型，并針對4×4包交換模塊的功能進行測試。

　　系統(tǒng)級測試平臺的核心由4個發(fā)送模塊（Sender0～Sender3）、4個接收模塊（Receiver0～Receiver3）和4×4包交換模塊組成，如圖2所示。其中發(fā)送模塊用來隨機地生成數(shù)據(jù)包并將數(shù)據(jù)包送入包交換模塊；接收模塊用來從包交換芯片中讀取數(shù)據(jù)包。

4×4包交換模塊主要由4個帶FIFO的輸入/輸出端口（IN0~IN3，OUT0～OUT3）和4個移位寄存器（R0~R3）組成，待交換的數(shù)據(jù)包則由16位組成，分別為4位目的端口號、4位源端口號以及8位交換數(shù)據(jù)。該包交換芯片的主要功能規(guī)范如下：

(1)每個端口均可以正確地發(fā)送或者接收數(shù)據(jù)包。
(2)每個輸入端口均可以正確地將數(shù)據(jù)包發(fā)送到多個不同的端口。
(3)移位寄存器能夠從對應的FIFO中正確地讀取數(shù)據(jù)包，并按R3→R2→R1→R0→R3的順序進行移位。
(4)每個輸出端口均可以正確地按設定的比例輸出數(shù)據(jù)包。
(5)輸入端口FIFO為空時，數(shù)據(jù)包可以送入該FIFO; 輸入端口FIFO為滿時，數(shù)據(jù)包不能送入該FIFO。

2 測試向量和驗證結果

通常，基于SCV隨機測試向量的驗證工作分為隨機驗證環(huán)境配置、基于直接隨機測試向量的驗證、基于帶權重的隨機測試向量的驗證以及基于帶約束的隨機測試向量的驗證四個階段。本文的驗證環(huán)境建立在Sun Blade 2000工作站上，通過集成SCV驗證庫以及相應的編譯、連接和調(diào)試工具構建而成。4×4包交換芯片系統(tǒng)級功能模型的驗證工作在各階段的時間開銷分別為30h、15h、35h和45h。

2.1 基于直接隨機測試向量的驗證

針對規(guī)范1～規(guī)范3的驗證，采用直接隨機測試向量的驗證方法。在描述中，包的數(shù)據(jù)部分被定義為sc_int8>的整數(shù)類型，它的有效數(shù)值范圍是[-128，127]；包的目的端口號被定義為dest[0]～dest[3]的布爾變量類型，它的有效數(shù)值范圍是[0，15]；而包的源端口號則在實例化的過程中被分別對應標記為0～3。因此，采用SCV生成直接隨機測試向量用數(shù)據(jù)包的過程主要是隨機化包的目的端口號和包的交換數(shù)據(jù)，如下所示：

//生成包的目的端口號
sc_uint4> dest;
scv_smart_ptrd;
d->keep_only(1,15);
d->next();
dest=(sc_uint4>)*d;
pkt_data.dest0=dest[0];
pkt_data.dest1=dest[1];
pkt_data.dest2=dest[2];
pkt_data.dest3=dest[3];
//生成包的交換數(shù)據(jù)
scv_smart_ptrp;
p->keep_only(-128,127);
p->next();
pkt_data.data=(sc_int8>)*p;

從生成的10 000個隨機數(shù)據(jù)包中任意截取10個，得到如表1所示的結果。由表1可以看出：

(1)包的目的端口號是隨機的數(shù)字0～3，包的數(shù)據(jù)是隨機的數(shù)據(jù)-128～+127。
(2)輸入模塊可以正確地將發(fā)送包送入各個輸入端口，
輸出模塊可以正確地從輸出端口讀出輸出包。
(3)發(fā)送包目的端口號的個數(shù)等于輸出包的總數(shù)。
以上結果表明，4×4包交換芯片系統(tǒng)級模型的每個端口均可以正確地發(fā)送或者接收數(shù)據(jù)包，每個輸入端口均可以正確地將數(shù)據(jù)包傳送到多個不同的端口。
在某時間段內(nèi)，采集R0～R3移位前后的數(shù)值，得到如表2所示的結果。 由表2可以看出：

(1)若FIFO中有新的數(shù)據(jù)包，則各個寄存器能夠從對應的FIFO中正確地讀取這些新的數(shù)據(jù)包；否則，各個寄存器將保持當前值。
(2)各個寄存器接收新的數(shù)據(jù)后就進行移位，移位的順序是R3→R2→R1→R0→R3。

2.2 基于帶權重的隨機測試向量的驗證

針對規(guī)范4的驗證，采用帶權重的隨機測試向量的驗證方法。在測試中，端口0作為測試向量的輸入端口，端口0、1、2、3作為測試向量的輸出端口。其中，端口0、1、2、3的包輸出比例分別為70%、10%、10%和10%。因此，采用SCV生成Sender0帶權重的隨機測試向量用數(shù)據(jù)包描述為：

if(pkt_data.id==0)
{scv_bagdist; //定義含權重分布信息的包用于隨機化

　　dist.add(1,70); //定義OUT0的輸出比例
dist.add(2,10); //定義OUT1的輸出比例
dist.add(4,10); //定義OUT2的輸出比例
dist.add(8,10); //定義OUT3的輸出比例
scv_smart_ptrd; //對帶權重的包隨機化
d->set_mode(dist);
d->next();
dest=(sc_uint4>)*d; //賦數(shù)據(jù)包目的端口號
pkt_data.dest0=dest[0];
pkt_data.dest1=dest[1];
pkt_data.dest2=dest[2];
pkt_data.dest3=dest[3];
}

使Sender0生成10 000個隨機數(shù)據(jù)包，得到如表3所示的結果?？梢钥闯觯好總€輸出端口輸出數(shù)據(jù)包數(shù)目的比例與設定比例基本一致。

2.3 基于帶約束的隨機測試向量的驗證

針對規(guī)范5的驗證，采用帶約束的隨機測試向量的驗證方法。在驗證中，采用的驗證策略為：當FIFO1非空時，Sender1發(fā)送非正整數(shù)的數(shù)據(jù)包；當FIFO1為空時，Sender1發(fā)送正整數(shù)的數(shù)據(jù)包。因此，采用SCV生成Sender1帶約束的隨機測試向量用數(shù)據(jù)包的約束定義為：

class fifoconstraint: public scv_constraint_base{
public:
scv_smart_ptr data;
scv_smart_ptr fifo.in1.status;
SCV_CONSTRAINT_CTOR (fifoconstraint){
SCV_CONSTRAINT(*data=0!fifo.in1.
status);
SCV_CONSTRAINT(*data>0 fifo.in1.status);}
};

在某時間段內(nèi)，從生成的10 000個隨機數(shù)據(jù)包中，采集一部分FIFO1和各端口中的數(shù)值，得到如表4所示的結果。由表4可以看出，當發(fā)送包的數(shù)據(jù)部分為非正整數(shù)時，F(xiàn)IFO1無交換數(shù)據(jù)輸入，輸出端也無交換數(shù)據(jù)輸出；當發(fā)送包的數(shù)據(jù)部分為正整數(shù)時，F(xiàn)IFO1讀入交換數(shù)據(jù)，相應輸出端也輸出交換數(shù)據(jù)。即當FIFO1非空時，Sender1發(fā)送了非正整數(shù)的數(shù)據(jù)包，表示數(shù)據(jù)包不能送入FIFO1；當FIFO1為空時，Sender1發(fā)送了正整數(shù)的數(shù)據(jù)包，數(shù)據(jù)包可以送入FIFO1。

從SoC的RTL級開始進行的驗證工作容易造成設計周期的長跌宕，因此，在更高層次的系統(tǒng)級尋求高效的功能驗證方法具有十分重要的現(xiàn)實意義。實驗結果表明，本文提出的基于隨機向量的SoC系統(tǒng)級功能驗證方法，不僅能夠獲得較好的功能覆蓋率，而且能夠盡早地發(fā)現(xiàn)SoC的功能性錯誤。此外，還說明：

(1)三種隨機驗證方法對功能規(guī)范的依賴程度、時間開銷和驗證效率不盡相同。直接隨機測試向量生成方法對功能規(guī)范的依賴程度最低，但時間開銷最高、驗證效率最低；帶權重的隨機測試向量生成方法對功能規(guī)范的依賴程度較高，但時間開銷最低、驗證效率較高；帶約束的隨機測試向量生成方法對功能規(guī)范的依賴程度最高，但時間開銷較高、驗證效率最高。在實際的驗證工作中可以選擇其中一種或組合兩種以上的方法進行驗證。

(2)直接隨機測試向量生成方法適用于做黑盒測試驗證，適于對驗證對象進行定性分析；帶權重的隨機測試向量和帶約束的隨機測試向量方法適用于做白盒測試驗證，適于對驗證對象做定量分析。