本文分六個(gè)部分：

1. 驗(yàn)證的策略篇之一：設(shè)計(jì)的流程

2. 驗(yàn)證的策略篇之二：驗(yàn)證的層次

3. 驗(yàn)證的策略篇之三：驗(yàn)證的透明度

4. 驗(yàn)證的策略篇之四：激勵(lì)的原則

5. 驗(yàn)證的策略篇之五：檢查的方法

6. 驗(yàn)證的策略篇之六：集成的環(huán)境

驗(yàn)證的策略篇之一：設(shè)計(jì)的流程

我們?cè)谏弦徽滦酒?芯片驗(yàn)證全視 中給出過芯片產(chǎn)品開發(fā)的流程圖，而在描述中我們將開發(fā)流程分為了兩條主線：

• 芯片功能的細(xì)分

• 不同人員的任務(wù)分配

即是說不同人員需要在硅前的不同階段實(shí)現(xiàn)和測(cè)試芯片的模塊功能。

如果我們從另外一個(gè)角度看，芯片的開發(fā)即是將抽象級(jí)別逐次降低的過程，從一開始的抽象自然語言描述到硬件的HDL語言描述再到最后的門級(jí)網(wǎng)表。而在我們已經(jīng)介紹過RTL設(shè)計(jì)和門級(jí)網(wǎng)表以后，這里需要引入一個(gè)目前更高抽象級(jí)的描述TLM（事務(wù)級(jí)模型，transaction level models）。

TLM一般會(huì)在早期用于構(gòu)建硬件的行為，側(cè)重于它的功能描述，不需要在意時(shí)序。同時(shí)各個(gè)TLM模型也會(huì)被集成為一個(gè)系統(tǒng)，用來評(píng)估系統(tǒng)的整體性能和模塊之間的交互。同時(shí)TLM模型在早期的設(shè)計(jì)和驗(yàn)證中，如果足夠準(zhǔn)確的話，甚至可以替代驗(yàn)證人員的參考模型，一方面為硬件設(shè)計(jì)提供了可以參考的設(shè)計(jì)（來源于系統(tǒng)描述側(cè)），一方面也加速了驗(yàn)證（無需再構(gòu)建參考模型，而且TLM模型足夠準(zhǔn)確反映硬件描述）。

TLM模型的需求和ESL開發(fā)

早期的芯片開發(fā)模式是遵循先從系統(tǒng)結(jié)構(gòu)設(shè)計(jì)、到芯片設(shè)計(jì)制造、再到上層軟件開發(fā)的。但隨著產(chǎn)品開發(fā)的壓力，一方面我們需要讓系統(tǒng)人員、硬件人員和軟件人員都保持著充沛的工作量，同時(shí)對(duì)于一個(gè)芯片項(xiàng)目而言，我們也希望硬件人員和軟件人員可以盡可能的同時(shí)進(jìn)行開發(fā)。這聽起來怎么可能？畢竟芯片還沒有制造出來，沒有開發(fā)板怎么去構(gòu)建軟件呢？在這里我們系統(tǒng)結(jié)構(gòu)人員會(huì)在早期構(gòu)建一個(gè)高抽象級(jí)的系統(tǒng)，同時(shí)該系統(tǒng)必須具備該有的基本功能和各模塊的接口保持信息交互，通過將功能描述變成可運(yùn)行的系統(tǒng)，讓硬件人員和軟件人員可以在早期就利用該系統(tǒng)進(jìn)行硬件參照和軟件開發(fā)。這種可以為復(fù)雜系統(tǒng)建立模型，讓多個(gè)流程分支并行開發(fā)的方式被稱作ESL（電子系統(tǒng)級(jí)，electronic system-level）開發(fā)。

傳統(tǒng)的系統(tǒng)設(shè)計(jì)流程

傳統(tǒng)的系統(tǒng)設(shè)流程是瀑布形式（waterfall）開發(fā)的，這種順序開發(fā)的方式存在明顯的邊界：

• 時(shí)間邊界：不同的開發(fā)子過程之間是保持順序執(zhí)行的，幾乎沒有可以交疊的空間來縮短整體的項(xiàng)目交付時(shí)間。

• 組織邊界：不同的開發(fā)小組之間的交流是計(jì)劃是發(fā)生在前一個(gè)過程結(jié)束，后一個(gè)過程開始的，這也引入了額外的溝通成本。

ESL系統(tǒng)設(shè)計(jì)流程

為了模糊或者融合這種邊界，ESL開發(fā)流程通過建立虛擬原型（virtual prototype），又或者稱之為TLM模型來使得整個(gè)參與到系統(tǒng)開發(fā)的小組做并行開發(fā)。之所以可以有這種魔力，是因?yàn)門LM模型不再是一種無法被硬件開發(fā)和軟件開發(fā)利用的抽象描述，而是一種更早期開發(fā)的軟件模型。所以在ESL開發(fā)的協(xié)助下，更多的自開發(fā)流程可以更早跟隨系統(tǒng)設(shè)計(jì)一塊進(jìn)行開發(fā)，那么從整體上來看這種方式有助于縮短芯片開發(fā)的時(shí)間。

除此之外，在前期產(chǎn)品定義的階段有相對(duì)可量化的模型，更有助于早期驗(yàn)證產(chǎn)品的功能、性能是否滿足客戶要求，也能減輕一些低配置性能的風(fēng)險(xiǎn)和降低過多設(shè)計(jì)的成本。這是為什么呢？有以下幾點(diǎn)：

1. 在早期定義產(chǎn)品的時(shí)候，市場(chǎng)部會(huì)將客戶對(duì)于產(chǎn)品特性收集回來，而交由系統(tǒng)框架師來定義芯片結(jié)構(gòu)。這中間會(huì)存在一些問題，例如系統(tǒng)框架師無法深入到局部功能更無從列舉出所有的用例來判斷功能是否滿足，而對(duì)于性能測(cè)試方面也只能通過一些表格化數(shù)據(jù)做出靜態(tài)估計(jì)。這時(shí)候，TLM模型可以幫助在系統(tǒng)級(jí)別完成模型搭建和虛擬系統(tǒng)集成，甚至幫助測(cè)算系統(tǒng)的性能，這對(duì)于系統(tǒng)框架師而言會(huì)有更多的信心來給出合理的結(jié)構(gòu)配置。

2. 正由于可以在早期做出性能評(píng)估（而且快速、發(fā)生在芯片結(jié)構(gòu)的定義階段），框架師可以及時(shí)地做出資源調(diào)整來滿足用戶的需求。否則，盡管芯片可能是低缺陷率的，但如果它的執(zhí)行速度不夠快、功耗又過高，那么也仍然無法滿足客戶的要求。

3. 過度設(shè)計(jì)的結(jié)構(gòu)就跟給一只襪子綴上水鉆一樣不差但也沒有必要。客戶給的報(bào)價(jià)擺在那里，你的設(shè)計(jì)越過度，不但意味著成本的增長(zhǎng)，也意外著更高的復(fù)雜度和風(fēng)險(xiǎn)。 

ESL和TLM對(duì)系統(tǒng)模型的要求使得需要有一門語言可以：

• 縱深多個(gè)抽象級(jí)別來進(jìn)行模型描述

• 標(biāo)準(zhǔn)開放的語言

• 高效的仿真性能和調(diào)試接口

• 被主流仿真工具支持

• 本身包含TLM事務(wù)級(jí)傳輸?shù)慕涌?/span>

這樣的一本語言即是我們接下來介紹的SystemC。

SystemC介紹

SystemC是可以滿足TLM模型開發(fā)的一種語言。嚴(yán)格來講，它本身不是一種語言，而是建立在C++之上的一種類庫(kù)（class library）。SystemC語言可以用來描述系統(tǒng)級(jí)別的硬件行為，而這一點(diǎn)恰是其它語言無法滿足的。SystemC從2006年被IEEE收入IEEE 1666標(biāo)準(zhǔn)，它本身也易于學(xué)習(xí)，對(duì)于有C++/Java基礎(chǔ)和硬件設(shè)計(jì)概念的人使用起來都不需要太多的學(xué)習(xí)成本。SystemC語言介紹不在本章的重點(diǎn)，所以我們略去它的更多的語言特性介紹。

語言的抽象級(jí)比較

