我對驗證的一些理解

1、Q：驗證的目的？A：發(fā)現(xiàn)Bug,發(fā)現(xiàn)所有的Bug，或者證明沒有Bug （轉自夏晶的帖子）Q：對驗證工程師的要求？Hacker mentality， Organized testing，Tool automation。如何做更多的testcase.如何覆蓋更多的測試點、如何充分的利用服務器、如何盡可能最大 化的自動比對強調一下：“注重細節(jié)”是驗證工程師一個非常非常好的工作習慣。Q：語言、方法學有多重要？A：我的觀點是：這兩個都不重要。做事情的是驗證工程師，來源是Spec,所以Testplan （全 覆蓋testplan）最重要。重要的是驗證的意識，愿不愿意去實現(xiàn)H-O-T，即使一開始做的“土”

2、一些也沒關系。比如tb里經常要做的“自動比對功能”：1）維護queue，然后foreach的比 較 2）利用 file-operation （fopenfreadfwritefscanf）來做文件比對3）直接$system（diff a b c） 以后看c文件大小。上述三種方法都可以（雖然2）會導致比較多的文件IO，硬盤讀寫會影 響仿真速度，3）不能做實時的比對。不必拘泥于方法，關鍵是有這個意識。Q： EDA行業(yè)對驗證的支持？A：個人感覺雖然（動態(tài)）驗證這些年在理論方面的突破不大（靜態(tài)驗證一直是熱點），但是EDA 行業(yè)一直都很重視，實現(xiàn)類的工具主要是在做算法優(yōu)化，這些年突破不大。但是驗證方向上

3、 的點工具一直在不停的出（雖然最終可能也沒有幾個好使的工具），但是說明EDA行業(yè)一直 在致力于尋求在驗證上的突破。而且由于現(xiàn)在做SoC的太多，IP又太多，大家都是越來越重 視驗證，很多上規(guī)模的公司里驗證人員較設計人員多不少。個人覺得這可能也是EDA重視 驗證的一個原因（用牛工具替代掉一些人LL）。Q：如何跟蹤缺陷？A：可以考慮bug-zillar這類的工具-自動跟蹤問題。Q：作業(yè)提交系統(tǒng)（lsf或grid-engine）A：充分和合理的利用計算資源。Q：環(huán)境變量的管理？A：個人推薦使用Module工具。很多公司都是用這個免費的工具Q： Testbench用到的編程語言？A：我覺得tb里syst

4、emverilog和verilog是可以互相替換（當然了，systemverilog特有的內容 用verilog來實現(xiàn)會很復雜），所以推薦tb基于systemverilog來搭建，一些仿真模型可以用 verilogo C除了 Cmodel以外，firmware也會用C和匯編寫?；旧衔易鲞^的項目里用到的語言：腳本：perl、makefile. shell （perl用的很多，其他用的很少）Tb （包括vmm的組件）：基本是systemverilog仿真模型：systemverilog和verilog混著用Cmodel： C 或 C+Firmware :匯編和 CQ：驗證工程師需要掌握的基本技術

5、？A：分享一份我做的基本培訓內容安排，供參考Perl，Makefile，AMBA 介紹，SVTB.pdf ，sva,幾種用到的編程語言的 File operation ，Low-power， C-pointer， Cshell-AWK+SED， 體系結構相關的一些 內容，SV-1Day training ， VMM_source_code ,Arm的嵌入式編程的基本概念 。：自動化必須嗎？A：不是必須的，但是應該盡量去實現(xiàn)自動化?？傊嵌嘧寵C器跑。如果人均License太少 的話，要盡量做到白天debug、晚上讓機器跑。“比對”這種事情太機械了，所以盡量讓機 器做，做這種事情機器的效率比人高太

