本文發散式分享幾個有效的bug發現手段或者驗證方法。

一、final chk

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

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

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

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

二、default test

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

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

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

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

審核編輯：湯梓紅