而不同的硬件領(lǐng)域使用到的建模語言都有它們各自適合的抽象級(jí)，下圖就指出了各個(gè)語言擅長(zhǎng)的抽象級(jí)領(lǐng)域。從左至右，VHDL和Verilog主要用作RTL仿真和數(shù)字電路的綜合，它們也用來在早期搭建一些驗(yàn)證平臺(tái)。對(duì)于SystemVerilog/Vera/e是用來做功能驗(yàn)證語言的，這其中也包括了它們的隨機(jī)約束重要特性。同時(shí)我們也可以發(fā)現(xiàn)SystemVerilog本身可以用來描述硬件做RTL仿真和門級(jí)綜合。在此之上，SystemC關(guān)注的地方要更偏向于系統(tǒng)層，它在結(jié)構(gòu)層面上可以做更高抽象級(jí)的描述，而本身也無法去描述電路的綜合網(wǎng)表，但它能夠以自己為平臺(tái)為上層的軟件開發(fā)做準(zhǔn)備。而Matlab和其它語言被用在了數(shù)字信號(hào)處理上面用來描述和驗(yàn)證算法。

傳統(tǒng)的系統(tǒng)集成視角

我們前面已經(jīng)提到，傳統(tǒng)的瀑布開發(fā)模型無法讓硬件人員和軟件人員在系統(tǒng)結(jié)構(gòu)定義早期就進(jìn)入。對(duì)于硬件的設(shè)計(jì)人員和驗(yàn)證人員而言他們都需要等待系統(tǒng)定義完成之后將功能描述文檔分別做出自己的翻譯來建立可綜合模型和參考模型。軟件人員只有在硬件流片以后才會(huì)真正開始進(jìn)行軟件開發(fā)，盡管目前的FPGA有著比硬件更快的仿真優(yōu)勢(shì)，但無論從時(shí)間段（硬件設(shè)計(jì)的后期）還是從速度（相比軟件模型）而言，仍然不是理想的軟件開發(fā)平臺(tái)。我們可以認(rèn)為FPGA等硬件加速工具對(duì)于硅后系統(tǒng)測(cè)試有積極意義，但是對(duì)于更上層的軟件層開發(fā)的幫助則并沒有那么明顯。

ESL系統(tǒng)集成視角

新型的ESL系統(tǒng)開發(fā)方式會(huì)在系統(tǒng)定義階段就建立TLM模型，這一模型的建立會(huì)對(duì)系統(tǒng)人員、硬件設(shè)計(jì)人員、驗(yàn)證人員和軟件開發(fā)人員都有顯著幫助：

• 系統(tǒng)人員在TLM模型集成系統(tǒng)上會(huì)更容易評(píng)估系統(tǒng)性能

• 硬件設(shè)計(jì)人員會(huì)同時(shí)利用功能描述文檔和TLM模型更準(zhǔn)確地翻譯為可綜合的RTL設(shè)計(jì)

• 驗(yàn)證人員甚至可以直接將TLM模型作為參考模型集成到驗(yàn)證環(huán)境中，省去了額外開發(fā)參考模型的時(shí)間

• 軟件開發(fā)人員也可以在TLM集成后的虛擬系統(tǒng)上面開發(fā)軟件，而當(dāng)芯片真正出片以后，只需要做一些基于實(shí)際硬件的軟件移植，這將大大提前軟件開發(fā)的起點(diǎn)

TLM建模有這么多的優(yōu)點(diǎn)，然而在真正考慮施行ESL系統(tǒng)集成流程上面，我們也需要考慮到一些實(shí)際的問題：

• TLM建模對(duì)于系統(tǒng)人員而言有更高的技能要求。這不但需要他們掌握SystemC開發(fā)，同時(shí)也需要他們有硬件描述的基礎(chǔ)。在此之上，他們的工作量將會(huì)同時(shí)包括功能描述文檔和TLM模型，并且TLM需要準(zhǔn)確翻譯功能描述文檔，確保一致性。對(duì)于從傳統(tǒng)流程邁向ESL流程而言，我們可能需要做一些妥協(xié)，引入專門的虛擬建模（virtual prototyping）團(tuán)隊(duì)來協(xié)助系統(tǒng)人員翻譯功能描述文檔，而他們的共同產(chǎn)出也將最終作為一致的參考標(biāo)準(zhǔn)。

• 盡管已經(jīng)有了可以被綜合的SystemC的子集和代碼規(guī)范，目前這種方式仍然沒有得到業(yè)界的青睞。不過，在某一個(gè)硬件模塊沒有就位，或者想加快仿真速度的時(shí)候，我們甚至可以臨時(shí)將原先的硬件設(shè)計(jì)用TLM模型替換。這一點(diǎn)的前提是，系統(tǒng)的仿真行為保持不變，而且TLM模型接口上的時(shí)序可以滿足HDL仿真的要求。

• 當(dāng)TLM模型被驗(yàn)證環(huán)境復(fù)用時(shí)，就需要TLM與驗(yàn)證環(huán)境之間保持標(biāo)準(zhǔn)接口（TLM interface），這樣方便TLM模型的插拔。

• 當(dāng)TLM用于軟件開發(fā)時(shí)，這就要求TLM被盡早集成到一起作為整體系統(tǒng)為軟件開發(fā)所用。因?yàn)檐浖_發(fā)環(huán)節(jié)中針對(duì)某一個(gè)功能模塊的軟件開發(fā)仍然是建立在整個(gè)芯片系統(tǒng)（至少是子系統(tǒng)之上）的。所以TLM模型之間也需要有標(biāo)準(zhǔn)接口可以更快速地實(shí)現(xiàn)系統(tǒng)集成。

目前我們常見的設(shè)計(jì)流程仍然是瀑布開發(fā)時(shí)，或者類ESL開發(fā)。這里類ESL開發(fā)指的是開發(fā)流程并沒有完全遵循上述流程，而是在一些地方引入了TLM建模。例如下面這張圖，由于系統(tǒng)人員的技能限制，項(xiàng)目開發(fā)需要額外引入虛擬建模團(tuán)隊(duì)。此外，由于地域上的限制，虛擬建模團(tuán)隊(duì)主要服務(wù)的對(duì)象是軟件開發(fā)一側(cè)，而他們與硬件設(shè)計(jì)、驗(yàn)證團(tuán)隊(duì)的溝通較少。這種類ESL的開發(fā)可能有多種組合，但我們需要警惕的是，在方便軟件開發(fā)早期進(jìn)入項(xiàng)目時(shí)，TLM模型是否會(huì)同系統(tǒng)定義保持絕對(duì)的一致性，從而為硬件和軟件方提供文本和代碼參考。

從圖上來看，這種類ESL的方式是存在風(fēng)險(xiǎn)的，因?yàn)樘摂M建模團(tuán)隊(duì)從系統(tǒng)定義到TLM模型的過程就存在二次翻譯，如果翻譯不準(zhǔn)確，存在疏漏，那么可以想象基于TLM模型的軟件開發(fā)不會(huì)那么容易被移植到真正的硬件系統(tǒng)上面，因?yàn)橛布旧硪彩嵌畏g。所以，理想的合作邊界應(yīng)該如下圖一樣。虛擬建模首先需要和系統(tǒng)定義保持原義的一致性，而硬件和軟件則可以將TLM模型視為功能描述的一致性翻譯，然后各自在TLM模型上進(jìn)行開發(fā)。

下篇文章我們將會(huì)探討《驗(yàn)證的層次》，以及在各個(gè)層次上面的驗(yàn)證方法。

驗(yàn)證的策略篇之二：驗(yàn)證的層次

從系統(tǒng)定義階段開始，我們就會(huì)將芯片系統(tǒng)劃分為子系統(tǒng)，進(jìn)而又為每個(gè)子系統(tǒng)劃分為不同的功能模塊，直到劃分為復(fù)雜度合適的模塊。而到了設(shè)計(jì)階段，我們又會(huì)按照自底向上的方式開始做硬件設(shè)計(jì)和集成。從定義階段到設(shè)計(jì)階段再到后端部分，我們整個(gè)硅前的流程都是將芯片按照層次劃分的，一般我們稱之為芯片系統(tǒng)級(jí)（chip level/system level）、子系統(tǒng)級(jí)（sub-system level）和模塊級(jí)（module level/unit level），這種層次劃分的方式對(duì)于芯片的好處有哪些呢？

