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

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

第三個，驗證環(huán)境的架構(gòu)不合理，這包括scoreboard 檢查數(shù)據(jù)的機制不全，monitor到的信號不全，driver輸出的激勵局限性，random的數(shù)據(jù)可能局限性等等問題。從而導(dǎo)致漏驗一些場景。

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

第五個，假pass，從而導(dǎo)致該驗證的沒有驗證到。這類問題表現(xiàn)在驗證環(huán)境可能有bug，自己沒發(fā)現(xiàn)，或是 第三條提到的驗證架構(gòu)的局限性，導(dǎo)致bug沒有驗證到。

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

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

第八個，關(guān)注了模塊功能，沒關(guān)注模塊性能，從而導(dǎo)致功能上沒有bug，但是性能上有bug。

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

第十個，芯片驗證的文檔缺失，bug管理缺失，導(dǎo)致有些bug雖然已經(jīng)發(fā)現(xiàn)，但是沒有提醒designer修掉，從而導(dǎo)致流片風(fēng)險。

第十一個，一些驗證人員關(guān)注RTL驗證，但是在gate leverl simulation 和 power simulation 中缺乏經(jīng)驗，沒有做全，導(dǎo)致一些時序bug 和功耗問題漏驗。

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

審核編輯：劉清