前面我們探討了接到驗證任務后的行動以及前期如何進行高效的學習，當有了對驗證對象的充分理解和學習之后，我們就可以進行驗證feature（即驗證的測試點）的提取了。

凡事預則立，不預則廢，眾所周知，驗證feature文檔決定驗證的內容、側重點、質量，是驗證工程師最重要的文檔和指導工具。

本文的側重點不在于大而全的探討諸如”不同類型的驗證對象哪些點可以作為驗證feature”等內容（以后在別的文章中有機會再討論），而是繼續遵循“高效”的主題，一起探討如何又快又好的梳理驗證測試點這個文檔？怎樣在驗證過程中充分使用這個文檔？

杰瑞IC驗證給出一種答案，圍繞一個口訣來作為今天探討的線索和綜述：

“先粗再細、先全再剃、不斷迭代、定期反思”

1

先粗再細

對于驗證feature來說什么叫粗？什么叫細？

我們舉個簡單的例子，如一條驗證feature可以這樣寫：

“需要覆蓋中斷功能的測試。”

也可以把這一條驗證feature細化成多條驗證feature，這樣寫：

“覆蓋不同中斷信號使能打開、關閉測試”

“覆蓋中斷正常清除測試”

“覆蓋延遲清除中斷測試”

“覆蓋不同中斷來源的中斷測試” “覆蓋中斷有效后相關中斷狀態寄存器正確性檢查” “覆蓋中斷不同來源同時有效的優先級測試”

“覆蓋多中斷次數測試場景”

……

當然，還可以寫的更細致：

例如上面“覆蓋不同中斷信號使能打開、關閉測試”可以繼續分解：

“覆蓋不同中斷信號隨機打開關閉以及不同信號間的交叉場景”

“覆蓋中斷信號使能全關閉，通過輪詢寄存器方式處理中斷場景”

……

例如“覆蓋延遲清除中斷測試”可以繼續分解：

“覆蓋延遲清中斷，延遲時間小范圍隨機”

“覆蓋延遲清中斷，延遲時間等到下一個中斷來之后再清除” ……

我們不再繼續細化贅述，相信大家從舉例中已經有點感覺了，什么叫“粗”，什么叫“細”，這里說到的粗細，其實就是指的是驗證feature的顆粒度。

杰瑞IC驗證認為，一個好的驗證feature文檔，一定是全面且顆粒度很細的文檔。只有顆粒度很細，借助這個驗證feature文檔才能更好的幫助你把需要覆蓋的測試點思考清楚，更好的衡量你的驗證工作量制定驗證計劃、更好的幫你構造定向或隨機case和編寫功能覆蓋率代碼、更好的保證你的驗證完備性。

可想而知，如果你只寫一句這么“博大精深”的驗證feature：“需要覆蓋中斷功能的測試。”，你看到這條驗證feature也許很難會想到還需要：“覆蓋延遲清中斷，延遲時間等到下一個中斷來之后再清除” 這種測試場景，這樣就有可能會埋下風險。

我們回到“高效戰斗”的主題，怎么又好又快的把這個文檔搞定呢？

從高效的角度杰瑞IC驗證建議一定要“先粗再細”。

一方面：

“粗”可以讓我們站在一個宏觀的角度，不漏掉大的功能點，例如先涵蓋各種需求點、各種設計文檔核心功能點、應用場景、性能點、功耗測試點、壓力測試點、注錯點等等

另一方面：

我們是不可能一蹴而就的。如果一開始就鉆進某一個點，把某個功能的所有細節驗證feature寫清楚再寫別的，效率顯然會低于先寫的粗一點，再多輪迭代進行細化。正如前面的舉例，每一次的細化都在上一輪細化的思考基礎之上進行的，這樣也會想的更清楚全面。

2

先全再剃

通過剛才講的先粗略提取再不斷細化的方式，相信大家可以高效提取出來一個比較全面的驗證feature文檔。

前面我們提到：“一個好的驗證feature文檔，一定是全面且顆粒度很細的文檔。”但是僅僅的全面和顆粒度小，就可以叫一個好的驗證feature文檔嗎？？

答案是否定的，全面和顆粒度小，只是提取驗證feature的第一步。如果說第一步細化是做加法，第二步更為重要和有難度，那就是做減法。就像本節的小標題“先全再剃”，這里的“剃”，講的就是“剃刀原則”的“剃”，關注的是驗證的執行層面，“剃”就是學會取舍，就是抓驗證重點和主要矛盾，就是高效的體現。

（1）“剃”，刪除掉不必要的驗證feature。

有時候，我們需要刪除和精簡一些沒有必要的驗證feature。

最簡單的例如，對于已經多次流片實踐驗證穩定的ip，沒有必要覆蓋非常細致的驗證feature，這部分完全可以舍去不驗證。

再舉一個例子：如針對某個參數我們通過確定邊界值、典型值、劃分等價類等方式進行驗證feature細化：

