下圖顯示了功能驗證流程： 這個驗證過程可以被分解成三個主要階段： 制定驗證策略和驗證計劃； 創建驗證平臺， 運行和調試； 覆蓋率分析和迴歸測試；
１ 制定驗證策略和驗證計劃階段
制定驗證策略和驗證計劃階段主要處理以下三個問題：
（１） 主要功能點和測試用例
當前， 複雜設計的測試空間是非常大的。 一個典型的百萬門的設計可能有百萬乃至上億個需要測試的功能點， 將測試空間縮小到一個可以管理的範圍， 或者說是一個有實際意義的集合並且沒有損害其期望的功能， 這是第一步。 針對這些功能點， 我們將根據具體情況擬定驗證策略和測試用例， 最後具體化到一個詳細的、 可執行的驗證計劃中， 作爲整個驗證工作的指導；
（２） 驗證平臺的抽象層次
驗證平臺的抽象層次將決定它主要的處理對象： 比特、 包或者更高層次的數據類型；高層次的抽象建模可以讓驗證平臺中低層次的功能自動化；
例如， 一個以太網的驗證平臺運行在比特的抽象層次中， 則要求驗證工程師手工創建一個一個的數據包， 從而組成一個測試用例。 然而， 若相同的驗證平臺在更高的層次上建模， 例如包這個層次， 它就能夠自動的生成和注入數據包， 而不需要驗證人員去手工的創建每一個數據包。 這個方法將極大地減少創建測試用例的時間， 從而獲取更高的測試覆蓋率。 這將大大解放驗證工程師， 使之可以專注在一些很難查找的邊界情況 （ conner-case）上面。 提高驗證平臺的抽象層次， 也使得創建測試用例和檢查結果更加容易；
（３） 激勵生成和結果檢查原則
這些原則定義了輸入到驗證平臺的激勵是如何提供的， 結果是如何檢查的， 並判斷測試是通過還是失敗
２ 驗證平臺搭建階段
這是第二個階段， 也就是驗證平臺的搭建， 書寫測試用例和調試階段。 在這個階段，書寫驗證平臺代碼和測試用例。 驗證平臺持續被擴展， 因爲測試用例不斷被添加進來。 其中， 驗證平臺的搭建要以可重用爲基本原則， 而且能夠方便設計工程師和驗證工程師添加測試用例；
３ 迴歸測試和覆蓋率收斂階段
一旦幾乎全部測試用例被成功運行， 驗證就進入了迴歸測試 （ regression test） 和覆蓋率收斂階段。 迴歸測試要求能夠週期的批處理運行， 二是激勵必須能夠容易得到重現， 成功或者失敗能夠自動檢查。 覆蓋率顯示出該設計被測試的程度， 是驗證收斂的重要標準；
一般會出現下面幾種情況：
（1）code coverage 高 functional coverage 高 理想情況
（2）code coverage 高 functional coverage 低 需要進行更多的仿真或者修改testbench
（3）code coverage 低 functional coverage 高 可能錯過了某些覆蓋點
（4）code coverage 低 functional coverage 低 需要進行更多的仿真或者修改testbench
驗證技術和驗證方法學
本節將介紹三種常用驗證手段： 白盒、 黑盒和灰盒驗證； 三種主要的驗證技術： 形式驗證、 仿真驗證和硬件加速驗證； 三種重要的驗證方法學： 隨機激勵生成、 斷言驗證和覆蓋率驅動驗證；
黑盒、 白盒與灰盒驗證
功能驗證的最終目標是驗證一個設計是否能夠像預期的那樣工作。 然而， 並非在設計中的任何一個設計缺陷都能通過激勵在其輸出邊界上被檢測到， 爲此可能會被遺漏。 這樣的錯誤可能包括下列幾種情況：
１） 從來沒有被激發過的錯誤；
２） 被激發的錯誤沒有被傳遞出來；
３） 多個潛在的錯誤掩蓋了其他錯誤；
１ 黑盒驗證
黑盒驗證 指的是只通過其邊界信號來驗證一個模塊或者設計的功能。 黑盒驗證的一般的架構如圖所示， 通過這種方法， 激勵可以被應用到設計和參考模型中； 在某個抽象層次 （例如事務級、 指令級、 時鐘週期級等）， 通過被測設計和參考模型的輸出被校對。黑盒驗證存在下列主要的缺點：
１） 很難驗證和設計相關的特點
２） 很難調試
３） 要求一個精確的參考模型
同一個設計規範， 不可能所有的實現都做得等價。 每一個實現都包含了很多和設計相關的細節， 以達到性能或者效率上的差異， 這是每個設計之間最大的區別 （ 例如fifo的讀寫閾值設定或者總線仲裁器的算法） 。 這都是通過黑盒驗證方法很 難 驗 證 的 具 體實現。
另外一個難題是， 是否使用黑盒驗證取決於被測的複雜度。 黑盒驗證需要通過多個時鐘週期才能查看到傳遞到外部引腳上的內部錯誤。 爲此， 要求更長的仿真時間來傳遞這個錯誤； 即使這個錯誤在輸出到外部檢測到， 也很難追溯這個問題的根源。
採用黑盒驗證還有一個難題， 在某種程度上要求有一個參考模型能夠足夠精確得可以檢測所有的內部錯誤。 對於這樣一個模型， 未必存在或者很難做得像設計那樣， 爲此不可能完全依靠這種驗證方法；
２ 白盒驗證
白盒驗證 和灰盒驗證 提供了另外一個途徑來解決黑盒驗證的侷限性。 在白盒驗證中， 可以不需要參考模型， 因爲可以通過在設計內部或者外部輸出信號放置監控器和斷言來保證設計操作的正確性。
３ 灰盒驗證
灰盒驗證是一個綜合了白盒和灰盒的一個手段， 也就是在設計內部添加監控器和斷言來減少對參考模型的精確要求， 在錯誤發現的時候也減少調試的壓力；
驗證存在的挑戰
功能驗證是芯片設計流程中的一個挑戰。 隨着設計規模的變大和複雜性的提高， 上市時間的縮短， 這都意味着驗證工程師要在更短的時間內驗證一個更大， 更復雜的設計。 一個有效的驗證方案必須解決以下挑戰， 來達到驗證收斂；
（１） 完備性
驗證完備性的挑戰， 就是如何最大限度地驗證被測設計的行爲。 難點在於如何獲取所有必須被驗證的場景。 這是手工操作的過程， 可能存在錯誤而且冗長。 在這個領域， 最重要的進步是採用覆蓋率驅動的驗證方法學。 覆蓋率驅動驗證方法學要求制定一個可以數量化衡量完備性， 可追蹤， 有組織的驗證計劃。 這對於驗證計劃的嚴格要求可以暴露出可能被遺漏的相關場景。
（２） 可重用性
驗證可重用性的挑戰是如何優化驗證環境的架構， 使之可以在不同的場合重用 （下一個版本的項目或者同一個版本的不同層次或者一個類似的項目）。 重用可以通過以下幾種方式來實現： 模塊化驗證組件、 採用標準的接口、 將激勵產生機制和驗證架構分離等； 一個項目中， 深層次的重用就是如何實現一個驗證平臺可以供多個測試用例使用。 當然， 驗證平臺的重用的程度取決於驗證工程師投入多少人力和時間去規劃和優化， 其中也要折中考慮到項目的進程和投入回報。
（３） 可靠性
驗證可靠性的挑戰在於如何減少在完成一個驗證項目中的手工操作。 很明顯， 手工操作可能存在錯誤、 冗長和耗時很大。 相反， 自動化系統可以在更短的時間內完成更多的工作。 然而， 自動化系統必須通過手動搭建。 爲此， 在可靠性上的改進必須細心分析在搭建自動化系統上的投入和該系統的可靠性。 約束隨機驗證是一個很好的方法， 通過搭建一個自動化的系統來產生激勵和自動比較， 進而提高驗證的可靠性。
（４） 效率
效率就是如何在給定的時間內使對驗證工作投入的產出最大化 （例如， 調試失敗場景的個數、 驗證環境模塊的實現等）。 提高驗證效率已成爲功能驗證中的最重要的挑戰。 在設計流程中， 重用等技術已經給予了設計工程師更高的效率。 驗證效率的提高已遠落後於設計方面， 這使得功能驗證成爲了完成一個項目中的瓶頸。 高效的功能驗證要求消除在設計和驗證之間的這個鴻溝。 提高驗證效率可以通過提高驗證平臺的抽象層次和採用重用的。
（５） 性能
驗證程序性能上的挑戰就是如何最大化驗證程序的效率。 消耗在一個驗證項目上的時間主要是由驗證工程師投入的人工來決定的， 爲此， 在設計和搭建驗證環境中驗證程序性能是第二個要考慮的因素。 在運行迴歸測試的時候， 迭代週期主要爲驗證平臺運作的有效性來決定， 驗證程序的性能成爲這個階段的主要因素。 對專業工具和語言的掌握是實現一個驗證環境和改善驗證性能的必要條件。
驗證方法學
驗證一個設計需要回答兩個問題： “ does it work？” （ ＤＵＴ 能夠正常工作麼？） （在驗證計劃中可以分解成： 測試什麼功能點？ 怎麼測？ 最後功能對不對？） 和 “ are we done？” （我們做完了麼？）。 第一個問題屬於最基本的驗證概念， 也就是說設計能否符合設計者的意圖；第二個問題就是問我們的驗證是否充分和完備， 驗證是否達到收斂。 我們可以通過這兩個問題來揭示整個設計和驗證的流程:
