2010年2月28日

驗證是設計質量的保證方式，沒有一個設計不經過驗證就可以準確運行的。所以驗證本身該如何保證質量就顯得非常重要了。

整個驗證工作在形式上主要表現為兩方面：1，驗證點；2，驗證環境（包括測例）

驗證環境是驗證點的載體，是驗證點的具體實現。

對項目而言，還包括驗證的組織工作，驗證的組織者是否合格將決定真個項目的驗證工作是否能夠順利開展。

對驗證點而言，它的重點是完備性；

對驗證環境而言，它的重點是效率與準確性。

對驗證組織而言，它的重點是驗證計劃的掌控，包括驗證重點，盲點，瓶頸以及驗證進度的掌控。同時也包括人員上的組織與驗證成員心理的掌控。

1         保證驗證點的完備性

我們的芯片出現的問題往往是遺漏了某些驗證點的緣故。我們驗證中覆蓋到的地方極少有出問題的?？梢哉f驗證點是否完備是驗證質量保證的基礎。那我們該如何確保驗證點的完備呢？

2         首先從Spec出發，提取測試點

這種方式往往是從外部功能角度出發，比較少考慮內部結構：比如什么總線類型，支持什么協議等等。

這種方式的優點是容易把最重要的驗證點找出來，特別是對于系統功能很容易檢測。如果是純黒盒驗證的話，往往容易遺漏一些設計本身的驗證點，從而會使芯片遺漏bug。因為Spec的功能組合是非常多的，我們無法窮舉所有的功能組合。

例如：

為此我們還需要考慮：

從協議出發：

2         協議的理解容易偏差：
我們的芯片項目基本上都跟一些通用協議相關，像非接卡的14443協議，RFID的18000-6協議，一些接口協議像SD協議，USB協議等等。這些協議不是我們自己制定的，而且協議文檔也寫得參差不齊，這讓我們的理解容易跟實際有所偏差

1         多人討論：
協議的理解需要多人討論，一個協議至少需要兩人精通（設計者和驗證者）；

1         協議部分的設計和驗證需要從人員上分開：

協議本身的分析：

1         首先保證基本流程與基本功能：基本流程與基本功能一般已經包含協議的80%的功能了，這部分功能是容易把握的；但不容忽視，否則會差之毫厘，失之千里；

1          協議的邊界：這部分是驗證者需要嚴格把握的，絕不可疏漏。（這是我們2201之前沒做好的地方）；

哪些協議邊界需要注意的？

1         協議規定的最大值和最小值：需要跟設計者溝通，搞清楚實際的邊界；

1         特殊情況與特殊條件：比如RFID 18000-6中的Truncate功能就有很多特別的要求。

1         需要了解協議的應用場景：
協議的應用場景不僅是系統驗證的要求，對我們深刻理解協議也有幫助。如果我們不知道具體的應用場景，我們就沒有把握我們做的東西是否是符合協議的，是否是符合實際需要的。

2         設計自身的特點：

設計自身往往有很多小的結構組成的，如果這些基本結構正確，結構跟結構之間的連接又沒有錯的話，那他們所組成的無數的功能也就可以滿足。這部分是自驗證和交叉驗證的重點。

這部分的測試點首先需要由設計者本人詳細給出，然后由交叉驗證者單獨給出；最后經過交叉驗證者和設計者以及相關人員綜合討論后合并成一個總的測試點CheckList。
即最后設計者和交叉驗證者需要共同維護一個驗證點的CheckList；

從覆蓋率報告增加相關測試點：

2         覆蓋率包括需要在所有已知驗證點都跑完的情況下再看覆蓋率報告，即在整個驗證工作即將結束時再看，而不是驗證的中間；

1         驗證組織者一定要強調這一點：覆蓋率不是驗證的目的，而是防止驗證遺漏的一種手段；所以絕不可以為了讓覆蓋率通過而驗證，即絕不以說覆蓋率100%，驗證就沒有問題了。

2         覆蓋率報告可以讓我們想到一些遺漏的驗證點：所以對覆蓋率報告要重視，絕不可以放過任何的遺漏；

2         在所有驗證點列全后，我們還需要根據主要的功能，即主要的feature來對一些測試點加以組合；這種組合應該是定向的組合加受限隨機的組合；

1         對于保證測試點的完備性，有針對的小范圍討論是一種很好的補充方式，特別是設計者和交叉驗證者的討論。

1         對于交叉驗證者：需要了解主要的設計實現，最好在設計開始時就切入，從而對模塊的需求與實現由更深入的了解。

1         對驗證點列全后，我們需要對驗證點進行分析：搞清楚驗證點直接的關聯性，耦合性；相同的可以合并，以提高效率；

1         對于驗證有bug修改的地方的處理：需要考慮新的修改是否帶來新的驗證點；如果修改會影響其它功能，而現有驗證點又沒有覆蓋的，需要增加相應的驗證點和相關的驗證。

