0 緒論

驗(yàn)證，顧名思義，看看做出來的東西對(duì)不對(duì)，通知以及說服設(shè)計(jì)人員，把BUG改掉。

其實(shí)看一家芯片公司靠不靠譜可以從他們的芯片驗(yàn)證是不是專業(yè)來判斷。部分人對(duì)芯片的驗(yàn)證映像還停留在讓設(shè)計(jì)人員寫幾個(gè)testbench自己測一下功能的階段，實(shí)際上芯片驗(yàn)證是一個(gè)非常專業(yè)化、體系化、有自己獨(dú)特技術(shù)棧的工作。芯片的驗(yàn)證和軟件的驗(yàn)證最大的一個(gè)區(qū)別我想應(yīng)該是責(zé)任的區(qū)別，軟件驗(yàn)證放走一個(gè)BUG大不了下個(gè)版本修改好，芯片驗(yàn)證如果放走一個(gè)BUG一旦流片可能就沒有補(bǔ)救的機(jī)會(huì)了，屬實(shí)是責(zé)任重于泰山，壓力山大。

驗(yàn)證的主要內(nèi)容我們按階段分ESL, EDA, 硬件輔助驗(yàn)證來講。

1 ESL建模驗(yàn)證

1.1 ESL簡介

ESL是electronic system-level languages的簡稱。廣義上來講，ESL建模也算是驗(yàn)證工作的一部分。主要是用C模型來驗(yàn)證芯片的行為，以達(dá)到快速debug的目的。ESL一般只在超大的芯片公司有獨(dú)立的團(tuán)隊(duì)，大部分公司由設(shè)計(jì)或者驗(yàn)證人員來完成，或者干脆不做。ESL驗(yàn)證一般用system C設(shè)計(jì)ESL平臺(tái)。system C可以理解為一個(gè)C++類庫和一堆宏，方便模擬硬件的并行操作的。ESL建模從芯片設(shè)計(jì)的很早期就可以開展。此處我們簡單講講幾個(gè)步驟。

1.2 建模步驟

建模大致分為5種model，由上到下逐步細(xì)化即可，按需實(shí)現(xiàn)即可，其實(shí)也不需要全部實(shí)現(xiàn)。

Spec Model如上圖，最先設(shè)計(jì)的是spec model, 這個(gè)步驟主要就是搞清楚算法鏈路是不是能實(shí)現(xiàn)功能。其實(shí)和算法鏈路區(qū)別不大。功能塊之間的交流直接用全局變量就搞定了，只能驗(yàn)證一下功能，不能驗(yàn)證芯片行為。

Architecture Model在spec model的基礎(chǔ)上繼續(xù)細(xì)化。根據(jù)設(shè)計(jì)人員的架構(gòu)設(shè)計(jì)講ESL也按架構(gòu)分開。模塊之間的數(shù)據(jù)交換也用variable channels （system c提供的類庫，可以很好的模擬interface行為）。這個(gè)步驟可以驗(yàn)證大的模塊之間的接口不會(huì)出錯(cuò)。

Transaction Model主要是將BUS連在了一起。這些模塊之間不再是兩兩互聯(lián)，而是根據(jù)架構(gòu)設(shè)計(jì)通過BUS Arbiter連接。需要注意的是這個(gè)地方Arbiter還是功能級(jí)的實(shí)現(xiàn)。這個(gè)步驟可以驗(yàn)證地址空間是不是對(duì)的，互聯(lián)是不是通的等等。

Behavior Model主要是對(duì)總線進(jìn)一步細(xì)化，模擬真實(shí)的總線行為。一般ESL驗(yàn)證到這個(gè)步驟就可以停了，后續(xù)交個(gè)EDA驗(yàn)證去搞定。

Cycle-Accuracy Model最后一個(gè)模型，cycle級(jí)精確的模型。進(jìn)一步細(xì)化behavior model，將每個(gè)信號(hào)給出時(shí)序就能出cycle accuacy 精確的model?？梢灾餭ycle比對(duì)行為。但我覺得這個(gè)模型太細(xì)致了，開發(fā)量也不小，沒必要。直接開發(fā)到behavior model或者transacation model即可，cycle accuracy model交給EDA驗(yàn)證。

ESL驗(yàn)證的一個(gè)好處是可以逐步細(xì)化你的驗(yàn)證平臺(tái)，在比較早的時(shí)候就發(fā)現(xiàn)問題，不要等代碼都寫完了以后再發(fā)現(xiàn)問題。建議做到architecture model或者transaction model, 可以很好的利用C++快捷的特點(diǎn)加速芯片收斂。

