在工作日里，如果你問驗證工程師在干嘛，多半時間他/她會告訴你在Debug。換句話說，一般在驗證周期內(nèi)，工程師有超過一半的時間都消耗在了功能調(diào)試上，盡管這里面包含了驗證工程師跟自己“作對”的時間，即驗證環(huán)境或者測試用例本身存在bug。所以，調(diào)試這項工作還是很重要的！

調(diào)試這項工作除了要求工程師對設(shè)計規(guī)范（Specification）、DUT（Design Under Test）、測試環(huán)境（testbench）結(jié)構(gòu)和用例（test case）的測試意圖有一定的了解，掌握必要的工具、方法和技巧也十分重要，它能夠幫助工程師獲得更多有效的信息，加速問題定位，提高工作效率。

方法4：可視化調(diào)試

可視化調(diào)試主要分為Post-process和Interactive這兩種模式。可視化調(diào)試工具是工程師在定位代碼問題時的有力工具，也是現(xiàn)在驗證工程師主流的調(diào)試工具。工具的使用一般可以參考官方的用戶手冊（User Guide），也能夠在官網(wǎng)上找到相應(yīng)的培訓(xùn)鏈接和視頻。

常用的可視化調(diào)試工具有Synopsys家的Verdi，Siemens家的Visualizer，還有Cadence家的SimVision。對于個人用戶來說，可能沒有辦法去實操體驗，但通常所在公司會購買至少一家的License。三家公司的工具的操作流程和基礎(chǔ)調(diào)試功能都差不多，然后又分別有自己調(diào)試的獨特功能。

先介紹下后處理調(diào)試模式（post-process，即在仿真結(jié)束之后再去可視化和處理仿真結(jié)果，有些地方會叫做PPE，post-processing environment）的使用，因為這種方式在實際工作中用的比較多。在使用可視化調(diào)試工具之前，通常需要將testbench和RTL編譯到同一個數(shù)據(jù)庫中，該數(shù)據(jù)庫包含了文件信息、RTL例化層次信息、信號連接關(guān)系等等，以供調(diào)試工具的追蹤和分析。

如果使用Verdi工具，需要使用VCS在編譯（Compilation=Analysis+Elaboration）的時候，通過加參數(shù)-kdb -lca來生成KDB庫（Knowledge Database），其中l(wèi)ca（Limited Customer Availability Features）參數(shù)是為了指定工具特性。KDB數(shù)據(jù)庫格式是Verdi專用的格式，所以KDB庫有時候也可以叫Verdi庫。打開verdi的時候使用命令verdi加參數(shù)-elab來選擇該KDB庫。

如果使用Visualizer工具，需要使用Questa/ModelSim在對設(shè)計完成編譯（vlog/vcom）之后，使用vopt命令加參數(shù)-debug -designfile design.bin來生成.bin文件，同樣該文件格式是Visualizer專用的。打開Visualizer的時候使用命令visualizer加參數(shù)-designfile來選擇該bin文件，使用參數(shù)-wavefile來選擇db波形文件。

如果使用SimVision工具，需要在仿真階段使用NC仿真器或者XCelium仿真器（具有更高的仿真性能，比如支持多核等）將設(shè)計和波形都導(dǎo)出成shm格式。在仿真結(jié)束之后，你可以看到名為example.shm的目錄，該目錄下會有兩個文件：.dsn文件和.trn文件，前者包含的是設(shè)計的信息（類似于我們上面說的數(shù)據(jù)庫），后者包含的是波形信息。打開SimVision的時候使用命令simvision直接加example.shm來打開待調(diào)試的數(shù)據(jù)庫。

再看看交互模式（interactive mode），交互模式相對于后處理模式增加了仿真控制的功能，即可以設(shè)置仿真斷點、控制仿真的暫停、運行和重啟等，并實時地觀察到信號的行為。交互模式下，上述EDA工具的界面上會多出來一些調(diào)試控件。不過這種模式的仿真運行速度比較慢，且在分發(fā)和重現(xiàn)代碼行為上不是很友好，所以在實際工作中也用的比較少，除非遇到非常棘手但卻摸不著頭腦的問題。以上提到的幾家工具都支持交互模式調(diào)試，操作流程也都差不多，并且跟后處理模式一樣也需要先編譯出來一個數(shù)據(jù)庫。

