0 引言

　　在傳統(tǒng)的驗(yàn)證流程中，通常會(huì)先編寫好驗(yàn)證計(jì)劃（verification plan，vplan），然后再編寫驗(yàn)證用例（testcase）。但是由于項(xiàng)目需求、規(guī)格變更，驗(yàn)證計(jì)劃和testcase會(huì)有著比較大差異的情況，testcase不能真實(shí)地反映驗(yàn)證計(jì)劃，而驗(yàn)證計(jì)劃就失去了其指導(dǎo)testcase編寫的本意。要避免這種情況發(fā)生，就需要工程師手動(dòng)對(duì)驗(yàn)證需求、覆蓋目標(biāo)、覆蓋結(jié)果進(jìn)行管理和跟蹤，使得驗(yàn)證迭代過程變得繁瑣，耗時(shí)，降低驗(yàn)證效率。

　　借助于vManager，通過完整的標(biāo)準(zhǔn)度量驅(qū)動(dòng)驗(yàn)證（Metric Driven Verification，MDV）流程參見圖1，可以很好地解決上面存在的問題。MDV驗(yàn)證方法使用功能覆蓋率，仿真正確性檢查和斷言作為驗(yàn)證需求通過準(zhǔn)則(Metrics)，并使驗(yàn)證計(jì)劃成為驗(yàn)證過程本身的一個(gè)可執(zhí)行的(executable)部分，即使用驗(yàn)證過程自動(dòng)化工具制定（或讀?。?yàn)證計(jì)劃，并收集覆蓋數(shù)據(jù)，產(chǎn)生基于驗(yàn)證計(jì)劃的狀態(tài)報(bào)告。使得驗(yàn)證計(jì)劃在整個(gè)項(xiàng)目周期內(nèi)充當(dāng)驗(yàn)證過程檢驗(yàn)標(biāo)準(zhǔn)的角色。

圖1  完整的MDV流程

1 建立executable驗(yàn)證計(jì)劃

　　驗(yàn)證計(jì)劃的編寫是整個(gè)MDV流程的開始，在MDV流程中通過vplanner進(jìn)行編寫驗(yàn)證計(jì)劃，如圖2所示，在vplanner中添加了兩個(gè)用例[1]。在這里一開始并沒有編寫完全部的驗(yàn)證計(jì)劃，主要是基于以下兩個(gè)原因：(1)驗(yàn)證計(jì)劃是一個(gè)逐次迭代的過程，隨著驗(yàn)證工作的展開，以及對(duì)DUT(Design Under Test)理解的加深，驗(yàn)證計(jì)劃會(huì)修改多次，所以一開始，先編寫兩個(gè)簡單用例，跑通數(shù)據(jù)流，為后續(xù)工作的開展，奠定堅(jiān)實(shí)的基礎(chǔ)；(2)以這兩個(gè)testcase為例，重點(diǎn)介紹如何將所編的vplan和testcase建立一種關(guān)聯(lián)，而這種關(guān)聯(lián)的建立，是MDV流程的基礎(chǔ)，同時(shí)它能夠使得驗(yàn)證計(jì)劃和testcase的更新相互促進(jìn)。

圖2  vplanner編寫testcase

　　1.1 vsif和仿真腳本

　　vsif(Verification Session Input Format)文件是整個(gè)MDV流程的重要組成部分，該文件中描述了vManager在啟動(dòng)仿真時(shí)，需要執(zhí)行的用例、仿真時(shí)需要執(zhí)行的腳本、每個(gè)用例最長的仿真時(shí)間等內(nèi)容[2]，根據(jù)文獻(xiàn)[2]的方式，編寫的debug_tb.vsif文件的部分內(nèi)容如圖3所示。

圖3  vsif文件部分內(nèi)容

　　在這個(gè)group geInternal_intfFormat里面，設(shè)定了這個(gè)group中用例需要執(zhí)行的次數(shù)、所使用的種子、用例的名稱、以及這個(gè)用例所執(zhí)行的模式，同時(shí)也可以根據(jù)自己的需要設(shè)定其他的一些信息。

　　1.2 vplan和驗(yàn)證平臺(tái)testcase/覆蓋率模型(ucm)建立關(guān)聯(lián)

　　在vManager中l(wèi)aunch一個(gè)vsif（Verification Session Input Format）文件，待仿真結(jié)束后，在vplanner中l(wèi)oad某個(gè) session，然后進(jìn)行驗(yàn)證平臺(tái)中的testcase和vplan中的testcase建立關(guān)聯(lián)的操作，如圖4所示。

圖4  選中對(duì)應(yīng)的session

