和大家聊聊IC芯片驗(yàn)證中的風(fēng)險(xiǎn)

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

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

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

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

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

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

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

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

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

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

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

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

審核編輯：劉清