如果使用Synopsys家的工具，在設(shè)置完必要的環(huán)境變量之后，比如VCS_HOME和VERDI_HOME，需要使用VCS命令vcs -kdb -lca -debug_access+all 編譯出KDB庫和simv可執(zhí)行的仿真文件，然后在執(zhí)行simv的時候加上參數(shù)-verdi就可以打開交互模式下的Verdi了，這個時候調(diào)試器和仿真器是關(guān)聯(lián)起來的。

如果使用Siemens家的工具，同樣在設(shè)置完必要的環(huán)境變量并使用命令vopt編譯出design.bin文件之后，可以使用命令vsim -visualizer=design.bin -qwavedb=+signal+class -f 打開交互模式下的Visualizer，便可以在調(diào)試工具界面去控制仿真器。

如果使用Cadence家的工具，那就相對復(fù)雜一點，因為Cadence前前后后有幾個仿真器，比如verilog、ncsim、irun，并且進交互調(diào)試模式的方法也比較多樣，但大致可以分兩種：一種是可以通過參數(shù)-gui直接開啟帶SimVision的仿真器，另一種方式是單獨啟動SimVision，使用參數(shù)-connect host/pid連接到運行在本地或者遠端的仿真上。

以上命令只是展示大概的使用過程，實際應(yīng)以對應(yīng)版本的用戶手冊為準哈。當(dāng)你打開可視化調(diào)試工具調(diào)試界面之后，有這么幾種常用的調(diào)試功能：

通過Hierarchy等窗口瀏覽源代碼的例化層次結(jié)構(gòu)，類繼承關(guān)系等；

通過查找Driver和Load來定位信號的傳播通路（這個是用的最多的）；

通過Filter來分類查看當(dāng)前文件包含的輸入輸出信號、參數(shù)、變量等；

通過查找來定位某一個module例化出來的所有模塊；

原理圖和狀態(tài)機跳轉(zhuǎn)圖可以有限地幫助你理解代碼行為；

配合波形文件查看各種信號隨時間變化的行為；

調(diào)試工具的功能還有很多，具體可以查看各個工具的官方介紹和培訓(xùn)視頻。

方法5：SVA斷言在調(diào)試中的應(yīng)用

概述：SystemVerilog Assertion（斷言）主要用于驗證設(shè)計的行為，并且可以提供功能覆蓋率信息。Assertion可以應(yīng)用于兩種不同的驗證方法中，一種是在動態(tài)仿真中去動態(tài)地檢查各個既定屬性（property）是否滿足，另一種測試用于Formal驗證工具去證明設(shè)計是否符合規(guī)范。

作用：如果你剛接觸，可以把斷言簡單理解成checker或者monitor，它指的是在設(shè)計中嵌入一些工程師根據(jù)待測特性自行定義的一些屬性，仿真的時候仿真工具會去判斷這些屬性是否成立，以此來判斷某個特性是否實現(xiàn)正確。SVA在本文中作為調(diào)試的方法來介紹，就是因為斷言可以幫助我們監(jiān)測屬性，為我們報出來哪些時刻行為正常、哪些時刻行為異常，且這些行為可以是有時序的！

分類：在SystemVerilog中，斷言大致可以分為兩類：立即斷言（immediate assertion）和并發(fā)斷言（concurrent assertion）。立即斷言是基于仿真事件（simulation event）的，當(dāng)它被執(zhí)行到的時候就會立即對多定義的屬性做出判斷并給出結(jié)果；而并發(fā)斷言是基于時鐘的，斷言的評估（evaluate）發(fā)生在時鐘邊沿，這也使得并發(fā)斷言具有監(jiān)測的能力，這也是下面要主要介紹的。