1. 便于拆解功能模塊，實(shí)現(xiàn)人員的并行工作協(xié)同，這一點(diǎn)是從項(xiàng)目執(zhí)行效率出發(fā)的。

2. 對(duì)于系統(tǒng)定義而言，這是從主要的功能、性能要求量化為系統(tǒng)不同模塊定義的方法。

3. 從設(shè)計(jì)和驗(yàn)證角度出發(fā)，合適的復(fù)雜度模塊也有助于估計(jì)合適的工作量和人員分配。設(shè)計(jì)最終是通過模塊化來集成的，而驗(yàn)證的環(huán)境在模塊化以后，也可以方便在更高級(jí)的驗(yàn)證環(huán)境中復(fù)用。

4. 對(duì)于后端，在進(jìn)行了合理的區(qū)域劃分后，模塊和SoC可以并行進(jìn)行后續(xù)的物理設(shè)計(jì)流程，在每個(gè)設(shè)計(jì)階段再合成進(jìn)行相關(guān)電源設(shè)計(jì)、時(shí)序分析等設(shè)計(jì)項(xiàng)檢查?；谀K化的設(shè)計(jì)最終再進(jìn)行SoC級(jí)別的設(shè)計(jì)檢查并通過流片要求。

如果我們是在為一款手機(jī)設(shè)計(jì)通訊芯片，那么如圖顯示，一開始系統(tǒng)定義階段可能要規(guī)劃出來這么多的功能模塊，而且還需要考慮模塊的性能因素。每一款芯片都會(huì)包括多個(gè)子系統(tǒng)，而每個(gè)系統(tǒng)也會(huì)包含多個(gè)功能模塊，從舉的這款手機(jī)通訊芯片來看，他包括的功能子系統(tǒng)有：

• 處理器子系統(tǒng)

• 協(xié)處理器系統(tǒng)

• 本地存儲(chǔ)系統(tǒng)

• 外部存儲(chǔ)控制器系統(tǒng)

• 數(shù)據(jù)接口系統(tǒng)

• 系統(tǒng)模塊外設(shè)

• 多媒體子系統(tǒng)

• 調(diào)制解調(diào)子系統(tǒng)

對(duì)于核心模塊調(diào)制解調(diào)子系統(tǒng)來看，其中的2G/3G/4G又因?yàn)樽陨淼膹?fù)雜性依次提高，可以進(jìn)一步作為獨(dú)立的子系統(tǒng)來對(duì)待，進(jìn)而細(xì)分下去。所以，如何劃分層次，我們一般會(huì)從如下幾個(gè)角度考慮：

• 系統(tǒng)的復(fù)雜性：如果該系統(tǒng)相對(duì)獨(dú)立，那么它自身有作為子系統(tǒng)的條件。如果它本身任然過于復(fù)雜，可以進(jìn)一步細(xì)分。

• 芯片集成的便利性：對(duì)于頂層芯片繼承而言，應(yīng)該一個(gè)合適子系統(tǒng)應(yīng)該與外界應(yīng)該有清晰的功能邊界，例如系統(tǒng)信號(hào)邊界、標(biāo)準(zhǔn)總線邊界、與其它子系統(tǒng)交互的邊界，同時(shí)這些信號(hào)邊界也盡可能保持穩(wěn)定和精簡(jiǎn)，這是從頂層集成的工作量和后端布局布線的角度出發(fā)的。

• 驗(yàn)證的階段：驗(yàn)證人員需要清楚哪些功能點(diǎn)在模塊級(jí)驗(yàn)證、哪些屬于子系統(tǒng)和芯片系統(tǒng)、是否有必要在不同級(jí)別重復(fù)驗(yàn)證、最終各個(gè)層次是否會(huì)保證驗(yàn)證完備性。

• 后端的流程：如果一個(gè)子系統(tǒng)占到了芯片整體面積的10%以上，那么后端就沒有理由不考慮將其單獨(dú)做綜合，因?yàn)檫@樣子系統(tǒng)綜合有助于后期整個(gè)芯片綜合的收斂速度。

在這里，我們將主要從驗(yàn)證的角度來考慮，如何選擇合適的驗(yàn)證層次到下面不同的驗(yàn)證環(huán)境中：

1. 模塊級(jí)（block level/unit level）

2. 子系統(tǒng)級(jí)（sub-system level）

3. 芯片系統(tǒng)級(jí)（chip level）

4. 硅后系統(tǒng)級(jí)（post-silicon system level）

模塊級(jí)

如果是圖中的處理器子系統(tǒng)，我們會(huì)考慮先將DMA（direct memory access）、cache緩存、和core0/core1分別展開模塊驗(yàn)證。每個(gè)模塊驗(yàn)證首先要考慮的是哪些功能點(diǎn)是可以在模塊一級(jí)完全驗(yàn)證的，這基于如下考慮：

• 內(nèi)部功能如狀態(tài)機(jī)驗(yàn)證

• 內(nèi)部數(shù)據(jù)存儲(chǔ)驗(yàn)證

• 數(shù)據(jù)打包功能、編解碼功能

• 指令執(zhí)行

• 寄存器配置

同時(shí)我們也需要考慮哪些功能無法在模塊一級(jí)被驗(yàn)證到：

• 與其它相鄰模塊的互動(dòng)信號(hào)

• 與其它子系統(tǒng)的互動(dòng)信號(hào)

• 與芯片外部的互動(dòng)信號(hào)

• 與電源開關(guān)的驗(yàn)證

這些部分我們需要考慮在更高的層次來驗(yàn)證他們。

子系統(tǒng)級(jí)

對(duì)于一個(gè)成熟的子系統(tǒng)而言，它既擁有完備的功能可以執(zhí)行專門的任務(wù)，也有足夠穩(wěn)定的接口用來在更高級(jí)做集成。與模塊相比，子系統(tǒng)更穩(wěn)定也更封閉，這對(duì)頂層集成是有好處的。也正是這種便于集成相對(duì)封閉的特征，我們可以從公司外部或者內(nèi)部得到不同的子系統(tǒng)。合格的子系統(tǒng)交付不單單包含著它的設(shè)計(jì)部分，也應(yīng)該包括如下：

• 設(shè)計(jì)包

• 驗(yàn)證包

• 遞歸測(cè)試表

• 覆蓋率收集腳本和數(shù)據(jù)

• 完整的文檔（設(shè)計(jì)、驗(yàn)證、集成、后端）

完備的交付才會(huì)增強(qiáng)頂層集成的信任，同時(shí)減少在集成過程中發(fā)生的一些接口理解分歧和參數(shù)化配置問題。

那么單就驗(yàn)證而言，除了充分驗(yàn)證內(nèi)部功能以外，對(duì)于子系統(tǒng)的外部接口如果存在參數(shù)或者編譯預(yù)處理（compiler directive）時(shí)，驗(yàn)證人員需要就這些參數(shù)和不同的編譯選項(xiàng)（可能因此產(chǎn)生不同的硬件結(jié)構(gòu)功能）給出完備驗(yàn)證。因?yàn)閺淖酉到y(tǒng)的封閉性和復(fù)用性來看，它們會(huì)在多個(gè)芯片項(xiàng)目中被使用，這對(duì)于設(shè)計(jì)復(fù)用來講是一件好事，而驗(yàn)證也需要將驗(yàn)證環(huán)境參數(shù)化來適應(yīng)硬件的參數(shù)化配置。只有充分驗(yàn)證了參數(shù)化的子系統(tǒng)，才可能讓它在不同的芯片項(xiàng)目中都能夠按照預(yù)期實(shí)現(xiàn)它的功能。

對(duì)于驗(yàn)證管理而言，子系統(tǒng)驗(yàn)證也是一個(gè)理想的可以切分的單元，因?yàn)檫@一層下面的模塊之間互動(dòng)很多，而這一層本身又趨于封閉，也即是與外圍的接口有限，所以便于在子系統(tǒng)層建立驗(yàn)證小組——包產(chǎn)到組。

芯片系統(tǒng)級(jí)

在芯片系統(tǒng)級(jí)，我們的驗(yàn)證平臺(tái)的復(fù)用性較高，這主要是因?yàn)?/span>

• 外圍的驗(yàn)證組件不需要像模塊級(jí)、子系統(tǒng)級(jí)的組件數(shù)量多且經(jīng)常需要更新，它們主要側(cè)重于驗(yàn)證芯片的輸入輸出
  