6、多。把精力放在構造testcase、testbench、coverage 以及debug和分析上。Q： Testplan 如何做？A：形式不重要，xls可以、word也可以、txt的也可以。但是來源于Spec！ testplan里除了 要羅列 function-test-piont，還應該有 error-injection 和 random-test-point 以及 cover-point 和 assertion o需要和各個team仔細逐條review testplan，有些針對具體實現(xiàn)的coverpoint可能只有designer 能提出來，需要盡早提出。Tb搭建之前，要充分的revie

7、w testplan，因為Testplan的較大修 改有可能會導致整個testbench的架構調整,effort較大。Testplan是一個需要不停增加，不 停迭代、不停review的東西。Error injection 要和 RTL-designer 逐條 review， 一個是看看 RTL-designer 是不是沒有想到，一 個是設計是不是本身就不允許、或者架構上本身不可能出現(xiàn)。Error-injection應該往深里去 好好挖掘。例如：內存控制器長時間不回數(shù)據(jù)（這里本身是一個隨機點）d由于長時間不回 數(shù)據(jù)是否產生錯誤中斷d產生錯誤中斷以后如何響應d響應不過來如何恢復d必須用softwa

8、re reset做恢復的話，對software的時機是否有要求dsoftware前需要遵守什么要求和步驟 雖然現(xiàn)在有一些工具可以根據(jù)規(guī)范化描述的testplan自動生成cover-point和assertion，不過 我覺得自然語言描述的testplan應該是最“自然”的。Q：哪些地方做隨機？A： 1）隨機配置（一般都想得到的），但是對于一個封閉的系統(tǒng)常常是最不重要的，因為 firmware可以自己開發(fā)，從而控制配置的流程和數(shù)值2）隨機激勵數(shù)據(jù)（很重要）3）隨機時序（通常容易被忘記）但是有一點要明確：隨機不是全隨機，是約束隨機，是在合理的范圍內盡量充分的隨機。Q：寫約束隨機哪些地方要注意？A：

9、推薦看snug papero （over-constraint導致測試不完全，欠約束導致不必要的debug和資 源的浪費）約束的效率：寫的不好會導致隨機失敗Q： Coverage 如何做？A： code-coverage 和 function-coverage（covergroup, assertion coverage ）。對于 constraint-random 的地方用covergroup做，對于一些時序的coverage可以用assertion-coverage。：核心腳本？A：單個仿真的腳本-建立所使用的不同的目錄、不同的seed （目錄可以叫case_$seed 這樣的格式；當然對

10、于直接的testcase，可以是case_$casename）；環(huán)境變量和license的管 理；如果需要做離線比對也可以讓腳本來自動調用比對腳本或命令（也可以在tb的代碼里 使用$system 或者$systemf）。批量仿真的腳本-自動批量提交到lsf上。自動收集log信息以判斷哪些case失敗，對于失 敗的case能自動重新提交，并且自動dump波形。以及產生批量仿真結束以后的匯總信息。 Q： SV中重要的點？A：特殊的數(shù)據(jù)類型，比如新增的三種array （動態(tài)、associate、queue） string （match函數(shù)、 backref 函數(shù)，參考 vcs 的 svtb.pdf）

11、；面向對象編程思想（handle）； coverage； constraint-randomo 熟練掌握這些語言點的用法很有必要。Q： VMM 1.0夠不夠？A：剛開始用1.0來建立起vmm的概念，然后轉到1.1或者1.2上。個人覺得不是必須一下 子就轉到1.1或1.2上（當然，1.1的一些擴展宏的確很好用）。個人建議vmm1.0+1.1的擴 展宏+subenvQ：是否要使用VIP？A： VIP的使用-復雜仿真模型推薦用VIP，簡單的建議自己做。如果自己開發(fā)仿真模型的 話，也推薦看看VIP的文檔，經?？梢钥吹揭恍┯袃r值的error-injection和random-test-points 來完

