本文發(fā)散式分享幾個有效的bug發(fā)現(xiàn)手段或者驗證方法。

一、final chk

final chk的思想是在執(zhí)行完成一個測試用例（或者一個簡單的命令）之后，然后查看下當前設(shè)計DUT的狀態(tài)。比如說一個cacheline，在完成一筆read/write之后，該cacheline應該是可以被替換（evict）的。

形象一點，當你在飯店吃完飯，座位資源應該是能夠被釋放掉的。

這種驗證方法就是驗證設(shè)計DUT的自我清除能力。一個很簡單的final chk方法就是在完成任何一個測試用例之后，可以隨機發(fā)送一些常規(guī)操作，可能有幸能夠發(fā)現(xiàn)這類問題。但是最完備，但可能粗暴的方法就是執(zhí)行完一個測試用例之后，用探針查看DUT的狀態(tài)和參考模型的狀態(tài)（所有寄存器和變量的值都是一個符合預期的值）。

時間足夠并且驗證人員了解DUT實現(xiàn)的情況下，個人傾向后者即使用最完備的方式檢查所有設(shè)計狀態(tài)。

二、default test

設(shè)計DUT中會存在很多的default:語句，看起來不是主要分支，但很多時候default分支也做了很多非常關(guān)鍵的事情，甚至default分支會比一些主要分支更加復雜和繁忙。

對于一個用戶，很多時候不做決定，傾向于留白，只會去配置自己會修改的寄存器配置。default test是指驗證人員做盡量少的實際工作，接受默認值，然后執(zhí)行一些操作。

“江湖不是打打殺殺,江湖是人情世故”。

很多時候，default test case fail，設(shè)計可能會說不符合實際約束，用戶應該怎樣怎樣~這個時候就涉及到驗證和設(shè)計的話語權(quán)問題了。從驗證的角度看，最好是default場景下，芯片是能夠work的。如果在正式發(fā)布的產(chǎn)品中，用戶不愿再配置而希望使用默認值，就非常令人尷尬。

審核編輯：湯梓紅