本文**：
目前主要的驗證方式包括動態**、形式驗證和硬體加速，那麼如何選擇它們，已經是否可以構建乙個可復用的驗證平台實現這些不同驗證方法的跨越是接下來我們需要關心的。隨著設計的尺寸和複雜度在不斷提高，即便有ip復用的方式來縮短設計時間，更多模組之間的互動可能性也要求更充分地去驗證這些狀態空間。目前**技術的瓶頸在於速度，隨著這幾年實際專案中的切身感受，**技術除了需要eda廠商提供加速方式以外，專案自身也需要結合實際情況使得**可以實現相對輕量化來保證可接受的速度。
形式驗證可以窮盡檢驗一些設計屬性。對於乙個合適尺寸的ip，它只需要通過一些時鐘週期就可以窮盡檢驗出設計屬性是否滿足。例如乙個32位的乘法器，如果通過動態驗證可能需要幾年的時間來窮舉出所有可能的情況來完全驗證，然而對於形式驗證而言，往往幾分鐘到數小時的時間就可以了。同時，形式驗證伴隨著設計的複雜度提高狀態空間指數增長的情況下，執行速度也急劇下降，ip是合適的形式驗證尺寸。
儘管在學術和工業領域，對於形式驗證的演算法研究非常活躍，它還需要解決的問題是，使用者對於形式驗證語言的不精通。因為使用者還需要保證設計屬性描述是精確反映實際設計的，同時屬性描述的總和可以對等乙個設計的所有功能，只有這兩點滿足了，才有足夠信心確信形式驗證的完備性。目前我們可以通過eda廠商提供的可復用的斷言庫來實現高層次的屬性描述，彌補我們對斷言描述本身的知識缺乏。此外，形式驗證讓我們「不那麼放心」的一點是，它無法像**一樣為我們提供乙個動態的行為，而驗證人員又需要「眼見為實」來親自判斷設計的實際行為是否正確。所以，如果採取形式驗證，建議的一種方式為以動態**為輔助手段，來完成基本的功能激勵和檢查。
硬體加速的歷史要更悠久，這可以回溯到1980中期到1990中後期，在rtl**還未推出被廣泛使用之前，佔據驗證市場的還是門級硬體模擬技術，隨著verilog和vhdl的語言推出和自動邏輯綜合技術的應用，rtl**就逐漸取代了硬體加速技術。這一技術更迭的背後，關鍵因素還是速度，因為那一時期的設計還不足以複雜到**器效能無法滿足的情況。20年後的今天，硬體加速技術顯然又有著收復失地的趨勢，三大主流工具商都提供各自的硬體加速解決方案。
硬體加速技術的速度優勢還是相當明顯的。動態**的效能平均保持在1khz，硬體模擬技術大致在1mhz左右，而fpga在10mhz左右。無論是硬體模擬還是fpga，都要比動態**技術的速度顯著提高不少，通過更快速的驗證技術，我們也才能夠抵消日益複雜的設計，和體量不斷增大的嵌入式軟體**測試。
那麼是不是硬體加速技術就是未來的主流呢？仍然不是絕對的。目前硬體加速技術也有自己的不足，比如：
編譯時間較長。這是因為硬體加速加速需要額外的邏輯綜合和硬體對映的時間，而綜合、布局、佈線和對映在動態**中是不需要的環節。
除錯手段少且慢。儘管最新的硬體加速技術可以實現記錄任何訊號、修改訊號或者等待訊號事件等常用的**除錯手段，然而由於技術限制，如果要新增或者修改新的訊號，仍然需要再次編譯消耗大量事件。此外，由於儲存的限制，我們也無法記錄所有層次的訊號，而只能有選擇性的記錄某些訊號在某一段時間內的行為。從除錯流程上來看，硬體加速技術仍然無法達到動態**的易除錯程度。
這麼看來，儘管在速度上硬體加速有顯著的優勢，但是從除錯層面，動態**和形式驗證也有其優點。那麼，實際中我們是怎麼結合這些技術的呢？一般我們傾向於以下方式：
在模組級或者ip級驗證中，更多使用動態**和形式驗證，盡量將缺陷率曲線更快更多地收斂在這一層次。
到了晶元系統級驗證中，我們傾向於使用動態**測試模組之間綜合的系統任務和整合關係。
對於耗時的測試用例，例如韌體啟動測試、效能測試、大規模資料儲存測試等我們會在系統測試階段使用硬體加速加速來更快得到結果。
從驗證平台搭建和復用的角度出發，我們也需要考慮，如何實現乙個可以橫跨這三種技術的可復用平台呢？通過乙個統一平台，如果可以自如地在這三種技術之間實現橫向跨越，以及完成從模組級到子系統級再到晶元級驗證的復用實現縱向復用，這將是接下來實現技術融合和驗證層次復用的方向。為討論這一方向，我們分別以下列問題展開敘述：
不同技術之間的驗證平台橫向跨越
不同層次之間的驗證平台縱向復用
技術之間的橫向跨越
在解決橫向跨越的問題之前，我們先需要理解為什麼有這樣的需求？從下面這張圖可以看到這三種技術之前有著共通的技術橋接，和一些核心的基礎技術：
那麼基於這些專案實際中的橋接，如何設計出可以合併的資料庫和通用的驗證平台就成為了關鍵。但對於這兩點，目前三大工具商還缺乏一種完整的解決方案。例如，驗證的覆蓋率資料庫如何在三種技術中實現互通和合併？如何定義出合理的結構完成形式驗證平台到動態**平台的復用？以及什麼樣的動態**平台才可以順利移植到硬體加速平台上呢？這些都是還有待思考解決的問題。
層次之間的縱向復用
在不同驗證層次之間的復用，我們也會遭遇到實際的痛點。例如，隨機約束的**方法（systemverilog，uvm/ovm或者specman/e）適合於模組級和子系統級驗證，而直接測試方法（c/c++）則適用於子系統級和晶元系統級的驗證過程。在這裡，我們看到了子系統級驗證有著兩種可能的驗證方法，我們需要考慮是否選擇其中一種，還是兩折兼具？如何實現模組級隨機測試到子系統級隨機測試的復用？如何實現子系統級直接測試到晶元系統級的直接測試復用？又譬如通過何種方式實現從隨機約束測試到直接測試的復用？因為只有完成了層次之間的縱向復用，我們驗證的是時間成本和人力成本才會降低，驗證效率才會進一步地提高。
面臨這目前這三種主流驗證技術，我們需要從驗證效率出發，只有通過合理地選擇使用這幾種技術，並且實現技術之間的橫向跨越和層次之間的縱向復用以後，我們才有可能在不斷提速的soc整合設計過程中也保持加速，與設計實現共同飛躍。
驗證的方法篇之六 效能驗證
本文 在pc時代，還少有人將處理器功耗提上驗證的日程，因為大家對於處理器效能的關注多於功耗的考慮。在十多年前，大家使用2g的功能手機，超長待機 一詞漸漸被作為主打廣告語進入了使用者的視線，這得益於硬體本身的低功耗 效能本身不要求太突出 和大容量的電池。而到了智慧型手機時代，伴隨著將桌面辦公和娛樂移動...
驗證的方法篇之七 效能驗證
本文 在邁過了效能驗證的坎以後，我們來到了效能 performance 驗證部分。顧名思義，在這部分驗證當中我們需要測試晶元的效能，而測試效能又離不開大量的運算或者資料傳輸。我們之前提到過，矽前rtl驗證的瓶頸之一在於 速度，而且一旦到了晶元級 這一因素就更進一步放大了。由於在產品定義過程中，對於系...
驗證的管理篇之六 驗證師的培養
本文 我們在之前的 晶元驗證全視篇 中針對驗證師的 自我修養 提出了包括技術和專案在內的要素分析，從 一名驗證師的自我修養 一文可以發現驗證師需要得到各方面的鍛鍊。在這些因素背後，通過日常的觀察，我們可以發現優秀驗證師之間的共同能力。這些能力不完全是與生俱來，如果你願意下功夫，也可以在下面總結出的出...