2 EDA驗(yàn)證

接下來我們就到了EDA驗(yàn)證階段。這個(gè)階段是驗(yàn)證的重中之重。ESL模型總歸是建模，EDA驗(yàn)證面向的是真正用于綜合的RTL代碼。為了讓大家對(duì)測試有個(gè)基本認(rèn)識(shí)，我們先講方法與平臺(tái)，然后講講驗(yàn)證的幾個(gè)重要階段。主要內(nèi)容如下。

2.1 驗(yàn)證方法

廣義的驗(yàn)證方法有很多，比如上一章講到過的Spyglass也可以叫做一種靜態(tài)驗(yàn)證。此處我們講講EDA驗(yàn)證中狹義的方法。主要包括三方面的內(nèi)容，驗(yàn)證的手段，驗(yàn)證的透明度和如何評(píng)估驗(yàn)證的進(jìn)度。

從驗(yàn)證的手段來講，主要有三種

·斷言測試, assertion check。這個(gè)主要是對(duì)模塊的輸出或者中間變量做一定的預(yù)設(shè)，比如狀態(tài)機(jī)就該如何跳，輸出就應(yīng)該是符合標(biāo)準(zhǔn)協(xié)議的。一旦不符合立刻就能發(fā)現(xiàn)錯(cuò)誤。這個(gè)部分適用于測試的最早期，能快速的發(fā)現(xiàn)問題。寫C++的時(shí)候這個(gè)其實(shí)由設(shè)計(jì)人員順手就寫了，隨手就一個(gè)斷言，保證自己的程序和預(yù)期一致。寫RTL的話斷言一般還是由測試人員寫在測試的平臺(tái)了的，不會(huì)直接插入到設(shè)計(jì)代碼里（可以插，但是不建議）。

·定向測試，directed test。測試的輸入都是提前定好的。驗(yàn)證人員通過設(shè)計(jì)需求分解的測試點(diǎn)，或者叫測試用例。定向測試主要運(yùn)用在測試的早期，用來測試基本功能。

·隨機(jī)測試，random test。輸入的序列是隨機(jī)的，然后測試輸出的結(jié)果是不是對(duì)的。隨機(jī)測試一般在定向測試結(jié)束以后開始的。一般來講隨機(jī)用例會(huì)監(jiān)測一下覆蓋率，覆蓋率達(dá)到要求就可以停下來了。此處也有一種每日回歸的提法，驗(yàn)證人員每天晚上跑上測試（包含了隨機(jī)和定向），早上發(fā)現(xiàn)BUG以后報(bào)告設(shè)計(jì)人員，設(shè)計(jì)人員修改BUG，下班之前提交一個(gè)版本讓驗(yàn)證再跑一晚上。如果不在意電費(fèi)的話當(dāng)然是隨機(jī)跑的越多，發(fā)現(xiàn)BUG的概率越大。但是每日回歸對(duì)設(shè)計(jì)人員和測試人員壓力都比較大。work life balance是別想了。

從透明度上來講，主要有三種透明度。

·白盒測試。白盒測試相當(dāng)于設(shè)計(jì)人員了解設(shè)計(jì)細(xì)節(jié)。上面講的斷言測試一般就是白盒的。白盒測試的優(yōu)點(diǎn)是對(duì)問題的定位其實(shí)是比較快的，適用于測試的初步階段。但白盒測試也有自己的一些問題。第一個(gè)問題是驗(yàn)證可能和設(shè)計(jì)錯(cuò)成一樣的。驗(yàn)證人員由于知道全部的設(shè)計(jì)細(xì)節(jié)，自然會(huì)收到設(shè)計(jì)思路的影響，從而讓驗(yàn)證錯(cuò)成一樣的問題。第二個(gè)問題白盒測試驗(yàn)證環(huán)境高度依賴于設(shè)計(jì)，不同版本之間其實(shí)很難復(fù)用。

·灰盒測試。介于黑盒測試和白盒測試之間的測試方法。主要用在集成測試?yán)锩妗２恢雷幽K的具體行為，但知道互聯(lián)的細(xì)節(jié)。其實(shí)我覺得更偏向白盒測試，只是白盒子里面的子模塊是黑的而已。