　　接下來，點(diǎn)擊Metrics標(biāo)簽，然后窗口左右兩邊選中對(duì)應(yīng)的testcase，點(diǎn)擊map建立關(guān)聯(lián)， Map之后，需要對(duì)vplan進(jìn)行保存。

　　通過前文的介紹，已經(jīng)建立了vplan與testcase的關(guān)聯(lián)，通過這種關(guān)聯(lián)，在vmanager中可以實(shí)時(shí)地查看vplan中相關(guān)feature的覆蓋情況（不僅僅局限于Testcase，同時(shí)也可以包括assertion、function coverage等，圖5中僅以testcase為例，關(guān)于assertion也將在下文介紹），通過這種圖形化的顯示，可以讓驗(yàn)證人員更加直觀地了解到vplan中哪些feature尚未被覆蓋，可以及時(shí)調(diào)整工作方向和工作重點(diǎn)。

圖5  vplan中的覆蓋情況

2 多維度度量分析

　　當(dāng)仿真進(jìn)行到一定階段之后，需要進(jìn)行testcase、assertion、coverage三個(gè)方面的分析，表現(xiàn)在vplan中的testcase被執(zhí)行了多少，還剩余哪些；assertion 是否被觸發(fā)；coverage達(dá)到了多少，哪些testcase對(duì)coverage的貢獻(xiàn)最新，所有的這些分析在Analysis Center中完成。

　　2.1 testcase和assertion分析

　　首先，按照上一個(gè)小節(jié)介紹的方法，增加相關(guān)用例，然后在vManager中l(wèi)aunch相關(guān)vsif文件，仿真結(jié)束后在vplan中l(wèi)oad相關(guān)session，那么接著就可以在vManager中進(jìn)行分析，圖6中展示了部分testcase的覆蓋情況：

圖6  vplan分析

　　從圖6中可以看到在vplan中關(guān)于1.1.1的gmii的testcase這一Metric已經(jīng)被覆蓋了，單從testcase上說，暫時(shí)可以告一段落了，后續(xù)如果再需要添加相應(yīng)用例的話，也可以按照上面的前文所述之方法進(jìn)行相對(duì)應(yīng)的分析。

　　正如前文所言，驗(yàn)證工程師需要從多個(gè)維度展開驗(yàn)證工作，testcase的編寫只是一方面，斷言assertion也是非常有用的手段，添加assertion之后，這些assertion是否被觸發(fā)，是否成功都需要關(guān)注。在MDV中，assertion也可以反映在vplan中，而且可以與testcase類似進(jìn)行相對(duì)應(yīng)的map，在vplan中添加的斷言如圖7所展示。

圖7  vplan中添加assertion

　　在仿真結(jié)束之后，load相應(yīng)的session，在vplan中可以進(jìn)行如圖8的map。

圖8  對(duì)assertion進(jìn)行map

　　完成map之后，可以對(duì)assertion進(jìn)行分析，如圖9所示。

圖9  assertion覆蓋情況

　　通過上面的操作，可以將所編寫的assertion清晰地展現(xiàn)出來，其優(yōu)點(diǎn)體現(xiàn)在以下幾個(gè)方面：

　　(1)整個(gè)驗(yàn)證計(jì)劃中有哪些assertion，可以清晰地展現(xiàn)。

　　(2)assertion是否被覆蓋可以在vplan分析中容易被發(fā)現(xiàn)。

　　不會(huì)在regression中遺漏assertion。這是因?yàn)閍ssertion對(duì)仿真速度有著很大的影響，可能在某次仿真中，驗(yàn)證工程師“關(guān)閉”了assertion，但是在后期的regression中又忘記“打開”，而使用vplan進(jìn)行map以及在vmanager中對(duì)vplan進(jìn)行分析，就可以很好地避免這種情況的出現(xiàn)。

　　2.2 Coverage分析

　　驗(yàn)證過程中需要在適當(dāng)?shù)睦锍瘫?jié)點(diǎn)關(guān)注DUT的coverage情況，以便及時(shí)地添加用例，同時(shí)在regression時(shí)，確定哪些用例對(duì)覆蓋率貢獻(xiàn)比較高，那么在regression的時(shí)候，就可以優(yōu)先回歸；而對(duì)覆蓋率貢獻(xiàn)比較低的testcase，可以分析其原因加以改進(jìn)。另外在覆蓋率分析的時(shí)候，可能某些特定的模塊和開發(fā)溝通之后知道它是冗余的或者不需要覆蓋，而這些不需要覆蓋的模塊可以通過在coverage分析的時(shí)候?qū)⑵洹疤蕹?，最終使coverage達(dá)到可解釋的100%如圖10所示。

圖10  coverage分析