1         設計者需要考慮設計的可驗證性：設計者要為驗證者著想（設計者需要有驗證經驗），設計者需要降低組合的種類；要保證設計組合比較少，各部分的耦合性要低。

2         確保驗證環境的有效性

驗證環境是驗證點的實際載體，好的驗證環境能有效的保證驗證的質量，而差的驗證環境則會給人一種錯覺，表面上所有的測試點都驗證過了，但實際上由于驗證環境有錯誤或驗證環境不完善，而導致錯誤的設計也能通過這個驗證環境。

這點在我們之前的2201芯片中有過類似的情況：由于我們的驗證環境不完善，沒有有效的錯誤檢測機制，從而導致一些bug遺漏過去。

          那我們如何保證驗證環境的完備與有效呢？

3         要有完善的差錯檢測機制。

3         要有合適的debug機制

3         驗證環境輸出給DUT的接口信號需要有兼容性機制，即需要能夠根據協議要求調整信號質量，使得信號能在一定的范圍波動，甚至增加信號的毛刺等。
特別是對于芯片接口信號和數模接口信號，這些不靠性因素在實際中是真實存在的，所以一定要在功能仿真的時候盡量模仿真實環境。

1         要有合理的分層：

合理的隨機機制：

3         對待隨機測試的態度：
驗證者要清楚不是每種首先隨機都是有效的，所以，隨機測例要有很好的目的性。

3         隨機測例的目的是：
沒有想到的條件組合是否有問題，所以重點是沒有想到的，而不是想到，但為了偷懶而使用隨機測試。
如果想到的有效條件組合，就不能使用隨機測試。不管隨機性如何的好，都有可能沒有覆蓋到這種有效條件。（我們之前就碰到過這個問題）

3         在時間有限的情況下，要提高受限隨機的效率，沒有效果的隨機測試需要避免；

2         要有時間打印機制：
比如毫秒打印等。功能要可關閉（使用define即可）

2         要有準確報錯機制：
跑出錯誤需要指明錯誤case號；

需要合理的時間控制機制：

3         需要有最長時間的finish機制；（單獨起initial，#Time；$finish)；

3         出錯的時候不要立即finish，最后延時一段時間，這樣可以方便debug；

2         盡量少的拉probe：
對后方，混紡有好處。如果一定要有，需要可關閉；

1         要有異常檢測機制：
比如毛刺檢測等機制，特別是時鐘輸入信號；

Dump波形機制需要可靈活控制：

3         可以根據實際情況關閉；

3         可以做到在出錯的地方左右dump需要的波形，以減少仿真時間；

使用自動檢測機制取代看波形的方式：

3         盡快要使用合理的check機制來取代看波形來check是否正確。

要有合理的差錯處理機制：

3         錯誤則仿真停止機制要可關閉（可以使用自定義的Finish task來處理）；

3         異常打印的時候需要打印具體的仿真時間；

驗證環境的維護性：

3         驗證環境命名需要有統一的規范，包括信號，參數，

3         需要有說明文檔，說明共用的task使用方式，說明環境結構，參數說明等內容；

3         合理的parameter和define：把數據使用合理的字母定義數字；

1         要考慮驗證環境易用性；

1         SVA使用；

驗證組織：

3         驗證計劃：區分重點，掌控進度

3         驗證心理：不放過任何異常；驗證者需要具備嚴謹的工作作風

3         驗證組織者需要掌控重點，瓶頸，與盲點；

1         在驗證和設計分開的情況下，驗證者最好跟設計者同時準備，而不要等到設計完成后才開始準備驗證；這樣可以讓驗證者加深對設計的理解。

2         驗證者的思路需要獨立于設計者。

2         分子系統，同步進行，落實責任，各自保證，要有統籌規劃，統一Check；

2         要搞清楚那部分是重點，要把重點交給責任心強，能力強的人驗證；一個功能兩個子系統都覆蓋的情況下，則最好由責任心強的那個來負責。

1         站在產品應用的角度考慮問題；

2         盡早開始考慮軟件的驗證，固件人員需要在驗證階段參與。

1         讓驗證者按照自己的思路去驗證；

1         驗證組織者要清楚交叉的地方，要制定明確的責任人。

1         需要詳細記錄bug，包括自驗證和系統驗證；

2         驗證何時結束

驗證者需要清楚一個事實：

我們的驗證還沒有做完；我們現在覺得做完了，是因為有好多點我們還沒有想到。

我們之前做的任何驗證，現在來看都有許多疏漏的地方；只是有些疏漏沒有質量問題，因為設計做對了，不用驗證也是對的。有些疏漏由于設計沒做對，就形成了最后的bug；

那我們的驗證是不是沒完沒了了呢？

不是的，驗證者需要清楚，你想到的所有基本功能是否可靠的驗證了；所有主要的功能組合是否都沒問題了。

如果以上兩點能保證，那驗證階段可以基本結束，因為這時99%以上的功能已經能夠保證了，特別是所有重要功能都得到了保證；后續根據實際情況再補充。