“A參數取值[0:1000]，需要覆蓋邊界值0，1000，典型值200、500、600、900……（例如100個），隨機覆蓋a模式[0:200)，b模式[200:700)，c模式[700:1000]”

“B參數取值[0:8880]，需要覆蓋邊界值0，8880，典型值200、500、600、900……（例如300個），隨機覆蓋a模式[0:1000)，b模式[1000:300)，c模式[3000:8880]”

……

這樣的參數有20個，然后有一條：

“需要覆蓋這20個參數取值的所有交叉場景”

這個“交叉場景”是很全面了（當然你如果想“修身養性”可以用一整天時間進一步具體細化出來怎么交叉的）。但是這條有意義嗎？

對于EDA仿真驗證來說，這條可以說是沒有意義的，因為這個需要覆蓋的驗證空間太大了，大到不能執行，即使你通過腳本交叉參數一鍵生成批量case，這么大的case量大概率不能在有限的時間跑完，就算能跑完，這樣的參數交叉測試是否真的有意義，是否在浪費測試時間？我們有這樣的時間，放在更重要的測試點上努力是否更有價值？

所以，對于這樣的驗證feature我們一定要做以權衡。是否可以通過深入分析實際應用場景和設計思路，精簡這些驗證feature，是不是哪些點可以刪除？是不是哪些點不需要交叉覆蓋？當然也可以思考是不是我們可以嘗試啟用形式驗證工具？

（2）“剃”，給驗證feature選擇一個更好的歸宿。

舉一個例子，有這樣一條驗證feature：“需要覆蓋連續不間斷運行10000次場景的壓力測試”。

這條驗證feature考慮的沒有問題，顆粒度很細，需求也很明確。但是對于EDA驗證來說，又是一個不可能完成的任務，這么一個case可能跑幾個月都結束不了。對于這樣的驗證feature，不需要從文檔中刪除，因為FPGA測試是可以辦到的，這種情況可以增加備注，指明在FPGA測試的時候進行覆蓋，并且負責跟蹤這個點是否在FPGA驗證計劃中列出以及測試時候是否確實落實。

同理，例如有的驗證feature可能不適合在單元級驗證時候測試，適合在更高層次的驗證階段中測試，都可以像上面的例子給驗證feature一個更好的測試“歸宿”，用最適合的方式覆蓋，從而提高項目總體的驗證效率。當然了，給驗證feature更好的歸宿前提是需要驗證者了解和把握驗證的不同驗證階段以及不同驗證層次的側重點和優劣勢，有一個驗證的全局觀念。

（3）“剃”，給驗證feature刮骨，設置不同的優先級。

有這么兩條驗證feature：

“需要覆蓋中斷功能的測試”

“覆蓋用于debug的狀態寄存器”

很明顯，第一個驗證feature是核心功能，第二條重要程度遠遠不如第一條。如果我們的驗證時間有限，那我們至少要通過完備的激勵和檢查機制保證第一條核心功能，而不是先編寫大量的checker去自動化檢查各種debug狀態寄存器。

也就是說，不同的驗證feature含金量和優先級也是不一樣的，我們在提取驗證feature的時候，要想清楚和標注不同驗證feature的優先級。

3

不斷迭代

驗證feature列表在驗證開始前就是寫好固定死了不能變的嗎？

不是的，驗證feature文檔是動態變化迭代的。

在正式驗證開展之前，我們會出一個當時認為最完善的版本，但是在驗證過程中我們還是要定期迭代我們的驗證feature文檔，例如：

當需求和設計的變更，我們需要相應的修改和增刪驗證feature；

當功能應用場景、典型參數增加或改變時，及時增加驗證feature；

性能功耗的場景驗證feature也可能常常需要修改文檔；

隨著驗證過程中對設計理解更加深入，也需要及時的記錄和補充細化驗證feature。

4

定期反思

驗證feature需要定期反思，有兩層含義，一方面是對已有驗證feature的不斷反思，其實類似于上面說的迭代，定期反思之前提取出的驗證feature是否合理或有缺少，這里不過多解釋；另一方面，是要利用好我們的驗證feature文檔，定期反思驗證進度和質量。

a. 依據我們的驗證feature列表和優先級等信息來制定我們的驗證計劃，并且不斷的修改更正我們的驗證計劃。

b.定期的把測試用例與驗證feature列表做一個對應和反標，心里清楚哪些驗證feature已經有case覆蓋住了，哪些還沒有，在驗證項目最后要保證所有驗證feature都有定向或隨機case可以對應。

c. 功能覆蓋率覆蓋點的規劃和收集工作，也需要定期利用驗證feature文檔進行規劃和反思，確定哪些點是一定需要寫功能覆蓋率收集代碼的，也是驗證完備性和質量的保證。

結語

今天我們用了一句口訣來回答“如何又快又好的梳理和利用驗證feature文檔？”

這個問題，即“先粗再細、先全再剃、不斷迭代、定期反思”。

驗證feature文檔的地位絕對是驗證過程中金字塔的頂端，篇幅有限，這其中很多的細節還希望各位進一步探索、感悟、交流～

審核編輯：劉清