如何在EDA驗證給找出大部分BUG

0 緒論

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

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

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

1 ESL建模驗證

1.1 ESL簡介

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

1.2 建模步驟

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

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

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

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

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

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

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

2 EDA驗證

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

2.1 驗證方法

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

從驗證的手段來講，主要有三種

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

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

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

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

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

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

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

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

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

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

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

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

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

-語句覆蓋率。每一句RTL是不是被運行過。

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

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

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

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

2.2 驗證平臺

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

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

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

·面向?qū)ο螅鱾€組件之間可以并行開發(fā)，耦合比較小

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

2.1.1 UVM的整體框架

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

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

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

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

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

2.2.2 UVM的主要機制

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

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

factory采用下面的方式注冊。

使用的時候就比較簡單了。

機制2：Config機制。

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

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

?

?

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

?

?

機制3：TLM機制。

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

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

機制4：Sequencer機制

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

2.3 驗證階段

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

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

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

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

UT劃分比較清楚，IT和ST劃分其實沒那么清楚，所以有個概念即可，驗證實分層做的。

3 硬件輔助驗證

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

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

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

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

4 總結(jié)

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

編輯：黃飛

?