第一個，spec 理解錯誤。這個問題比較致命。有些bug是designer理解錯了spec導致的，然后dv也理解錯了，最終導致bug沒有驗證出來。另外一類是designer 理解正確但是寫code引入了bug，dv理解錯了spec，認為bug正常，從而導致bug沒有修掉。

第二個，testplan沒有列全。dv的后續驗證行為都是根據testplan進行執行，很多時期bug沒有驗到是因為testplan沒有列全。如何保證testplan的完備性？找designer 一起review不失一種很好的辦法。

第三個，驗證環境的架構不合理，這包括scoreboard 檢查數據的機制不全，monitor到的信號不全，driver輸出的激勵局限性，random的數據可能局限性等等問題。從而導致漏驗一些場景。

第四個，盲目相信code coverage。很多dv認為code coverage 收全design就大概率沒有問題。實際上在我們的設計中很多時序問題靠code coverage是沒法發現的。如果我們的function coverage也沒有寫全，此類問題很容易漏掉。

第五個，假pass，從而導致該驗證的沒有驗證到。這類問題表現在驗證環境可能有bug，自己沒發現，或是 第三條提到的驗證架構的局限性，導致bug沒有驗證到。

第六個，忽視了log中的warning或者是violation，導致一些有問題的design被放任不管，從而導致流片風險。

第七個，實際應用的場景沒有驗證到，驗證的場景實際不會用到，這表現在寫test的時候沒有考慮軟件的應用情況，比如某模塊在實際應用中會被頻繁調用實現某一算法，但是在驗證的時候只考慮了單一場景，從而忽視在實際應用中可能存在的問題。

第八個，關注了模塊功能，沒關注模塊性能，從而導致功能上沒有bug，但是性能上有bug。

第九個，芯片驗證中漏掉重要的檢查，比如寄存器屬性，reset值，模塊 reset行為等等。從而導致bug漏掉。

第十個，芯片驗證的文檔缺失，bug管理缺失，導致有些bug雖然已經發現，但是沒有提醒designer修掉，從而導致流片風險。

第十一個，一些驗證人員關注RTL驗證，但是在gate leverl simulation 和 power simulation 中缺乏經驗，沒有做全，導致一些時序bug 和功耗問題漏驗。

除了上面十一條，在我們的驗證工作中還有很多風險。如何做好驗證，除了驗證工程師自身的因素以外，還需要一套完善的驗證流程。

審核編輯：劉清