• 芯片內(nèi)部的子系統(tǒng)之間的交互、協(xié)作檢查主要交給了處理器和子系統(tǒng)，從寄存器檢查和數(shù)據(jù)檢查入手，寫直接測(cè)試（directed test）用例

在芯片系統(tǒng)級(jí)的驗(yàn)證側(cè)重于不同子系統(tǒng)之間的信號(hào)交互問題，以及實(shí)現(xiàn)更貼近實(shí)際使用的用例。這里的實(shí)際用例并非是在系統(tǒng)軟件層面的，而是將系統(tǒng)軟件層面的場(chǎng)景進(jìn)一步拆分為多個(gè)模塊互動(dòng)情景，再分類測(cè)試的。

硅后系統(tǒng)級(jí)

盡管我們硅前驗(yàn)證部分與硅后系統(tǒng)軟件開發(fā)聯(lián)系較少，但是如果可以盡早將硅后軟件開發(fā)的實(shí)際用例在硅前測(cè)試，也能夠可以發(fā)現(xiàn)一些實(shí)際使用中的問題。實(shí)際上，系統(tǒng)軟件用例和硅前的隨機(jī)測(cè)試有著互補(bǔ)的特性，對(duì)于功能驗(yàn)證上面缺陷的理解是，如果沒有被硅后測(cè)試、軟件開發(fā)、用戶使用的過程中發(fā)現(xiàn)，那么隱藏的缺陷也會(huì)永遠(yuǎn)靜靜躺在那里，也許永遠(yuǎn)也不會(huì)被發(fā)現(xiàn)（沒有零缺陷的芯片，卻有用戶沒有發(fā)現(xiàn)缺陷的芯片）。所以，如果可以將硅后的驅(qū)動(dòng)、固件和系統(tǒng)軟件盡早在硅前就引入驗(yàn)證過程的話，這可以跟硅前的驗(yàn)證方法形成互補(bǔ)，使得驗(yàn)證更加完善。

我們上面介紹了驗(yàn)證的四個(gè)階段，也給出了他們各自使用的測(cè)試場(chǎng)景。這里我們?cè)俳o出幾點(diǎn)可以遵循的原則幫助大家選擇適合的級(jí)別來進(jìn)行驗(yàn)證：

1. 如果更低的級(jí)別可以完成某一項(xiàng)功能驗(yàn)證，那么就不要在更層去驗(yàn)證它。因?yàn)楦〉尿?yàn)證環(huán)境更有利于控制激勵(lì)場(chǎng)景的產(chǎn)生，更加全面的覆蓋功能點(diǎn)。

2. 如果低層次已經(jīng)充分驗(yàn)證過某一項(xiàng)功能，那么高層次不需要重復(fù)驗(yàn)證。而對(duì)于低層次無法完全覆蓋功能點(diǎn)驗(yàn)證的時(shí)候，應(yīng)該在高層次完全覆蓋。
   

3. 如果是低層次的驗(yàn)證階段，應(yīng)該適當(dāng)?shù)乜紤]高層次的測(cè)試用例，而在低層次創(chuàng)造一些條件來進(jìn)行模擬發(fā)生。

4. 如果是高層次的驗(yàn)證階段，驗(yàn)證環(huán)境中的參考模型、數(shù)據(jù)比對(duì)、監(jiān)視器等模塊首先考慮從低層次環(huán)境復(fù)用，在無法滿足的情況下再考慮重新構(gòu)建。

5. 如果是新的模塊或者新的功能，應(yīng)該投入更多的精力和優(yōu)先級(jí)在不同層次充分驗(yàn)證。

最后，我們通過一張列表來更好的理解，不同的驗(yàn)證層次的驗(yàn)證側(cè)重、性能、使用方法：

懂得選擇一個(gè)合適的驗(yàn)證層次，并且通過在不同層次分配不同的功能驗(yàn)證點(diǎn)，是最終邁向驗(yàn)證完備性的一項(xiàng)必備技能。

下一篇文章我們將來討論《驗(yàn)證的透明度》，來看看一名驗(yàn)證師采取黑盒、白盒及灰盒測(cè)試的場(chǎng)景依據(jù)是什么。

驗(yàn)證的策略篇之三：驗(yàn)證的透明度

我們可以按照激勵(lì)的生成方式和檢查的功能點(diǎn)分布將驗(yàn)證劃分為三種基本方式：

• 黑盒驗(yàn)證

• 白盒驗(yàn)證

• 灰盒驗(yàn)證

接下來，我們逐個(gè)解釋這三種不同透明度的驗(yàn)證特征。

黑盒驗(yàn)證

如果驗(yàn)證人員對(duì)于設(shè)計(jì)的細(xì)節(jié)缺乏認(rèn)識(shí)，那么黑盒驗(yàn)證是一種合適的方式。因?yàn)轵?yàn)證環(huán)境只需要將激勵(lì)給入設(shè)計(jì)的外部接口，而檢查設(shè)計(jì)的另一側(cè)輸出就夠了。而測(cè)試的成功與否只是根據(jù)一個(gè)輸入是否得到一個(gè)正確的輸出，驗(yàn)證環(huán)境本身不會(huì)關(guān)注設(shè)計(jì)的內(nèi)部。

從上面這張圖可以看到，激勵(lì)生成器（stimulator）只負(fù)責(zé)給設(shè)計(jì)灌入激勵(lì)，監(jiān)視器（monitor）和檢查器（checker）也只查看和比較輸出信號(hào)。

黑盒驗(yàn)證的一個(gè)缺點(diǎn)是它缺少設(shè)計(jì)的透明度和激勵(lì)的可控度，而由此帶來的一些問題包括：

1. 當(dāng)測(cè)試失敗以后，無法更深層次地定位問題。對(duì)于驗(yàn)證人員而言，他只能判斷是測(cè)試是否成功，但無法將報(bào)告進(jìn)一步定位到缺陷所在的位置，與設(shè)計(jì)人員完成深度協(xié)作。

2. 這種方式對(duì)于發(fā)現(xiàn)一些較深的缺陷比較困難，因?yàn)轵?yàn)證人員無法根據(jù)設(shè)計(jì)本身給出更窄的隨機(jī)約束來定向生成一些激勵(lì)。同時(shí)，這也對(duì)設(shè)計(jì)內(nèi)部功能點(diǎn)的功能覆蓋率收斂沒有太多的幫助。

當(dāng)一些設(shè)計(jì)的接口采用標(biāo)準(zhǔn)接口時(shí)，圖中的激勵(lì)生成器或者總線功能模型可以使用復(fù)用性高的驗(yàn)證IP。這些驗(yàn)證IP一般由第三方公司提供，有時(shí)候公司內(nèi)部也有這樣的IP，它們的特點(diǎn)是像標(biāo)準(zhǔn)接口一樣易于在驗(yàn)證環(huán)境中插拔，易于控制且接口時(shí)序嚴(yán)格按照總線文檔定義。同時(shí)對(duì)于監(jiān)測(cè)器而言，它也來自于驗(yàn)證IP，這也減少了驗(yàn)證人員的工作量。所以當(dāng)模塊的接口標(biāo)準(zhǔn)化時(shí)，驗(yàn)證環(huán)境也可以復(fù)用一些驗(yàn)證IP。

由于黑盒驗(yàn)證本身不包含設(shè)計(jì)的內(nèi)部邏輯信息，所以當(dāng)設(shè)計(jì)由于缺陷做了更新或者添加新的特性之后，原有的測(cè)試列表仍然較穩(wěn)定，驗(yàn)證人員只需要對(duì)新添加的特性考慮新的測(cè)試場(chǎng)景。黑盒驗(yàn)證有利于保持測(cè)試環(huán)境的穩(wěn)定，在后續(xù)項(xiàng)目中一旦更新了設(shè)計(jì)，新的驗(yàn)證人員也只需要很少的力氣來維護(hù)繼承的驗(yàn)證環(huán)境。

白盒驗(yàn)證

相比黑盒驗(yàn)證，白盒驗(yàn)證可以彌補(bǔ)一些不足。由于驗(yàn)證人員了解設(shè)計(jì)的內(nèi)部工作邏輯、層次、信號(hào)等，他就可以對(duì)更底層的設(shè)計(jì)細(xì)節(jié)進(jìn)行測(cè)試。由于對(duì)于設(shè)計(jì)中各種組件和邏輯細(xì)節(jié)都了如指掌，這種驗(yàn)證方式可以驗(yàn)證設(shè)計(jì)是否更嚴(yán)格地遵循功能描述文檔，而且一旦測(cè)試發(fā)生失敗也可以更快速地定位到缺陷。