12、善你自己的testplan。Q：要不要做門級仿真？A：如果是走design-service，不知道最終帶sdf的netlist仿真是否需要做，如果做的話，最 好在release綜合后netlist的時候也做一下（插完scan-chain和做完CTS以后有條件也做一 下），如果需要VCD文件做power分析和指導PR工具的話，那么門仿是必須做的。如果 design-service公司不負責調量產pattern的話，那么ATPG等的門仿是需要自己做的。門仿并不是sign-off標準，但是推薦還是做一下，經常還是能跑出問題來的。如果做sdf反 標的門仿的話，對于async的多級dff要剔除掉（VCS

13、和NC都有option，vcs可以查手冊里+optconfigfile”，NC 查” +nctfile”）。反標 Sdf 仿真的時候推薦 notimingcheckano_notifya checking_timing with optconfigfile 的三步走。前期在評估IP的時候，有可能個別模塊可能需要單獨搭門級環(huán)境，比如CPU-IP有RTL，要 自己做flow，那么通常是需要做門仿的（有可能主要是為了跑vcd或saif做power分析）。Tb的修改：由于CTS和綜合的原因，導致時鐘名字和信號名字有變化，所以tb有可能要修 改。另外，tb里的probe文件建議使用反沿采樣，也是為了避免

14、帶sdf反標以后clk踩不到 整個data-vector。除此之外，個人不太建議在門仿的時候依然使用自動化的tb。因為你的 tb里抓的很多內部信號可能名字變了（或者被優(yōu)化掉了），這樣導致tb在門級跑的時候維護 起來有些麻煩。有些信號即便名字不變，可能會反向，這樣會導致你的checker誤報錯。畢 竟在門仿的時候不用跑太多的testcase，可以靠幾條和rtl仿真 對應的仿真來覆蓋。門仿 畢竟不是為了 function，而是為了檢查timing。如果你的設計里用了不帶reset的dff的描述，由于開始不定態(tài)的傳播，可能導致你門仿失 敗。個人推薦的方法是：如果特別多的話，用腳本找到對應模塊里所有d

15、ff，產生一個force-release文件（注意：很影響編譯時間，所以能不用就不用）Q： FPGA和仿真如何安排順序？A：首先是schedule優(yōu)先，其次是力所能及。但是原則上是先仿真然后再上FPGA，仿真可 以很快的掃清一些基本的bug。給仿真的時間充裕的話，那就仿真盡量往前趕，盡量在上FPGA 之前多測一些（不是太多case的情況下，F(xiàn)PGA的測試速度畢竟要快一些）。即便FPGA很著 急上，起碼也讓仿真先用幾條直接testcase調試通過最基本的功能。第一版FPGA可能因為 接死、懸空和信號反向導致邏輯被優(yōu)化掉，這些問題有時候用仿真也不能全發(fā)現(xiàn)，就要結合 leda等lint工具。Q：仿真

16、如何復現(xiàn)FPGA發(fā)現(xiàn)的bug？A：首先保證配置的一致性，可以考慮做一些內部的工具。仿真上要probe寄存器操作端口， FPGA上要能把firmware里的配置流程轉成文本。如果配置一樣還是不能發(fā)現(xiàn)的話，再去邏輯分析儀上debug時序。當然，CDC的問題在仿真 上是看不到的。個人不建議做FPGA網(wǎng)表的門仿，有點得不償失。Q： FPGA不能cover的部分的驗證？A： PAD_Mux （Test_mux）、Clkrst、Power-management-unit 以及 FPGA 跑不到的高頻所對應 的功能。Clkrst 這部分主要就是 pllconfig、clock-gate、divider、so

17、ft-and-hard reset,從測試點 的角度還是很明確的，RTL代碼修改的少的話，可以考慮不用做太復雜的驗證（但是clkrst 模塊里可能會有一些控制邏輯或者狀態(tài)機，比如：sdram的切頻，這里一般是需要一個狀態(tài) 機控制的，這個需要仔細和小心的驗證。）PAD_mux個人比較推薦使用自動化的流程，因為代碼風格非常固定，所以可以用腳本生成 RTL和用腳本生成testcase （一般這樣的testcase是一堆的force）PMU建議看看VCS的MVsim的文檔，里面介紹的很清晰了。（還是要配合靜態(tài)驗證工具MVRC 一起來做）沒有MVSim的話，可以考慮用VCS的$power $isolat

