我對(duì)驗(yàn)證的一些理解

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

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

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

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

5、？A：分享一份我做的基本培訓(xùn)內(nèi)容安排，供參考Perl，Makefile，AMBA 介紹，SVTB.pdf ，sva,幾種用到的編程語(yǔ)言的 File operation ，Low-power， C-pointer， Cshell-AWK+SED， 體系結(jié)構(gòu)相關(guān)的一些 內(nèi)容，SV-1Day training ， VMM_source_code ,Arm的嵌入式編程的基本概念 。：自動(dòng)化必須嗎？A：不是必須的，但是應(yīng)該盡量去實(shí)現(xiàn)自動(dòng)化。總之是多讓機(jī)器跑。如果人均License太少 的話，要盡量做到白天debug、晚上讓機(jī)器跑?！氨葘?duì)”這種事情太機(jī)械了，所以盡量讓機(jī) 器做，做這種事情機(jī)器的效率比人高太

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

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

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

9、推薦看snug papero （over-constraint導(dǎo)致測(cè)試不完全，欠約束導(dǎo)致不必要的debug和資 源的浪費(fèi)）約束的效率：寫的不好會(huì)導(dǎo)致隨機(jī)失敗Q： Coverage 如何做？A： code-coverage 和 function-coverage（covergroup, assertion coverage ）。對(duì)于 constraint-random 的地方用covergroup做，對(duì)于一些時(shí)序的coverage可以用assertion-coverage。：核心腳本？A：?jiǎn)蝹€(gè)仿真的腳本-建立所使用的不同的目錄、不同的seed （目錄可以叫case_$seed 這樣的格式；當(dāng)然對(duì)

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

11、；面向?qū)ο缶幊趟枷耄╤andle）； coverage； constraint-randomo 熟練掌握這些語(yǔ)言點(diǎn)的用法很有必要。Q： VMM 1.0夠不夠？A：剛開始用1.0來(lái)建立起vmm的概念，然后轉(zhuǎn)到1.1或者1.2上。個(gè)人覺得不是必須一下 子就轉(zhuǎn)到1.1或1.2上（當(dāng)然，1.1的一些擴(kuò)展宏的確很好用）。個(gè)人建議vmm1.0+1.1的擴(kuò) 展宏+subenvQ：是否要使用VIP？A： VIP的使用-復(fù)雜仿真模型推薦用VIP，簡(jiǎn)單的建議自己做。如果自己開發(fā)仿真模型的 話，也推薦看看VIP的文檔，經(jīng)常可以看到一些有價(jià)值的error-injection和random-test-points 來(lái)完

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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