·黑盒測試。黑盒測試驗(yàn)證人員應(yīng)當(dāng)完全不了解內(nèi)部實(shí)現(xiàn)。只關(guān)心輸入輸出。測試人員給若干輸入，看看輸出是不是都對(duì)。黑盒測試的優(yōu)點(diǎn)是更加貼近使用場景，容易發(fā)現(xiàn)比較重要的BUG。但也有問題，一旦發(fā)現(xiàn)了BUG定位是比較麻煩的，而且黑盒測試的輸入不一定能覆蓋各種情況，有可能有漏測的情況。

實(shí)際上，為了最好的驗(yàn)證效果，驗(yàn)證在不同階段使用的手段和透明度其實(shí)是不一樣的。

上面講的都是驗(yàn)證的手段，此處還有一個(gè)主要問題要說一下，怎么確認(rèn)驗(yàn)證要停下來了？畢竟除非你能把所有輸入情況都試一遍，否則沒辦法打包票驗(yàn)證就一定完成了。所以我們需要一些指標(biāo)來指導(dǎo)我們驗(yàn)證是不是充分了。

·回歸測試通過率。測試中我們會(huì)把典型場景的輸入作為一個(gè)用例集，每次修改源代碼都會(huì)回歸一下。通過樣例數(shù)/總樣例數(shù)=回歸測試率，回歸測試率顯然是要求100%的，如果有樣例都通不過測試，說明代碼有功能問題，不可能拿去流片。

·功能覆蓋率。功能覆蓋率主要指的是各項(xiàng)功能是不是一一驗(yàn)證過了。驗(yàn)證人員逐一驗(yàn)證設(shè)計(jì)需求。功能覆蓋率也要求100%。否則相當(dāng)于有功能沒有經(jīng)過驗(yàn)證就直接拿去流片了。

·斷言覆蓋率。斷言是不是都被執(zhí)行過。不一定要達(dá)到100%，有些斷言可能確實(shí)也沒什么用。由于斷言本來就是驗(yàn)證人員加的，如果確認(rèn)就是執(zhí)行不到的斷言刪掉即可。

·代碼覆蓋率，代碼覆蓋率是軟件測試中經(jīng)常用到的手段。芯片測試里也會(huì)用。這些覆蓋率不要求100%，因?yàn)橛行┣闆r確實(shí)靠構(gòu)造用例很難構(gòu)造出來。一般應(yīng)該會(huì)要求95%以上即可，（有段時(shí)間在互聯(lián)網(wǎng)公司寫C++的時(shí)候覆蓋率要求貌似是99%以上，RTL代碼要求理論上不需要這么嚴(yán)格）。里面又細(xì)分為

-語句覆蓋率。每一句RTL是不是被運(yùn)行過。

-條件覆蓋率。每個(gè)條件是不是都執(zhí)行過成立和不成立。特別是或的情況。if (cond a || cond b)這種語句，cond a和cond b是不是都驗(yàn)過了。

-決策覆蓋率。指的是if和else塊是不是都運(yùn)行過了。（你可以想想決策覆蓋率和條件覆蓋率有什么區(qū)別）。

-跳轉(zhuǎn)覆蓋率。各個(gè)信號(hào)是不是都從0到1跳變過。

·缺陷曲線。評(píng)估驗(yàn)證是否完全的一個(gè)重要工具是缺陷曲線。缺陷曲線Defect curve長下面這樣。一般來講，測試活動(dòng)全面鋪開以后每天都會(huì)統(tǒng)計(jì)測試出的BUG。可以根據(jù)曲線的斜率變大還是變小確定測試活動(dòng)是不是在收斂。最后一定要曲線收斂。當(dāng)然，即使曲線收斂了也不能保證100%就沒問題。曲線收斂了有兩種情況，一種是沒有BUG了，一種是測試質(zhì)量不過關(guān)，壓根就發(fā)現(xiàn)不了BUG。比如曲線看著收斂了，但是還是發(fā)現(xiàn)了最基礎(chǔ)的BUG，這種情況可能就是偽收斂的，需要重新檢查缺陷質(zhì)量。

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

上面講了一堆方法上的東西，我們還缺一個(gè)東西，如何把方法實(shí)現(xiàn)。EDA驗(yàn)證我們用的語言一般是System Verilog，為了提高重用性，大量使用了面向?qū)ο蟮脑O(shè)計(jì)方式。還是那句話，沒必要重復(fù)造輪子。目前業(yè)界最常用的一套輪子是UVM (The Universal Verification Methodology)。雖然名字叫方法學(xué)，其實(shí)就是一套用system verilog寫的庫以及基于這個(gè)庫的一套驗(yàn)證框架，方便驗(yàn)證的時(shí)候使用。

UVM主要的優(yōu)勢：

·提供可重用的的組件以及可分層的組件