對(duì)于白盒驗(yàn)證的環(huán)境，我們的參考模型邏輯非常簡(jiǎn)略，甚至不需要參考模型，而只需要植入監(jiān)視器和斷言來檢查各個(gè)內(nèi)部邏輯。這種環(huán)境配置背后的原則是說，當(dāng)我們充分檢查各個(gè)邏輯驅(qū)動(dòng)和結(jié)構(gòu)以后，就不需要測(cè)試它的整體功能，因?yàn)榘缀序?yàn)證是窮舉邏輯路徑的方法。

使用白盒驗(yàn)證也面臨一些方法學(xué)上的缺陷：

1. 由于本身專注于設(shè)計(jì)內(nèi)部邏輯檢查而忽略整體功能的測(cè)試，在設(shè)計(jì)本身違反規(guī)范的情況下，白盒驗(yàn)證難以發(fā)現(xiàn)缺陷。

2. 在數(shù)據(jù)一致性檢查的方面，白盒驗(yàn)證難以從整體入手給出實(shí)際測(cè)試用例。

3. 由于白盒驗(yàn)證的測(cè)試用例很多都是從設(shè)計(jì)的細(xì)節(jié)入手，所以一旦設(shè)計(jì)發(fā)生更新，那么對(duì)于驗(yàn)證環(huán)境的維護(hù)成本就偏高。這一點(diǎn)在項(xiàng)目間復(fù)用方面帶來的影響更多，甚至新接手驗(yàn)證環(huán)境的人要付出很大的成本去理解設(shè)計(jì)細(xì)節(jié)和驗(yàn)證環(huán)境的細(xì)節(jié)。這時(shí)候白盒驗(yàn)證環(huán)境的低復(fù)用性缺點(diǎn)就暴露出來了。

灰盒驗(yàn)證

從黑盒驗(yàn)證和白盒驗(yàn)證來看，他們各自都有著優(yōu)勢(shì)和劣勢(shì)。在實(shí)際驗(yàn)證中，我們更傾向于將黑盒和白盒兩種方法摻雜在一起，讓監(jiān)視器、斷言、參考模型一同來完善驗(yàn)證。這種糅合的方式帶來的好處包括：

1. 監(jiān)視器和斷言可以有著更好的透明度來著重檢查設(shè)計(jì)的一些重要內(nèi)部邏輯。

2. 參考模型由于已經(jīng)有了斷言檢查局部邏輯的幫助，會(huì)減少很大一部分精確度，而主要專注在輸入和輸出的數(shù)據(jù)比較上。

而從復(fù)用性角度考慮，灰盒驗(yàn)證也有著靈活地變動(dòng)方式：

1. 對(duì)于新的設(shè)計(jì)，我們的驗(yàn)證人員需要更深入地理解設(shè)計(jì)本身，而采用灰盒驗(yàn)證一開始通過監(jiān)視器和斷言來進(jìn)行局部驗(yàn)證。待設(shè)計(jì)初步完善和趨向穩(wěn)定時(shí)，驗(yàn)證人員此時(shí)也有了對(duì)設(shè)計(jì)更全局的理解來構(gòu)建參考模型。又因?yàn)榍捌诒O(jiān)視器和斷言保證局部邏輯的正確，那么參考模型的構(gòu)建不需要完全精確，只需要較少的精力來實(shí)現(xiàn)。

2. 如果該設(shè)計(jì)移植到別的項(xiàng)目，盡管難免設(shè)計(jì)需要進(jìn)行局部修改，對(duì)于驗(yàn)證環(huán)境而言，灰盒驗(yàn)證的復(fù)用性優(yōu)勢(shì)就體現(xiàn)出來了。即便是新的驗(yàn)證人員接手這個(gè)驗(yàn)證環(huán)境，好的灰盒環(huán)境也可以清晰地將黑盒和白盒的部分劃分開來。在設(shè)計(jì)本身復(fù)用的項(xiàng)目中，我們首先建議打開黑盒開關(guān)，這對(duì)于新的驗(yàn)證人員來講是較低的測(cè)試成本，也無需對(duì)設(shè)計(jì)和驗(yàn)證環(huán)境了解太多。同時(shí)，這么做也可以第一時(shí)間保證原有功能的穩(wěn)定性，并反饋給設(shè)計(jì)人員新的改動(dòng)造成的影響。緊接著，應(yīng)該驗(yàn)證人員可以針對(duì)新的特性創(chuàng)建特定的黑盒測(cè)試序列，由于設(shè)計(jì)本身的穩(wěn)定，新的黑盒測(cè)試序列不需要關(guān)注與設(shè)計(jì)內(nèi)部太多。

   
   當(dāng)黑盒環(huán)節(jié)進(jìn)行完畢以后，我們可以在時(shí)間允許的情況下，有序引入白盒的開關(guān)。首先，我們應(yīng)該考慮先創(chuàng)建新的白盒斷言點(diǎn)或者是功能檢查點(diǎn)，來專注在新的功能部分。其次，在完成了新的功能點(diǎn)白盒覆蓋以后，我們?cè)倏紤]逐個(gè)打開原有的白盒功能檢查開關(guān)，逐次打開白盒檢查開關(guān)的方式我們也遵循著每次添加盡可能少的開關(guān)來跑遞歸測(cè)試，這便于發(fā)現(xiàn)問題以后可以快速定位到新打開的開關(guān)一側(cè)；并且，白盒檢查點(diǎn)的開關(guān)也有邏輯重要性的優(yōu)先級(jí)，如果之前驗(yàn)證人員足夠?qū)I(yè)的話，在他的代碼或者文檔中也應(yīng)該對(duì)這些不同白盒開關(guān)給出說明和重要性的排列，這種說明會(huì)有助于新的驗(yàn)證人員先開高優(yōu)先級(jí)的開關(guān)，而依次按照優(yōu)先級(jí)的降序來打開不同的開關(guān)。

所以灰盒驗(yàn)證不但可以繼承黑盒驗(yàn)證和白盒驗(yàn)證的優(yōu)勢(shì)，同時(shí)也對(duì)于驗(yàn)證環(huán)境在新項(xiàng)目中的復(fù)用有著明顯優(yōu)勢(shì)。

最后，我們列出一個(gè)信息比較表來量化總結(jié)黑盒驗(yàn)證、白盒驗(yàn)證和灰盒驗(yàn)證的特點(diǎn)。從上面的語言描述和下面列表的歸納我們可以一致得出，灰盒驗(yàn)證方式可以最好平衡新設(shè)計(jì)驗(yàn)證和穩(wěn)定設(shè)計(jì)驗(yàn)證復(fù)用的工作量。如果在新設(shè)計(jì)驗(yàn)證階段，驗(yàn)證人員有著充分的經(jīng)驗(yàn)來實(shí)現(xiàn)灰盒驗(yàn)證環(huán)境，將黑盒部分和白盒部分清晰劃分，考慮到日后其它驗(yàn)證人員的接手和環(huán)境復(fù)用，那么這樣的穩(wěn)定設(shè)計(jì)伴隨著復(fù)用性高的環(huán)境，在今后更多的項(xiàng)目中也能證明該設(shè)計(jì)包的復(fù)用度。在高度集成化的今天，我們衡量一個(gè)設(shè)計(jì)復(fù)用性的優(yōu)良，是從整個(gè)設(shè)計(jì)交付包（design delivery package）衡量的，這包括了我們之前提到過的設(shè)計(jì)包、驗(yàn)證包、文檔包、遞歸測(cè)試包和覆蓋率包等等。

所以無論對(duì)于設(shè)計(jì)人員還是驗(yàn)證人員也都需要從各自的角度考慮復(fù)用性，將設(shè)計(jì)的整個(gè)流程全盤考慮，也只有可以讓使用設(shè)計(jì)交付包的項(xiàng)目可以有更好的“用戶體驗(yàn)”，縮短集成時(shí)間（設(shè)計(jì)和驗(yàn)證），才是好的設(shè)計(jì)和驗(yàn)證環(huán)境。