18、e（Q：固化的firmware如何驗證？A：個人不建議讓仿真去覆蓋firmware，但是對于FPGA和ASIC不一樣的地方要重點覆蓋到。 大的流程要覆蓋到，其他細節(jié)由FPGA保證。Q：架構評估？A：我經驗也不多，舉幾個例子。比如你的總線拓撲合理不合理？內存控制器的效率（機制） 是否滿足你的應用？使用哪類Cache ? Cache的大?。磕K的FIFO深度夠不夠 （error-injection可以測到）？算法需要多少mips （rvds等工具帶的模擬器可以給出結論，但是要讓模擬器能考慮到內存access的latency）？軟件里如果有不少memcpy的話，要模 擬系統(tǒng)運行起來以后memcpy的

19、效率。如果沒有人手專門用ESL （如Carbon的CMS）工具的話，建議在驗證平臺上做（當然一旦 有大問題，要推翻架構會很麻煩）。Q：哪些資源要節(jié)??？A：當然首先是人（數(shù)）要節(jié)省，人的成本比起計算資源成本和存儲資源成本要大多了。提 高技術、提高自動化程度才能節(jié)省人的成本。（低Package這種方法屬于傷天害理的手段， 不是正當途徑）減少硬盤需求（如果有必要）共享simv/simv.daidircsrc包括regression過程中自動清理磁盤 空間）；激勵數(shù)據(jù)是否可以不一下子全產生出來（對于通訊類的比較有意義，由于是floating 的激勵數(shù)據(jù)，所以經常很短時間就需要GB的空間）。注意對每個人

20、每個項目設置硬盤quota， 避免被個別人撐爆存儲。減少編譯次數(shù)。soc項目里比較有必要，testcase基于firmware ），parallel-compile or separate-compile，vmm-test，在一個 testcase 里做多個功能點的覆蓋，fsdb/vpd 的 dump 層次的改變不要重新編譯（fsdb有command，vpd可能得用ucli）。Q：設計規(guī)模大了編譯很慢怎么辦？A：有時候設計規(guī)模太大導致編譯很慢，但是SoC項目很多情況下，功能模塊彼此之間是用 總線隔開的（即便在功能模塊之間有硬件連線也可以考慮用仿真模型來做替代）。在仿真某 一個功能模塊的時候，可

21、以考慮dummy掉不相關的模塊。但是這就引入了一個新問題“文件列表的維護”?；谶@種dummy的思想，文件列表的維 護就成了 tb里的一個很關鍵的地方，要盡量避免維護太多的文件列表。我個人比較推薦利 用腳本來自動產生所需要文件列表。除此之外，仿真用的文件列表里我個人比較推薦用絕對 路徑（避免別人debug的時候出現(xiàn)調錯文件的問題，另外可以指定不同的工作目錄）。CVS 里用相對路徑，相對路徑轉絕對路徑的工作由腳本自動完成。Q：編譯還是運行option？A:為了減少編譯的次數(shù)，能使用運行的option就使用運行的option。比如使用$value$plusargs$test$plusargsQ：

22、Assertion 誰來寫？A：建議RTL designer和IC驗證工程師都寫。內部實現(xiàn)細節(jié)的描述由RTL-designer自己寫， 模塊之間的時序由IC驗證工程師來寫。Assertion的抽象層次有些高，寫復雜了有時候極容易出現(xiàn)和你想象不一致的地方。而且如 果spec上描述的不清楚，誤報assertion-fail也會引入不必要的debug時間。Q： IC驗證工程師要不要看RTL？A：不是很必要，但是有些設計背景比較強的驗證工程師看代碼通常能看到一些問題。個人 建議還是拿出點時間來review 一下RTL code。：自動化的tb搭好了，波形對驗證工程師來說還那么重要嗎？A：非常非常的重要

