0 引言

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

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

圖1  完整的MDV流程

1 建立executable驗證計劃

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

圖2  vplanner編寫testcase

　　1.1 vsif和仿真腳本

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

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

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

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

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

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

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

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

圖5  vplan中的覆蓋情況

2 多維度度量分析

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

　　2.1 testcase和assertion分析

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

圖6  vplan分析

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

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

圖7  vplan中添加assertion

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

圖8  對assertion進行map

　　完成map之后，可以對assertion進行分析，如圖9所示。

圖9  assertion覆蓋情況

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

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

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

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

　　2.2 Coverage分析

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

圖10  coverage分析

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

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

圖11  Rank Runs

　　在Rank Runs的結(jié)果中，需要重點關(guān)注兩列。testRankRuns(Rank)，這一列顯示出用例對覆蓋率整體的貢獻大??；另外一列是delta_testRankRuns(Rank)，它顯示了在所有羅列的仿真中，本次仿真用例相對于其他用例，對coverage貢獻的大小。例如第一行的geInternal_intfFormat/RVC_pcs2mac_metric，在仿真中相對其他testcase而言，對coverage的貢獻是67.74%；而那些delta_tessRankRuns(Rank)為0的行，表示，在這次仿真中，相對其他的幾次的仿真，對coverage沒有任何額外的貢獻。值得注意的是RVC_pcs2mac_metric在第一行中delta_tessRankRuns(Rank)為67.74%；而在最后一行中delta_tessRankRuns(Rank)為0%，這是因為在仿真中用例可能被執(zhí)行多次，而且每次的seed都有可能是隨機的，那么就會出現(xiàn)同一個testcase對coverage貢獻不同的情況。

3 項目級別狀態(tài)進展匯報

　　3.1 項目進度狀態(tài)跟蹤

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

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

圖12  take snapshot

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

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

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

圖14  增加多個session

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

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

圖15  tracking metric

圖16  coverage圖表

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

圖17  生成Report

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

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

　　3.2 基于server的項目管理

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

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

圖19  查看項目中所有的seesion

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

圖20  查看團隊中所有用例執(zhí)行情況

4 小結(jié)

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

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

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

　　參考文獻

　　[1] Cadence.2_mdv_foundations_planning workshop.pdf.

　　[2] Cadence.3_mdv_foundations_infrastructure_workshop.pdf.