下一篇內(nèi)容我們將進(jìn)入驗(yàn)證的環(huán)境部分，首先認(rèn)識(shí)《激勵(lì)的原則》。

驗(yàn)證的策略篇之四：激勵(lì)的原則

我們這篇文章《激勵(lì)的原則》實(shí)際上就是解決一件事情，那就是如何保證激勵(lì)源最大的自由度？因?yàn)橹挥袕沫h(huán)境結(jié)構(gòu)上保證了激勵(lì)源最大的自由度，我們才有可能在輸入一側(cè)提供更豐富的輸入組合，有條件地窮歷一些測(cè)試序列。

按照這個(gè)核心原則，我們可以將激勵(lì)的自由度按照如下去考慮評(píng)估：

• 接口類型

• 序列顆粒度

• 可控性

• 組件獨(dú)立性

• 組合自由度

我們一一來看激勵(lì)在這些方面的表現(xiàn)和評(píng)估方法。

接口類型（interface type）

首先面對(duì)一個(gè)設(shè)計(jì)的輸入接口，我們可以先判斷接口的類型，如果該設(shè)計(jì)的接口類型復(fù)雜多樣，我們也可以通過接口類型劃分，化繁為簡(jiǎn)找到從哪里下手來給出激勵(lì)。常見的接口類型可以分為如下幾種：

• 系統(tǒng)控制接口（system control interface）：常見的有時(shí)鐘、復(fù)位、安全、電源開關(guān)和這些系統(tǒng)控制信號(hào)旁生出來的控制信號(hào)，例如時(shí)鐘門控信號(hào)（clock gating signal）。

• 標(biāo)準(zhǔn)總線接口（standard bus interface）：公開的行業(yè)標(biāo)準(zhǔn)總線協(xié)議，常見的有例如AMBA總線系列協(xié)議、OCP、SRAM、MIPI系列協(xié)議等，文檔詳細(xì)，有豐富的驗(yàn)證IP提供服務(wù)。

• 非標(biāo)準(zhǔn)總線接口（non-standard bus interface）：公司內(nèi)部定義的接口，或者根據(jù)模塊功能需求定義的接口，接口時(shí)序相對(duì)簡(jiǎn)單，同時(shí)文檔也較粗略。公司內(nèi)部即使有可復(fù)用的驗(yàn)證IP，驗(yàn)證IP本身也沒有得到充分的質(zhì)量保證，而且在非標(biāo)準(zhǔn)協(xié)議和總線多樣性定制的背景中，驗(yàn)證IP的復(fù)用性較低。

• 測(cè)試接口（test interface）：該測(cè)試接口主要留給可測(cè)性（DFT，design for test）功能使用，在功能驗(yàn)證中我們只需要禁用即可。

• 其它控制接口（miscellaneous control interface）：如果被測(cè)設(shè)計(jì)是處于子系統(tǒng)中的功能模塊且與相鄰多個(gè)模塊交互的話，那么該控制接口信號(hào)的數(shù)量較多、功能較分散還有較高的復(fù)雜度；如果該設(shè)計(jì)是子系統(tǒng)，那么子系統(tǒng)從標(biāo)準(zhǔn)復(fù)用的設(shè)計(jì)角度出發(fā)，該種類型的控制接口數(shù)量會(huì)較少且功能也較集中。
  

有了清晰的分類，驗(yàn)證人員就好入手根據(jù)不同的接口類型來選擇驗(yàn)證IP或者自己著手搭建激勵(lì)組件（verification component）了。

序列顆粒度（sequence granularity）

對(duì)于不同的接口我們會(huì)引入不同的驗(yàn)證組件，每個(gè)驗(yàn)證組件一般都會(huì)包含激勵(lì)生成器（stimulus generator / driver）。激勵(lì)生成器會(huì)提供一些基本功能方法用來生成小顆粒度的激勵(lì)，同時(shí)用戶也可以進(jìn)一步做上層封裝，來從更高抽象級(jí)的角度生成大顆粒度或者是宏顆粒度的激勵(lì)序列。我們按照軟件的層概念將激勵(lì)序列顆粒度劃分為如下：

• 基本顆粒層

• 高級(jí)顆粒層

• 宏顆粒層

• 用戶自定義顆粒層

從激勵(lì)生成器提供的方法進(jìn)行繼承和封裝入手，我們可以將這些顆粒層的關(guān)系表達(dá)為：

這里我們拿出一個(gè)商業(yè)總線驗(yàn)證IP舉例，該驗(yàn)證IP包會(huì)含有基本顆粒層和高級(jí)顆粒層來生成不同級(jí)別的測(cè)試序列，一些情況下驗(yàn)證IP也提供宏顆粒層的定義來滿足更高規(guī)模的數(shù)據(jù)傳輸。這里的抽象級(jí)指的是從時(shí)序和數(shù)據(jù)量傳輸?shù)慕嵌瘸霭l(fā)，越高的抽象級(jí)，越不關(guān)注底層的時(shí)序而更重視數(shù)據(jù)量的傳輸，也是TLM（transaction level model）含義的延伸。當(dāng)驗(yàn)證人員不能從已有的各種顆粒層中生成自己期望的測(cè)試序列時(shí)，便會(huì)利用已有的基本顆粒層和高級(jí)顆粒層來構(gòu)建自己的顆粒層。

可控性（controllability）

可控性是從對(duì)不同顆粒層的控制來出發(fā)的，那么按照序列顆粒度的劃分，對(duì)應(yīng)的可控性應(yīng)該是：

從功能驗(yàn)證的周期出發(fā)，在初期階段，我們應(yīng)該從基本顆粒層中選擇，這有利于我們?cè)诮涌诘幕竟δ苤姓{(diào)節(jié)和測(cè)試不同的總線傳輸情況，這里的驗(yàn)證點(diǎn)側(cè)重于協(xié)議功能和時(shí)序檢查。隨著設(shè)計(jì)的穩(wěn)定，我們會(huì)逐漸選擇高級(jí)顆粒層和宏顆粒層，將驗(yàn)證精力逐漸轉(zhuǎn)移到數(shù)據(jù)量的一致性傳輸和性能評(píng)估上面，而這兩層的顆粒控制性也沒有像基本顆粒那樣可以細(xì)致調(diào)節(jié)到每一個(gè)參數(shù)變量，它們會(huì)同驗(yàn)證重點(diǎn)保持一致，主要提供跟數(shù)據(jù)量有關(guān)的可約束參數(shù)。

組件獨(dú)立性（component independency）

在我們將一個(gè)設(shè)計(jì)的邊界信號(hào)劃分為不同的接口類型，并且創(chuàng)建出對(duì)應(yīng)的接口驗(yàn)證組件之后，我們就應(yīng)該考慮一下各個(gè)組件之間的獨(dú)立性了。組件的獨(dú)立性實(shí)際上也是協(xié)調(diào)性的基本保障，因?yàn)橛辛霜?dú)立性，各個(gè)組件之間才會(huì)最大程度地不受另外組件的制約，同時(shí)又可以通過有效的通訊機(jī)制來實(shí)現(xiàn)組件之間的協(xié)調(diào)。我們接下來看看，要實(shí)現(xiàn)組件獨(dú)立性需要考慮的因素：

• 必須按照接口類型來劃分組件

• 對(duì)于系統(tǒng)控制信號(hào)組件，盡可能將信號(hào)的關(guān)系按照實(shí)際集成關(guān)系做控制，例如多個(gè)時(shí)鐘是否是同步關(guān)系，多個(gè)復(fù)位信號(hào)是否可以單獨(dú)控制等。

• 對(duì)于總線接口（標(biāo)準(zhǔn)或者非標(biāo)準(zhǔn)），實(shí)現(xiàn)一對(duì)一的控制關(guān)系。例如存在兩組相同的總線，那么我們應(yīng)該引入兩個(gè)總線組件分別控制，而非建立一個(gè)總線組件卻擁有兩套總線接口，后者對(duì)于有悖于可控性和復(fù)用性。

• 對(duì)于其他控制接口，應(yīng)從實(shí)際相鄰設(shè)計(jì)那里準(zhǔn)確了解各個(gè)信號(hào)的使能極性、脈沖有效還是電平有效、是否存在握手關(guān)系、時(shí)序信息等真實(shí)的設(shè)計(jì)信息，來給予日后更高層集成環(huán)境中的控制場(chǎng)景。同時(shí)又由于這部分信號(hào)偏于雜亂，在盡可能梳理信號(hào)的不同來源和功能以后，也需要在接口組件中定義封裝好的方法來實(shí)現(xiàn)靈活的驅(qū)動(dòng)。