23、。毋庸置疑！波形是最直接的，checker可能寫錯，有問題沒有報出來。 但是沒有激勵就沒有所要的波形信息。Q：如何重用？A： reuse可以分為橫向和縱向。橫向是指項目之間。這個reuse主要包括：文檔和tb、script?？v向是指同一個項目內，一般是模塊級和系統(tǒng)級（包括子系統(tǒng)級）。一般是tb和scripto 比如在一個項目中，所有的tb都是用run_sim和regress腳本的，只是帶的filelist不同。對 于tb來說，driver和generator可能不能reuse，但是一般monitor和scoreboard這類被動接 收的一般都可以reuse。而且testcase通常是可以reu

24、se的。對于SoC類項目，為了保持testcase的一致性，我個人比較傾向于都使用firmware做testcase， 這就要求1）模塊的驗證也要基于一個（類）soc的tb下驗證。2）cpu-ip要盡量簡單，否則cpu會占用太多的仿真資源。個人推薦用iss做cpu-ip，負責配 置寄存器。Q： regression什么時候做？做多少次？A： tb好了以后，任何時候都可以做。下班后盡量提交regression到lsf里，讓機器充分的跑。 如果你的環(huán)境是random的，那么隨機空間實際是很大的（隨著random-test-point的增長指 數(shù)級增長），所以只要seed不同，其實是可以跑到各種各樣

25、的情況。Q： DPI要不要用？A：有的人很喜歡用DPI，不過我個人不喜歡用。我盡量是把C封裝好（自己寫wrapper）， 產生可執(zhí)行文件，然后在tb里用$systemf來調。不喜歡用DPI的原因主要是因為如果代碼 里有不太安全的地方（比如C代碼里你不是在堆上而是在棧上開了一個大數(shù)組，或者C和 SV之間的參數(shù)傳遞寫法不合理），很容易造成coredumpo而且你也不確定到底是SV寫的不 安全還是C寫的不安全。另外，有些大公司的算法源代碼是不提供的，只給你一個.o文件， 這樣coredump 了你debug起來會讓你有砍人的沖動。但是不用DPI也帶來一些壞處：1）要自己寫一些wrapper之類的代碼

26、2）靜態(tài)變量處理要小心。舉個例子：我是每幀調一次systemf來做比對，某個函數(shù)每次比對會 被調用一次。函數(shù)里的靜態(tài)變量就沒什么靜態(tài)的意義了。如果不做修改的話，肯定會出錯。 一般是要求算法組盡量少用靜態(tài)變量，非用不可的話，我們會把靜態(tài)變量改成全局變量，然 后讓systemf多一個參數(shù)。要說明的是：DPI “天然”的就是tb的一部分。但是我覺得把時間浪費在debug算法C代 碼的優(yōu)劣上是一件很不值得的事情（無論什么時候都是schedule優(yōu)先），當然我也很佩服有 些人對任何事情都“精益求精”的態(tài)度。無論用不用DPI，你都可以使用DDD這類debug工具。DDD這種工具在非DPI情況下用起來 會更

27、加的得心應手。Q： Force要不要用？A：有的人比較抵觸用Force-release，覺得如果寫的不注意的話，可能會浪費時間（debug 或者re-compile）。個人覺得“規(guī)定所有人把各自模塊的force語句寫在一個文件里，然后再 被一個統(tǒng)一的force_prj.sv include進去，并且include前要有ifdef保護起來”應該可以規(guī)避 掉一些風險。Q：人手少的情況下怎么做驗證？A：我個人覺得驗證不能大包大攬，人手少的話就要更多的靠RTL-designer自己做驗證。對 于某些模塊驗證工程師就不要做了，否則陷進去出不來，反而影響了核心模塊的驗證力度。 可以適當?shù)母嘁蕾嘑PGA。但是對于核心模塊一定要做好驗證