　　我們可以通過圖10對(duì)coverage的情況有直觀的了解，同時(shí)也可以在instance名字，比如GE4_MAC_TX上右擊，然后進(jìn)行更加細(xì)致地分析比如Block Analysis、Expression Analysis、FSM Analysis等，關(guān)于這些細(xì)節(jié)這里不再進(jìn)行詳細(xì)地探討，留給讀者自行嘗試。這里介紹如何確定testcase對(duì)coverage貢獻(xiàn)的情況，那么在后續(xù)regression時(shí)，可以優(yōu)先執(zhí)行對(duì)coverage貢獻(xiàn)大的用例。

　　在Analysis Center中，執(zhí)行Rank Runs操作，其方法在圖11給出了描述。

圖11  Rank Runs

　　在Rank Runs的結(jié)果中，需要重點(diǎn)關(guān)注兩列。testRankRuns(Rank)，這一列顯示出用例對(duì)覆蓋率整體的貢獻(xiàn)大?。涣硗庖涣惺莇elta_testRankRuns(Rank)，它顯示了在所有羅列的仿真中，本次仿真用例相對(duì)于其他用例，對(duì)coverage貢獻(xiàn)的大小。例如第一行的geInternal_intfFormat/RVC_pcs2mac_metric，在仿真中相對(duì)其他testcase而言，對(duì)coverage的貢獻(xiàn)是67.74%；而那些delta_tessRankRuns(Rank)為0的行，表示，在這次仿真中，相對(duì)其他的幾次的仿真，對(duì)coverage沒有任何額外的貢獻(xiàn)。值得注意的是RVC_pcs2mac_metric在第一行中delta_tessRankRuns(Rank)為67.74%；而在最后一行中delta_tessRankRuns(Rank)為0%，這是因?yàn)樵诜抡嬷杏美赡鼙粓?zhí)行多次，而且每次的seed都有可能是隨機(jī)的，那么就會(huì)出現(xiàn)同一個(gè)testcase對(duì)coverage貢獻(xiàn)不同的情況。

3 項(xiàng)目級(jí)別狀態(tài)進(jìn)展匯報(bào)

　　3.1 項(xiàng)目進(jìn)度狀態(tài)跟蹤

　　驗(yàn)證工程師不僅要完成日常工作，還有需要將工作之進(jìn)展向驗(yàn)證經(jīng)理進(jìn)行匯報(bào)，在vManager中提供了非常方便的Report功能，生成Report的格式也可以是多樣的；另一方面，作為驗(yàn)證經(jīng)理也需要關(guān)注每個(gè)驗(yàn)證工程師testcase執(zhí)行的情況，如testcase總數(shù)、pass多少、失敗多少；或者是在某個(gè)時(shí)間段內(nèi)，驗(yàn)證工作的進(jìn)展。vManager的Tracking Center提供了非常便捷的方式，以多樣化的圖表展示出驗(yàn)證工作的進(jìn)展。

　　首先，需要Taking snapshot，選中所要分析的sessions，然后執(zhí)行如圖12中所示的操作。

圖12  take snapshot

　　在Tracking Center中，可以看到生成的表格顏色，其中bar的顏色是可以自己設(shè)置的，從圖13中可以看到這個(gè)session中，用例總共是6個(gè)，pass和fail都是3個(gè)。

圖13  用例執(zhí)行情況（toatal、Pass、Fail）

　　按照上面的方法，可以再增加一些session，其結(jié)果如圖14所示。

圖14  增加多個(gè)session

　　通過圖14，比較直觀地了解到這幾個(gè)工作日用例執(zhí)行的情況；在tracking center中，也可以tracking coverage的情況，通過tracking coverage，驗(yàn)證工程師能夠更好地調(diào)整用例的執(zhí)行，否則即使用例pass再多，coverage一直很低，或者一直維持在一個(gè)恒定的水平，那么說明testcase設(shè)計(jì)的不夠合理，或者是沒有使用隨機(jī)化種子。

　　基于這樣的考慮，我們進(jìn)行在tracking center中查看coverage的情況，其主要步驟如圖15所示。最終的結(jié)果如圖16所示。

圖15  tracking metric

圖16  coverage圖表

　　驗(yàn)證工程師，生成了所需要的數(shù)據(jù)，可以將結(jié)果反饋給驗(yàn)證經(jīng)理，數(shù)據(jù)結(jié)果的生成也是比較簡單的，點(diǎn)擊Create Report，然后選擇相應(yīng)的路徑即可，如圖17所示。查看生成的最終結(jié)果如圖18所展示。

圖17  生成Report

圖18  最終的html格式圖表（部分內(nèi)容）