• 驗(yàn)證環(huán)境中的系統(tǒng)控制信號(hào)組件也會(huì)跟其他接口組件發(fā)生連接，例如提供必要的時(shí)鐘和復(fù)位信息，那么這些連接也應(yīng)該遵循實(shí)際集成的情況，確保組件驅(qū)動(dòng)端的時(shí)鐘輸入與設(shè)計(jì)的時(shí)鐘輸入端保持同步。

組合自由度（combination space）

最后一個(gè)衡量因素是對(duì)上述因素的整體評(píng)估，只有通過底層的精細(xì)劃分，進(jìn)而建立抽象級(jí)更高的顆粒度，通過獨(dú)立組件之間的協(xié)調(diào)來給出激勵(lì)，才會(huì)提供較高的組合自由度。在這里，除過組件的獨(dú)立性以外，我們也需要考慮組件之間的協(xié)調(diào)方式。一般我們將協(xié)調(diào)方式分為兩種：

• 中心統(tǒng)籌式（centrally organized）：通過中心的調(diào)遣段統(tǒng)一分派給各個(gè)接口組件不同的任務(wù)，進(jìn)而產(chǎn)生不同的激勵(lì)組合場(chǎng)景。

• 分布事件驅(qū)動(dòng)式（distributed event driven）：將激勵(lì)控制權(quán)交給各個(gè)接口組件，而通過接口組件之間的通信來實(shí)現(xiàn)分布式的事件驅(qū)動(dòng)模式，即組件之間的通訊通過事件（event）、信箱（mailbox）、接口信號(hào)（interface signal）等方式實(shí)現(xiàn)同步通信。

通過上述因素，我們可以評(píng)定出一個(gè)驗(yàn)證環(huán)境中各個(gè)接口組件之間的組合是否可以提供足夠的自由度，最終有可能窮歷出預(yù)定的激勵(lì)序列。

我們下一篇內(nèi)容將帶大家認(rèn)識(shí)各種《檢查的方法》。只有檢查的方法也同樣強(qiáng)大，才能在各種可能的激勵(lì)組合面前保持一顆淡定的心。

驗(yàn)證的策略篇之五：檢查的方法

我們?cè)谏弦还?jié)《激勵(lì)的原則》里面給出了幾點(diǎn)用來評(píng)估激勵(lì)自由度的方法，在這篇文中，我們則需要考慮在各種可能的激勵(lì)組合下，如何選擇適當(dāng)?shù)臋z查來完成一項(xiàng)核心要素：檢查就是查看設(shè)計(jì)是否按照功能描述做出理應(yīng)的行為，并且識(shí)別所有錯(cuò)誤的輸出從而發(fā)現(xiàn)設(shè)計(jì)缺陷。

對(duì)于激勵(lì)我們是從接口類型來劃分的，那么在檢查階段，我們劃分則是基于被檢查邏輯的層次，這些層次指的是：

• 模塊的內(nèi)部設(shè)計(jì)細(xì)節(jié)

• 模塊的輸入輸出

• 模塊與相鄰模塊的互動(dòng)信號(hào)

• 模塊在芯片系統(tǒng)級(jí)的應(yīng)用角色

對(duì)于這些不同的檢查層次，我們會(huì)考慮采用不同的方法來應(yīng)對(duì)：

從上面這張方法選擇列表里我們可以看出，經(jīng)常使用的方法有監(jiān)測(cè)器（monitor）、斷言（assertion，用于仿真）、參考模型（reference model）、比較器（comparator/scoreboard）、直接測(cè)試和形式斷言等等。至于常用的驗(yàn)證方法和工具，我們會(huì)在下一季的《驗(yàn)證的工具篇》給大家詳細(xì)介紹，在這一篇中我們就主要的方法來看看我們之所以這樣劃分的考慮是什么。

一般而言，監(jiān)測(cè)器（monitor）是一項(xiàng)必備的組件，有了它方便我們觀察內(nèi)部信號(hào)，所以你在各個(gè)層次都可以找到監(jiān)測(cè)器的身影，而要查看設(shè)計(jì)內(nèi)部信號(hào)，另外一個(gè)可行的辦法是使用SystemVerilog綁定（bind）的特性。由于監(jiān)測(cè)器可能被置入到各種方法中，我們需要本著復(fù)用的角度，在構(gòu)建監(jiān)測(cè)器的時(shí)候考慮如下的地方：

• 監(jiān)測(cè)器一般跟激勵(lì)發(fā)生器的作用域一致。這指的是，如果該激勵(lì)發(fā)生器對(duì)應(yīng)一組總線，那么也應(yīng)該有一個(gè)對(duì)應(yīng)的監(jiān)視器來負(fù)責(zé)監(jiān)視總線的傳輸。

• 監(jiān)測(cè)器應(yīng)根據(jù)檢查的層次將信號(hào)檢測(cè)分為模塊內(nèi)部和模塊邊界。

• 對(duì)于斷言（assertion），我們主要依靠它檢查模塊的內(nèi)部邏輯細(xì)節(jié)和時(shí)序信息。利用斷言，我們可以通過仿真或者形式驗(yàn)證來測(cè)試對(duì)應(yīng)的邏輯和時(shí)序。這里，是否選用仿真或者形式驗(yàn)證的方式，給的建議是：

• 如果是模塊級(jí)別，斷言通過形式驗(yàn)證完全覆蓋設(shè)計(jì)的多數(shù)功能點(diǎn)從效率和完備性來看是可靠的。同時(shí)我們建議在子系統(tǒng)或者芯片一級(jí)創(chuàng)建基本的測(cè)試用例進(jìn)行仿真，作為形式驗(yàn)證的補(bǔ)充。

• 如果斷言驗(yàn)證的功能點(diǎn)較分散，或者主要是關(guān)切于模塊的核心邏輯、時(shí)序的時(shí)候，我們傾向于使用仿真驗(yàn)證，采取灰盒模式，用斷言來驗(yàn)證重要設(shè)計(jì)細(xì)節(jié)。

• 如果斷言總體可以覆蓋模塊的所有設(shè)計(jì)功能部分，采取形式驗(yàn)證或者白盒仿真驗(yàn)證兩種方法都是可取的。

參考模型（reference model）的構(gòu)建除過待測(cè)設(shè)計(jì)本身的尺寸、復(fù)雜度以外，也跟驗(yàn)證方法有關(guān)。從之前《驗(yàn)證的透明度》來看，白盒驗(yàn)證對(duì)于參考模型的要求是最低的，而黑盒驗(yàn)證卻會(huì)將最多的壓力交給參考模型。

就比較器（comparator）而言，它的結(jié)構(gòu)相對(duì)簡(jiǎn)單。一般依靠足夠穩(wěn)定的監(jiān)測(cè)器和準(zhǔn)確的參考模型，比較器只需要將檢測(cè)的待測(cè)輸出和參考模型的輸出做比較，給出充分的比較信息。在測(cè)試用例結(jié)束的時(shí)候可以給出自定義的測(cè)試報(bào)告即可。

當(dāng)模塊完成了模塊測(cè)試、子系統(tǒng)測(cè)試，遷入到芯片系統(tǒng)級(jí)測(cè)試以后，我們會(huì)在系統(tǒng)一級(jí)復(fù)用監(jiān)測(cè)器和斷言。這些從低層次復(fù)用來的監(jiān)測(cè)器和斷言在上層測(cè)試中主要覆蓋于其它模塊互動(dòng)的功能點(diǎn)。同時(shí)由于在系統(tǒng)測(cè)試中，我們會(huì)采用直接測(cè)試從實(shí)際系統(tǒng)應(yīng)用場(chǎng)景出發(fā)，寫C或者匯編代碼由系統(tǒng)中的處理器來執(zhí)行。直接測(cè)試的另外一個(gè)好處是可以為硅后測(cè)試提供可以復(fù)用的測(cè)試代碼。

在我們分析了檢查的方法之后，我們下一篇文章會(huì)給大家總覽《集成的環(huán)境》，看看常用的驗(yàn)證環(huán)境的構(gòu)成。

驗(yàn)證的策略篇之六：集成的環(huán)境