結(jié)構(gòu)：斷言的具體實現(xiàn)依賴于更基礎(chǔ)的元素，比如sequence和property。Sequence是最底層的元素，它可以復(fù)用和嵌套。Sequence可以用來定義簡單的布爾表達式，也可以用來描述多周期的時序行為。Property則可以實現(xiàn)跟sequence一樣的內(nèi)容，也可以通過組合不同的sequence來構(gòu)造更加復(fù)雜的時序行為。為了規(guī)范化，建議將嵌入的時鐘信號@(posedge clk)放在property這一層，而將sequence跟時鐘獨立開來，方便基礎(chǔ)sequence的復(fù)用。

調(diào)度：SystemVerilog的仿真基于事件驅(qū)動模型，事件的調(diào)度機制在SV語言標準中有明確說明。該調(diào)度機制將每個仿真時刻（time slot）再劃分成多個region，如下圖所示，每個region都有自己明確的操作。仿真調(diào)度算法的確定，可以使得仿真環(huán)境跟DUT交互時顯示出同步的效果。其中跟SVA相關(guān)的region有Preponed、Observed和Reactive。在Preponed中，SVA會對有關(guān)聯(lián)的變量完成采樣；在Observed中，多有的property完成評估，即判斷斷言描述是否成立；在Reactive中，執(zhí)行斷言評估結(jié)果需要采取的對應(yīng)的操作。

應(yīng)用：斷言的應(yīng)用主要可以分成四個步驟：1、構(gòu)造基礎(chǔ)布爾表達式；2、構(gòu)造sequence序列；3、構(gòu)造斷言屬性property；4、將屬性代碼插入或綁定（bind）到待測模塊中。SVA提供了一些好用又強大的功能：判斷信號邊沿和狀態(tài)、添加延時來構(gòu)造信號時序行為、支持構(gòu)造不定周期的時序窗口、判斷過去的信號狀態(tài)、支持斷言的邏輯運算等等，本文篇幅顯然是不夠的了。

方法6：軟件調(diào)試方法的借鑒和應(yīng)用

這一節(jié)的內(nèi)容更像是討論，有哪些軟件開發(fā)中用到的調(diào)試方法，或者問題定位策略是可以借鑒過來應(yīng)用到芯片驗證中的。

有個前提需要明確的是，硬件仿真始終是基于事件驅(qū)動的程序執(zhí)行過程，盡管仿真調(diào)度機制簡潔明了，但往往待測設(shè)計規(guī)模龐大（具體表現(xiàn)為硬件行為具備并行性質(zhì)，一個時鐘信號的翻轉(zhuǎn)事件關(guān)聯(lián)著成千上萬的信號動作），所以硬件仿真的運行速度會非常的慢，這是跟單純軟件程序的一個顯著區(qū)別。

運行速度上的差異帶來了調(diào)試方法上的一些不同。軟件調(diào)試中交互式的操作非常多，比如解釋執(zhí)行的腳本（比如Python）不需要編譯就可以馬上得到執(zhí)行的結(jié)果，又比如基于斷點的調(diào)試可以非常容易地檢查變量值和堆棧跟蹤。反觀硬件調(diào)試，工程師很難快速地知道在哪里設(shè)置斷點，往往需要反復(fù)的嘗試，這會浪費掉很多時間。因此硬件的調(diào)試更多依賴于信息的導(dǎo)出，其形式通常是仿真日志和波形文件。

如何提高硬件調(diào)試的交互性可能是軟件調(diào)試帶來的啟示，有這么一些不成熟的想法，比如是否可以增加調(diào)試信息（代碼、波形和仿真日志）之間的關(guān)聯(lián)，實現(xiàn)自動化跳轉(zhuǎn)；是否可以增加工具對代碼的理解或者記錄調(diào)試過程來進行自動化分析；是否可以在增量編譯的概念上實現(xiàn)增量仿真；等等等等。

審核編輯：劉清