·面向?qū)ο?，各個(gè)組件之間可以并行開發(fā)，耦合比較小

·各個(gè)組件通過configuration可以很靈活的使用

2.1.1 UVM的整體框架

UVM的整體框架見下面的圖，UVM內(nèi)部的東西非常多，此處只是介紹個(gè)大概。其實(shí)大部分的驗(yàn)證框架都是這個(gè)圖。DUT是我們要測的模塊，用TX ENV產(chǎn)生輸入激勵(lì)，從RX接收到DUT的計(jì)算結(jié)果。在Scordboard比對(duì)一下結(jié)果。判斷用例是不是執(zhí)行正確了。

需要注意的是這個(gè)圖可能會(huì)產(chǎn)生部分誤解。TX Agent和RX Agent都復(fù)用了agent, 但實(shí)際上在最簡的測試系統(tǒng)中，RX中的sequence, driver可能沒有， TX Agent的Monitor可能也沒用。實(shí)際上變成下面的一個(gè)形式。

其中sequencer是產(chǎn)生抽象序列的類，driver是真正的生成pin信號(hào)控制dut, monitor接受信號(hào)。scoreboard比對(duì)信息。reference model (RM) 通過in_agent給出的激勵(lì)，通過算法鏈路生成結(jié)果，最后和dut的結(jié)果比較。

和其他開源框架比如LLVM一樣，UVM運(yùn)行也是分階段的。

主要就是上面若干階段。其中build, connect, start_f_simulation其實(shí)需要我們干預(yù)的比較少，我們主要是要重載若干run里面的函數(shù)。run里面又分為reset, configure, main, shutdown四個(gè)階段。后面有check, report, final階段，都好理解。

2.2.2 UVM的主要機(jī)制

UVM區(qū)別于手?jǐn)]的System Verilog驗(yàn)證環(huán)境主要是幾個(gè)機(jī)制起作用。所以對(duì)幾個(gè)機(jī)制也要有一定了解。UVM的新機(jī)制還是比較多的，此處我們只介紹幾個(gè)最基本的。

機(jī)制1：Factory機(jī)制。這個(gè)和我們軟件工程里面的函數(shù)工廠或者對(duì)象工廠其實(shí)是一個(gè)意思，UVM會(huì)通過uvm_components_utils的機(jī)制把我們寫的組件注冊(cè)到一張表中，我們需要使用的時(shí)候直接使用名字字符串為索引創(chuàng)建出相應(yīng)的對(duì)象。(emmm, 此處突然想賣個(gè)關(guān)子，大家可以想一下UVM為什么采用了Factory機(jī)制獲取對(duì)象，而不是直接采用類的構(gòu)造函數(shù)獲取對(duì)象^^)

factory采用下面的方式注冊(cè)。

使用的時(shí)候就比較簡單了。

機(jī)制2：Config機(jī)制。

Config機(jī)制主要是為了改變testbench的配置項(xiàng)，生成各種不同的激勵(lì)。UVM區(qū)別于SV的另一個(gè)重要的機(jī)制是config機(jī)制。這個(gè)config從頂層一直往下傳導(dǎo)，各處都能訪問到，類似一個(gè)config-hub。對(duì)于硬件設(shè)計(jì)和測試來講這種方式確實(shí)還是可以省去很多麻煩。后面chisel的config設(shè)計(jì)其實(shí)也和這種config是同一個(gè)思路，只是進(jìn)行了擴(kuò)展。

用set或者get配置、獲取參數(shù)。

?

?

static function bit get(
       uvm_component   cntxt,
       string   inst_name,
       string   field_name,
     inout   T   value
)

?

?

機(jī)制3：TLM機(jī)制。

這個(gè)機(jī)制主要是為了專門做一個(gè)模塊，在不同模塊之間傳數(shù)據(jù)。比如monitor向scorebord傳數(shù)據(jù)。簡單理解為port分裝。

PORT又分為port和export。其中PORT是主動(dòng)端，寫入數(shù)據(jù)用PUT, 讀出數(shù)據(jù)用GET。這種交互主要是為了數(shù)據(jù)隔離，避免意外的數(shù)據(jù)改動(dòng)。

機(jī)制4：Sequencer機(jī)制

看這個(gè)圖，driver是真正驅(qū)動(dòng)DUT的模塊，而給DUT提供數(shù)據(jù)的是Sequencer。sequencer相當(dāng)于一個(gè)數(shù)據(jù)隊(duì)列，存儲(chǔ)著一包包的數(shù)據(jù)，按包發(fā)給driver, 然后driver再解析包，解析成具體的驅(qū)動(dòng)信號(hào)。之所以加入sequencer的一個(gè)很大的原因是隔離DUT業(yè)務(wù)。假如DUT的端口變化了，我們只需要改動(dòng)driver, 不需要改動(dòng)其他東西。