在分析完激勵(lì)的原則的檢查的方法之后，我們關(guān)于驗(yàn)證平臺(tái)（testbench）的核心要素就大致齊備了。接下來我們將進(jìn)一步分析整個(gè)驗(yàn)證集成環(huán)境要考慮的部分有哪些，通過這些分析了解這些部分之間的關(guān)系。從下面這張圖我們將驗(yàn)證集成環(huán)境分為了：

• 驗(yàn)證平臺(tái)（verification platform）

• 運(yùn)行環(huán)境（runtime environment）

• 待驗(yàn)設(shè)計(jì)（design under verification）

• 驗(yàn)證管理（verification management）

驗(yàn)證平臺(tái)

驗(yàn)證平臺(tái)是驗(yàn)證人員日常工作的對(duì)象，在建立或者復(fù)用驗(yàn)證框架時(shí)，主要從激勵(lì)分類和檢查方法兩部分考慮，這兩部分會(huì)直接影響驗(yàn)證的框架。

激勵(lì)分類

• 直接激勵(lì)：一般通過文本激勵(lì)、C代碼激勵(lì)、預(yù)先生成激勵(lì)碼等形式給入測(cè)試激勵(lì)。

• 隨機(jī)激勵(lì)：通過約束隨機(jī)給入測(cè)試激勵(lì)，這里的隨機(jī)方式不局限于SV，也包括其他隨機(jī)驗(yàn)證語言，或者腳本語言用來的隨機(jī)生成。

檢查分類

• 線上檢查（online check）：在仿真的過程中動(dòng)態(tài)比對(duì)數(shù)據(jù)，并且給出比較結(jié)果信息。

• 線下檢查（offline check）：在仿真結(jié)束之后將仿真中收集的數(shù)據(jù)進(jìn)行比對(duì)，再給出比較結(jié)果。

• 斷言檢查（assertion check）：可以通過仿真或者形式驗(yàn)證的方式利用斷言檢查設(shè)計(jì)的功能點(diǎn)。

待驗(yàn)設(shè)計(jì)

硬件設(shè)計(jì)根據(jù)功能描述的定義階段和功能劃分，可以分為兩個(gè)部分：

• HDL硬件模型：即使用HDL語言描述的硬件模型，按照硬件層次劃分可以分為RTL和網(wǎng)表。該模型的特定是與硬件設(shè)計(jì)師距離最近，也是最貼合硬件邏輯行為的模型。

• 虛擬原型（virtual prototye）：在硬件定義的早期階段，我們會(huì)引入虛擬原型來對(duì)硬件的框架和性能進(jìn)行評(píng)估。同時(shí)，在數(shù)字信號(hào)處理模塊中，需要較為復(fù)雜的算法參與，所以在硬件實(shí)施之前，我們也可以采用軟件算法模型來代替硬件的功能（不考慮時(shí)序替代）。常用的虛擬原型語言包括SystemC、C/C++、Matlab等。

在仿真過程中，我們也可以將HDL硬件模型與虛擬原型組合進(jìn)行聯(lián)合仿真，這時(shí)需要考慮虛擬原型的接口是否可以較為方便地在硬件環(huán)境中集成，以及是否對(duì)虛擬原型的接口時(shí)序有要求。

運(yùn)行環(huán)境

運(yùn)行環(huán)境的主要職責(zé)是將驗(yàn)證平臺(tái)和待驗(yàn)設(shè)計(jì)做一個(gè)融合（軟件激勵(lì)端和硬件模型端的互動(dòng)），而根據(jù)上面驗(yàn)證平臺(tái)和待驗(yàn)設(shè)計(jì)的分類，運(yùn)行環(huán)境需要考慮的因素有：

• 驗(yàn)證平臺(tái)：運(yùn)行環(huán)境需要傳入?yún)?shù)來實(shí)現(xiàn)根據(jù)測(cè)試場(chǎng)景來選擇特定測(cè)試序列、隨機(jī)種子數(shù)值、參數(shù)化驗(yàn)證環(huán)境的結(jié)構(gòu)、實(shí)例化驗(yàn)證平臺(tái)等跟所有跟通過運(yùn)行參數(shù)來控制驗(yàn)證平臺(tái)的因素。

• 待驗(yàn)?zāi)Ｐ?/strong>：除了考慮如何實(shí)現(xiàn)HDL硬件模型與虛擬原型在仿真器中協(xié)同仿真之外，還需要實(shí)現(xiàn)驗(yàn)證平臺(tái)和待驗(yàn)設(shè)計(jì)的接口對(duì)接，這包括硬件信號(hào)接口連接和內(nèi)部信號(hào)的接口連接。

• 仿真全流程建立：這包括了驗(yàn)證和設(shè)計(jì)的文件提?。╡xtraction）、文件依賴度分析（dependancy analysis）、編譯（compilation and elaboration）、仿真（simulation）、結(jié)果分析（result analysis）和遞歸測(cè)試（regression test）等。全流程的建立一般是由環(huán)境建設(shè)者（environment builder）通過腳本（script）語言來做管理的，常見的用于仿真流程建立腳本語言包括Shell、Makefile、Perl、Tcl、Python等。

驗(yàn)證管理

無論我們芯片的尺寸有多大，作為驗(yàn)證人員和驗(yàn)證經(jīng)理都需要對(duì)自己負(fù)責(zé)的模塊或者芯片做一個(gè)量化的驗(yàn)證管理，除了常見的Excel表格管理之外，我們也會(huì)通過其它驗(yàn)證管理工具來進(jìn)行管理。這些驗(yàn)證管理工具需要考慮的因素有：

• 驗(yàn)證計(jì)劃和進(jìn)度管理（verification plan and progress management）：驗(yàn)證計(jì)劃需要從抽象文字一級(jí)與量化后的測(cè)試用例、功能覆蓋率對(duì)應(yīng)，進(jìn)而給出一個(gè)可視化的驗(yàn)證進(jìn)度。

• 文件版本控制管理（file version control management）：文本版本控制在團(tuán)隊(duì)協(xié)作中幾乎是必需品，常見的工具有SVN、Git、Clearcase。

• 項(xiàng)目環(huán)境配置管理（project environment configuration management）：項(xiàng)目環(huán)境的配置文件不但包括有項(xiàng)目中使用的各種工具的版本、單元庫(kù)的版本、驗(yàn)證IP的版本，也包括驗(yàn)證環(huán)境的頂層配置，通過這些環(huán)境配置管理每一個(gè)參與到項(xiàng)目的人可以很快地實(shí)現(xiàn)環(huán)境配置，省去同步協(xié)調(diào)驗(yàn)證環(huán)境的工作。

• 缺陷率跟蹤管理（defect tracking management）：在之前提到的缺陷率曲線，需要驗(yàn)證人員和驗(yàn)證經(jīng)理保持記錄的習(xí)慣，除了可以通過缺陷率曲衡量驗(yàn)證的進(jìn)度，還需要通過記錄的缺陷來跟蹤缺陷的修復(fù)、后續(xù)驗(yàn)證的工作。

有了足夠穩(wěn)定的驗(yàn)證平臺(tái)，能夠在更早期利用不同抽象級(jí)別的待驗(yàn)?zāi)Ｐ驼归_驗(yàn)證環(huán)境的搭建和設(shè)計(jì)驗(yàn)證，通過模塊化自動(dòng)化的運(yùn)行環(huán)境實(shí)現(xiàn)環(huán)境從建立到檢查，這是一個(gè)完善的驗(yàn)證環(huán)境能夠提供給驗(yàn)證人員的。在此之上，從項(xiàng)目管理角度出發(fā)，我們也需要一個(gè)完善的工具（可能是幾個(gè)工具共同協(xié)助）幫助我們完成驗(yàn)證管理，最終可以達(dá)到驗(yàn)證的目標(biāo)。

到這里，我們的《驗(yàn)證的策略篇》就介紹完了。從下一季開始，我們將進(jìn)入《驗(yàn)證的方法篇》，將結(jié)合常用的驗(yàn)證方法、運(yùn)行環(huán)境、驗(yàn)證管理等驗(yàn)證構(gòu)成的要素來談一談貫穿驗(yàn)證周期內(nèi)的工具。

（完）

來源：路科驗(yàn)證(微信訂閱號(hào)ROCKER-IC) 及 EETOP BLOG