驗證演算法模塊時，如果數據很大，如果做到充分驗證？不可能每個可能數據都要驗證過吧？

01-15

謝邀，好問題。假設你的演算法是硬體實現的，首先，你這個演算法肯定是理論正確的，否則就是理論的問題，要從理論是怎麼推導出來找問題。所以你要做的，就是驗證這個硬體模塊是正確的，完全實現了你的演算法意圖。

有個學問叫測試矢量壓縮，只驗證一個子集而得到100%的功能覆蓋率。打個比方，你要驗證一個32 bitALU的功能，不可能把所有的數字組合都做一遍加減乘除運算，然後才認為正確吧，這會浪費大量的時間，至少加法和減法是重合的，驗證一個就可以了。理想的情況，你只需要驗證一個子集，比如300組，但是要保證這300組運算可以讓所有的硬體代碼都被執行過。

要操作這個，有兩個問題：

（1）怎麼確認達到了100%的覆蓋率。

這個可以有tool來支持代碼覆蓋率的檢測。你在模擬的時候，硬體代碼被執行的語句會被記錄下來，然後報告給你一個覆蓋率。如果還有沒測試到的部分，就要修改測試輸入，讓其覆蓋到。至少要保證所有的硬體結構都工作過，而且得到了正確的結果。為了得到較好的覆蓋率，一般要對輸入進行隨機化，這樣每次驗證的輸入都是不一樣的，然後讓tool來統計。隨機測試到了後期，可能會發現有一些硬體部件無論如何就是覆蓋不到，這個時候就要手動寫一些定向測試矢量，讓其覆蓋到。但是這本質上仍然是種窮舉法，要想減少工作量，希望以更少的測試輸入得到100%的覆蓋率，那麼需要（2）。

（2）找到這個子集。

一般在硬體的DFT測試以及BIST測試的設計中，都會有對應的測試矢量壓縮演算法，當然這種技術是專門為了檢測硬體製造問題的。比如memory BIST測試中，普遍使用March演算法，對於存儲器，只需要寫入很少的幾個值然後讀出來，就可以確定這個memory是不是有製造缺陷（比如有的bit被tie成0/1了，無法寫入新值），不需要把所有的組合可能都寫進去然後讀出來才能驗證。這個很複雜，跟具體的案例有關。

而且你必須首先對錯誤的可能進行建模，然後有針對性的建模，將這幾種可能出錯的情形進行驗證。比如加法器你認為自己的模塊有可能有溢出出錯，那麼就要設計一個test case，檢測沒有沒有溢出問題，如果這個case通過了，基本上也不需要更多的case重複驗證。這種針對性的設計，前提當然是你知道可能存在這種錯誤。

所以，找到這種子集的前提必須是你知道這個模塊可能存在哪些問題，然後定向排除，如果不知道，那麼還是窮舉吧。