　　通過上面的操作，將所感興趣的內(nèi)容最終以html格式的文件向驗(yàn)證經(jīng)理進(jìn)行匯報(bào)，通過圖表，更加直觀地展示了工作的進(jìn)展，coverage的趨勢，有助于降低項(xiàng)目的風(fēng)險(xiǎn)，節(jié)省項(xiàng)目管理所需要的時(shí)間。

　　3.2 基于server的項(xiàng)目管理

　　在上一個(gè)小節(jié)中，提及了驗(yàn)證工程師如何向驗(yàn)證經(jīng)理匯報(bào)工作進(jìn)展，作為驗(yàn)證經(jīng)理，從項(xiàng)目管理的角度，需要知曉團(tuán)隊(duì)中所有的驗(yàn)證工程師的工作進(jìn)展，而傳統(tǒng)的EDA工具無法讓驗(yàn)證經(jīng)理實(shí)時(shí)知曉每個(gè)人的進(jìn)展，用例執(zhí)行情況，用例耗時(shí)等信息，這些信息需要在周末或者月末匯總之后才可以得知。

　　vManager是基于server進(jìn)行管理的，server的地址以及端口號(hào)，需要設(shè)置在環(huán)境變量中，設(shè)置完成之后，驗(yàn)證工程師在自己的服務(wù)器上啟動(dòng)vManager，launch vsif文件啟動(dòng)仿真時(shí)，這些信息會(huì)傳遞到server上，驗(yàn)證經(jīng)理可以在自己的服務(wù)器上啟動(dòng)vManager，在regression Center中查看每個(gè)人的情況，如圖19所示。

圖19  查看項(xiàng)目中所有的seesion

　　當(dāng)然驗(yàn)證經(jīng)理也可以在tracking Center中查看到所有session狀態(tài)，如pass, fail, session duration time等等，如圖20所示。

圖20  查看團(tuán)隊(duì)中所有用例執(zhí)行情況

4 小結(jié)

　　Cadence vManager作為MDV驗(yàn)證方法的實(shí)現(xiàn)工具，將項(xiàng)目驗(yàn)證過程變得自動(dòng)化和可管理化。本文由vplan和session如何建立關(guān)聯(lián)開始，詳細(xì)地介紹了建立關(guān)聯(lián)的意義以及流程。接著向讀者展示如何借助于vManager進(jìn)行testcase分析，assertion分析，重點(diǎn)介紹了如何在Coverage分析時(shí)，如何借助于Rank Runs查找對(duì)覆蓋率貢獻(xiàn)最大的testcase。最后介紹了驗(yàn)證工程師如何利用tracking Center生成相關(guān)報(bào)告，以便更加直觀地反饋?zhàn)约旱倪M(jìn)展以及所負(fù)責(zé)模塊的覆蓋率趨勢；驗(yàn)證經(jīng)理如何利用regression Center查看團(tuán)隊(duì)session執(zhí)行的情況，以及在Tracking Center中以圖表的形式查看整個(gè)團(tuán)隊(duì)session執(zhí)行的情況。

　　驗(yàn)證質(zhì)量的提升與MDV驗(yàn)證方法的實(shí)施緊密相連。工具本身并不能保證驗(yàn)證的完備性，但其具備的制定可執(zhí)行驗(yàn)證計(jì)劃，自動(dòng)回歸驗(yàn)證管理及仿真數(shù)據(jù)管理，覆蓋率分析，以及驗(yàn)證進(jìn)度可視化等功能為MDV驗(yàn)證方法的實(shí)施提供了強(qiáng)有力的支撐，為驗(yàn)證過程中大量耗時(shí)管理工作節(jié)約了時(shí)間，使驗(yàn)證工程師能夠有更多時(shí)間專注于設(shè)計(jì)本身，對(duì)設(shè)計(jì)中功能點(diǎn)進(jìn)行詳細(xì)分析和驗(yàn)證，以提升驗(yàn)證完備性。

　　當(dāng)驗(yàn)證計(jì)劃發(fā)生變化時(shí)，所有改動(dòng)都能夠被工具記錄，跟蹤并保證最終能得以驗(yàn)證，因而可執(zhí)行的驗(yàn)證計(jì)劃在整個(gè)驗(yàn)證過程中都是有意義的一部分，而非如傳統(tǒng)驗(yàn)證計(jì)劃，在項(xiàng)目初期完成后就很少被使用。同時(shí)，可執(zhí)行的驗(yàn)證計(jì)劃使驗(yàn)證進(jìn)度變得透明，幫助驗(yàn)證團(tuán)隊(duì)提高驗(yàn)證可預(yù)見性，以及更好的利用資源。

　　參考文獻(xiàn)

　　[1] Cadence.2_mdv_foundations_planning workshop.pdf.

　　[2] Cadence.3_mdv_foundations_infrastructure_workshop.pdf.