本文**：
在邁過了效能驗證的坎以後，我們來到了效能（performance）驗證部分。顧名思義，在這部分驗證當中我們需要測試晶元的效能，而測試效能又離不開大量的運算或者資料傳輸。我們之前提到過，矽前rtl驗證的瓶頸之一在於**速度，而且一旦到了晶元級**，這一因素就更進一步放大了。
由於在產品定義過程中，對於系統的運算和資料傳輸都有要求，如果可以在產品實現階段盡早地得出一些基本資料，從而為矽後測算出一些效能資料，那麼這不但可以幫助提前指明硬體實際效能是否滿足，在有時間的情況下對於可以調整的硬體設計還可以做出完善效能的修改，同時，這種將效能測試提前的方式也可以使得矽前驗證與矽後測試使用的效能測試用例保持一致，進而得出有幫助的效能資料。
效能驗證是用來衡量乙個系統在特定工作負載下它的響應能力和穩定性，同時通過效能報告也可以用來分析和優化系統的質量標準，例如可靠性和資源使用能力。效能驗證是一門實用的電腦科學工程方法，且在軟體工程測試中分類較多，譬如有負載測試（load testing）、壓力測試（stress testing）、浸泡測試（soak testing）、尖峰衝擊測試（spike testing）、配置測試（configuration testing） 、隔斷測試（isolation testing）等。
目前在矽前驗證階段，效能驗證還是乙個新穎的概念，一方面由於業界對這一測試還沒有形成一致的定義和驗收標準，另外也是由於效能驗證更多地是在衡量測試指標，而與驗證（判斷設計是否與功能描述一致）本身的聚焦不太重合。但是，對一些效能要求（同樣對於功耗要求）較嚴格的硬體設計，我們確實希望在更早期就得出一些資料，而且最好能夠趕得上給設計做出反饋並且完善設計，做更早期的回饋，以此來降低開發成本。所以，這就要求我們能夠自己先定義出矽前效能驗證的目標、環境和方法。
設定目標
目前我們主要將效能驗證主要側重在負載測試和壓力測試上面，來完成下面的目標：
在我們開始效能測試之前，應該首先問一問自己「為什麼我們要進行效能驗證？」，因為只有朝著明確的效能目標方向，才能得出下面的一些測試資料：
實際上我們很難在效能驗證計畫中具體描述出測試方式和場景，而效能驗證計畫又應該列在硬體設計之前。在實際專案中，我們不能很好地知道軟體使用硬體的場景，已經應用軟體如何排程不同硬體模組，所以我們只能首先將目光著眼於單個子系統的效能測試，或者通過測試單一的資料鏈路找到最薄弱的節點。因為上面這種方式可以將複雜的問題降維到可以理解可以描述測試場景的難度。
測試環境
理想地來看，如果測試環境貼近於使用者實際使用的情況，我們得出的資料會更加真實有意義，然而作為矽前硬體實現階段，我們與使用者的距離又何其遠。退而求其次，我們希望可以通過和韌體開發團隊合作，找到一些典型的子系統應用場景，在硬體**上實現來觀察子系統的效能。
同時為了將測試的成本降低，我們盡可能選擇原有的功能驗證的環境，通過動態的環境配置或者**開關來實現監視系統效能的元件。這些監視效能的元件可以分為：
線下分析（offline analysis）：將監視到的資料首先通過**記錄下來，通過線下的指令碼分析，繪製出效能的波動曲線。
驗證方法
從效能驗證流程來看，目前我們參照微軟的效能測試方法學流程，它包括以下步驟：
構建驗證環境：一般利用現有的功能驗證環境，通過更新使其可以完成效能檢測和分析的任務。
決定效能驗收標準：在測試之前首先限定反饋時間、吞吐量、資源利用率等驗收標準。一般而言，對於矽前測試，我們可以測出反饋時間和吞吐量，而資源利用率是乙個系統概念，較難測試。
制定計畫和測試用例：需要同系統人員、韌體人員一同列出重要的測試場景，同時建立可以衡量效能的**。
配置測試環境：如果環境足夠靈活，我們甚至可以在遞迴測試（regression test）中開關效能檢測功能，來平均衡量子系統的效能。
開發用例和測試：開發測試用例，提交和檢測帶驗模組，收集效能檢測資料。
分析結果、反饋和再測試：分析測試資料，提交效能報告，如果硬體效能與計畫的效能之間有缺口需要硬體做出修改。而後在此測試，直到硬體效能符合預期，滿足驗收標準方可結束。
正如前面提到的，實際專案中的效能測試除了不規範和較難實現意外，也缺少明確的驗收標準。這就使得不同驗證人員編寫的測試用例距離真實情況應用的差別不等，而且檢查效能的標準也各不相同。目前，我們通過下面一些形式來幫助實現效能驗證：
驗證的方法篇之六 效能驗證
本文 在pc時代，還少有人將處理器功耗提上驗證的日程，因為大家對於處理器效能的關注多於功耗的考慮。在十多年前，大家使用2g的功能手機，超長待機 一詞漸漸被作為主打廣告語進入了使用者的視線，這得益於硬體本身的低功耗 效能本身不要求太突出 和大容量的電池。而到了智慧型手機時代，伴隨著將桌面辦公和娛樂移動...
驗證的管理篇之七 驗證的專業化
本文 人們對乙個行業所產生的偏見多半是由於沒有親身體驗過，而在晶元領域驗證所接收到的偏見也絲毫不少於其它行業所面臨的窘境。在每次新開學與我的學生們交流的時候，他們對於驗證的理解仍然停留在當初學習vhdl或者verilog所學到的通過乙個簡易包裝的測試盒子，固定的激勵源和細緻的時序激勵調整來測試設計。...
驗證的方法篇之八 趨勢展望
本文 目前主要的驗證方式包括動態 形式驗證和硬體加速，那麼如何選擇它們，已經是否可以構建乙個可復用的驗證平台實現這些不同驗證方法的跨越是接下來我們需要關心的。隨著設計的尺寸和複雜度在不斷提高，即便有ip復用的方式來縮短設計時間，更多模組之間的互動可能性也要求更充分地去驗證這些狀態空間。目前 技術的瓶...