無法拒絕Formal驗證的4個理由分別是什么

無法拒絕Formal驗證的4個理由分別是什么，相信很多沒有經驗的人對此束手無策，為此本文總結了問題出現的原因和解決方法，通過這篇文章希望你能解決這個問題。

在討論Formal驗證相比傳統動態仿真驗證的優勢之前，讓我們先確認一個共識：

動態仿真、硬件加速或者其他的一些驗證流程只能“證偽”，而不能“證明”。真正完備的驗證應該對設計進行嚴謹地數學分析，從原理上對進行證明。

后者就是我們所說的形式驗證（Formal Verification，FV）。（

Note0：這里的形式驗證，主要指的是模型驗證，而非大多數人所知的等價性驗證。

Note1：Formal也有很多缺點，所以現在Formal還不如動態仿真驗證普及。具體是哪些缺點需要各位自行體會了，Formal和動態仿真相結合才能發揮出驗證人員最大的潛力。

Formal驗證的優勢包括：

1.解決真正的驗證問題：對于面向實際工程問題的驗證人員，驗證方面的數學分析也許太過理論和不切合實際。但是如果你嘗試問下自己：我們究竟該如何驗證或者說保證設計的正確性？大多數人還是會說，理想情況只能在數學上驗證設計符合規格，而不是使用隨機激勵覆蓋那些人為提取的測試點。不幸的是，由于當前EDA工具的缺憾，我們還是主要采納后者的驗證方式。相信隨著工具的升級，我們會越來越多地采納形式驗證對RTL，甚至更High level的設計進行驗證，以降低在后期驗證發現BUG帶來的DEBUG成本。

2.完全覆蓋：覆蓋率（coverage）是指已經驗證通過的測試點占全部測試點的比例，本質上FV會提供完全的覆蓋（如果你的功能覆蓋率文件沒有寫錯的話）。這些需要覆蓋的測試點在動態仿真上我們可能需要進行等價，只收集其中的一部分，并且要花費數十倍于FV的時間成本。由于設計規模和工具算力的限制，對chip level進行Formal驗證幾乎是不可能的，但是在符合規格的輸入約束條件下，可以對某些關鍵模塊進行block level的Formal驗證，這相當于對該模塊進行“指數級”的動態仿真，能夠提高驗證的完備性和驗證交付信心。

3.設計行為最小示例：大多數FV引擎都能夠生成設計行為的最小示例。如果Formal驗證失敗，會展示出發生BUG的數個周期內的設計行為，但是在典型的隨機動態仿真環境中可能需要追溯到數千個周期前才能定位到問題所在（如果問題所在處沒有斷言），從而使得Formal驗證的調試和問題定位非常容易。

4.邊界（Corner）場景：在FV的引擎中，工具會遍歷用戶尚未禁止的所有場景，這意味著形式驗證能夠發現很多用戶都不會識別出來的邊界場景。而在動態仿真中，驗證工程師需要輸入有限的激勵，這會導致這些邊界場景無法得到完備的驗證，即發生漏測。究其根本，是因為動態仿真只指定有限的合理約束，而Formal驗證只需要驗證人員指定有限的錯誤約束。相比前者，后者更容易做到。

看完上述內容，你們掌握無法拒絕Formal驗證的4個理由分別是什么的方法了嗎？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊頻道，感謝各位的閱讀！