2.3 驗(yàn)證階段

上面講了驗(yàn)證方法和驗(yàn)證平臺(tái)，此處我們開始講講驗(yàn)證的階段流程。由于現(xiàn)代芯片越來越復(fù)雜，驗(yàn)證一般要分層次。常見的測試和軟件測試活動(dòng)其實(shí)類似，分為UT, IT,ST。比如我們簡單畫一個(gè)AI SOC。

·UT（Unit Test）測試：測試功能模塊是不是正確的，比如CNN CORE, RISC-V CORE就是一個(gè)UT。UT層面基本上可以白盒或者灰盒測試。主要測試單元模塊的正確性，包括內(nèi)部狀態(tài)機(jī)是不是正確的，數(shù)據(jù)處理是不是正確的等等。由于這個(gè)層面的測試和設(shè)計(jì)功能實(shí)在是耦合有點(diǎn)緊密，可以由設(shè)計(jì)人員自己完成UT測試，當(dāng)讓也可以測試人員來搞。

·IT(Integrated Test)測試：測試子系統(tǒng)。比如AP子系統(tǒng)（Application Processor), 里面的core， cache, DMA是不是聯(lián)合起來能工作正常。理論上來講IT測試出的問題應(yīng)該主要在各個(gè)UT之間的交互上，但實(shí)際上也可能發(fā)現(xiàn)UT內(nèi)部的問題。IT測試一般是灰盒和黑盒的。主要有測試人員來做。

·ST(Sysem Test)測試：這一個(gè)層面的測試主要是芯片整體層面。整個(gè)芯片的子系統(tǒng)是不是能很好的配合運(yùn)行起來主要靠ST來保證。ST測試的重點(diǎn)是真實(shí)場景下的用例?；径际嵌ㄏ驕y試，最好把實(shí)際芯片用的各種情況都模擬一遍，以防出錯(cuò)。

UT劃分比較清楚，IT和ST劃分其實(shí)沒那么清楚，所以有個(gè)概念即可，驗(yàn)證實(shí)分層做的。

3 硬件輔助驗(yàn)證

EDA驗(yàn)證由于軟件其實(shí)對(duì)于跑一些大型測試是比較慢的。歸根結(jié)底EDA用CPU來算，CPU就不適合算這種高并發(fā)的計(jì)算任務(wù)。所以在驗(yàn)證的最后階段，往往還有用硬件輔助驗(yàn)證查漏補(bǔ)缺。

硬件輔助驗(yàn)證大約就兩種，第一種是FPGA搭原型。這個(gè)容易理解，將你寫的芯片先燒到FPGA上看看能不能跑起來，這種驗(yàn)證可以驗(yàn)出一些芯片接口的問題，但也有缺點(diǎn)，一來，芯片里面一些東西是沒辦法綜合到FPGA上的，所以只能寫一個(gè)假的模塊用來驗(yàn)證，二來，隨著芯片規(guī)模的變大，F(xiàn)PGA不一定放得下芯片，可能需要并聯(lián)兩塊甚至多個(gè)FPGA，搭建這樣一個(gè)平臺(tái)也不容易。FPGA一般用xilinx家的ultrascale。這個(gè)東西聽說國內(nèi)不一定買得到了。

第二種是emulator。這種東西可以理解為一個(gè)仿真波形的加速器。Cadence Palladium, Synopsys ZeBu, Mentor Veloce都屬于這類emulator。賊貴。Mentor Veloce長這樣的, 放在數(shù)據(jù)中心。用戶租用軟件就可以。

不得不說，這三家EDA廠商為了驗(yàn)證芯片真的是什么招都想出來了。

4 總結(jié)

驗(yàn)證部分的內(nèi)容到此就介紹完了，也只是個(gè)框架，實(shí)際上遠(yuǎn)不止這些內(nèi)容。驗(yàn)證在芯片里屬于一個(gè)系統(tǒng)工程，主要解決的是如何用最小的代價(jià)讓芯片出錯(cuò)概率最小的問題。此處主要講的是前端驗(yàn)證，后續(xù)做完版圖還會(huì)后仿真一下，后面再提。大部分BUG應(yīng)當(dāng)都能在EDA驗(yàn)證給找出來。

編輯：黃飛

?