覆蓋率的要求

????????覆蓋率是衡量激勵生成種類和功能點驗證的量化指標(biāo)。無論通過何種驗證方法，我們都需要采用覆蓋率來確保給出了足夠多的激勵類型，并且設(shè)計的邊界和內(nèi)部窮舉了可能的狀態(tài)。

????????覆蓋率可以分為代碼覆蓋率、功能覆蓋率和斷言覆蓋率。除了給出合法的激勵之外，也需要考慮給出一些錯誤的激勵，來測試設(shè)計的穩(wěn)定性和糾錯能力。

在驗證過程中，我們需要不斷地更新驗證進(jìn)度，從各項參數(shù)綜合評估驗證的完備性。我們通過收集以下信息來評估驗證計劃的實施進(jìn)度：

※ 回歸測試通過率（regression pass rate），一份回歸測試表是將測試設(shè)計所有功能點的用例合并為一個測試集?；貧w測試表的主要功能是用來在設(shè)計經(jīng)過缺陷修復(fù)或者性能提高后測試原有的所有功能點，確保設(shè)計仍然可以正常工作。為了能夠保證測試出來bug的場景可以重現(xiàn)，我們需要在測試中顯示每次使用到的隨機(jī)種子（random seed），只有通過這個特定的種子，我們才可以重新產(chǎn)生之前的激勵，跟蹤調(diào)試失敗的用例。

※ 代碼覆蓋率（code coverage），代碼覆蓋率是用來衡量RTL代碼是否被充分運(yùn)行的指標(biāo)，目前的仿真器也都提供方法來收集代碼覆蓋率，并且進(jìn)行合并和分析。

※ 斷言覆蓋率（assertion coverage），斷言描述本身也支持覆蓋率收集，一般可以通過仿真或者硬件加速的方式來收集，也可以通過形式驗證的工具來收集。

※ 功能覆蓋率（function coverage），功能覆蓋率是為了衡量設(shè)計的各項功能是否都實現(xiàn)了，并且按照預(yù)想的行為執(zhí)行。功能覆蓋率會關(guān)注設(shè)計的輸入、輸出和內(nèi)部狀態(tài)。

※ 缺陷曲線（bug curve），在驗證過程中，我們會不斷地發(fā)現(xiàn)新的設(shè)計缺陷，通過缺陷記錄表或者已有的商業(yè)工具記錄下來，進(jìn)而提交給設(shè)計人員。

※ 寄存器覆蓋率（register coverage）

驗證的不穩(wěn)定因素

????????※芯片結(jié)構(gòu)不穩(wěn)定：如果在項目執(zhí)行后期，突然面臨結(jié)構(gòu)的變化，這肯定會給相關(guān)設(shè)計帶來很大影響，而驗證任務(wù)量和時間也需要發(fā)生改變。

????????※工具的不穩(wěn)定：在新的項目中，更傾向于使用新的工具版本，因為它們會帶來新的性能提升和特性提升，而在新版本工具使用中也會有適應(yīng)期，并非一帆風(fēng)順。如果我們需要替換工具，那么面臨的工具替換成本、環(huán)境流程更新、技術(shù)培訓(xùn)都要更大一些。

????????※人力的不穩(wěn)定：我們都希望在項目中人員結(jié)構(gòu)可以穩(wěn)定，這樣就不會出現(xiàn)模塊的驗證人員被臨時替換，加大驗證風(fēng)險的問題。

????????※模塊交付時間的不穩(wěn)定：由于驗證的展開與設(shè)計的交付時間密不可分，所以HDL設(shè)計的交付時間對于驗證進(jìn)度的影響非常大，所以在計劃初期，驗證經(jīng)理應(yīng)該從設(shè)計團(tuán)隊哪里獲取清晰的交付時間，然后在此基礎(chǔ)上做進(jìn)度和人力安排。

驗證計劃

????????一份驗證計劃的模板應(yīng)該包括下面的結(jié)構(gòu)：1. 設(shè)計功能簡要描述 2. 硬件實現(xiàn)框圖 3. 待驗證的功能點 4. 驗證環(huán)境搭建 5. 測試用例構(gòu)成 6. 編譯腳本和回歸測試 7. 覆蓋率分析。

創(chuàng)建驗證環(huán)境

????????在實現(xiàn)激勵發(fā)生組件中，需要考慮接口信號是標(biāo)準(zhǔn)總線還是系統(tǒng)控制信號。如果是標(biāo)準(zhǔn)總線，那么應(yīng)該有對應(yīng)的總線驗證IP的復(fù)用資源，這樣會節(jié)省構(gòu)建平臺的時間。

????????我們也要考慮收集數(shù)據(jù)和對比結(jié)果，這就需要監(jiān)視信號組件和檢查組件的實現(xiàn)。監(jiān)視信號組件的主要任務(wù)是監(jiān)視設(shè)計的接口信號以及內(nèi)部信號，如果是總線接口，那么需要在解析總線的情況下將觀察到的數(shù)據(jù)打包處理，如果是其他控制或其他信號，也需要按照信號的定義，在特定的事件下捕捉有效信號。

????????監(jiān)視信號組件最終會將分析整理好的數(shù)據(jù)發(fā)送給檢查組件，由檢查組件進(jìn)行數(shù)據(jù)比較，給出比較信息和報告，最終判定測試是否成功。

????????

驗證的周期

1：芯片框架和模塊功能定義完成，指定驗證的策略。

2：模塊和子系統(tǒng)的功能信號定義完成，定制需要的存儲模型。

3：完成芯片系統(tǒng)的連線集成和驗證，覆蓋所有的功能驗證點。

GLS：完成門級網(wǎng)表的驗證。

Tape-O：回顧驗證的各項檢查清單，最終流片。

????????回歸測試指的是每次將所有測試用例提交到服務(wù)器上運(yùn)行，并且檢查測試結(jié)果。對于模塊級的回歸測試，這種方法在時間和計算資源上也許是可行的，然而對于芯片級，這種方式每次要消耗的時間和資源恐怕需要重新考慮。

回歸表：

提升回歸效率

????????在可實現(xiàn)的情況下，考慮切分測試場景，講一個場的測試序列切分為多個序列，并為之創(chuàng)建多個測試用例。這么做的好處是避免過于冗長復(fù)雜的測試，劃分為多個用例可以實現(xiàn)并行提交測試，用計算資源來節(jié)省時間。

????????而對于一些比較難切分的測試場景，例如芯片級仿真需要首先完成上電、復(fù)位、時鐘使能，同時芯片處理器需要完成初始化、搬運(yùn)執(zhí)行代碼的過程。我們可以考慮通過在完成上述操作之后的時間點比如500ns設(shè)置一個快照保存當(dāng)前的變量和狀態(tài)，在之后的仿真可以直接跳過前面的步驟直接到500ns，讀取快照接著仿真，這樣可以減少很多時間。

問題的追蹤