可能在貫穿到整個驗證系統思想裡面，我們都會不斷重複驗證人員該具備的素質。為了可以將抽象的詞彙具象出來，我們列出了驗證人員在驗證流程中需要具備的五個技術維度。接下來讓我分別解釋這五個維度：

• 完備性：該維度要求驗證的充分。無論你從專案經理、系統人員、設計人員還是驗證人員，大家談驗證首先提到的就是要“充分”。然而充分一詞對於驗證而言邊界時模糊的，很難量化到什麼時候才可以達到驗證的完成標準。所以，作為一名驗證經理，需要引入各種資料來綜合量化出驗證的進度，這其中包括了驗證功能點的覆蓋率，程式碼覆蓋率，是否經過了低功耗驗證流程（power aware verification），是否經過了跨時鐘域檢查等等。 通過資料量化，來對驗證人員和驗證經理增強足夠信心來宣佈某一個專案節點中，驗證已經得到了“充分”的驗證。當然，對於功能覆蓋率部分，如何將功能描述文件充分理解，進而充分列出要測試的功能點並儘可能地細分出來，這需要系統人員、設計人員和驗證人員的共同努力。同時，如何將抽象的驗證計劃轉換到功能覆蓋語言（SystemVerilog function coverage）需要驗證人員具備該能力。

• 複用性：從專案的實際運用角度來看，複用性和完備性是同等重要的。沒有人願意會在下一個專案中將以前的驗證環境做較大的更新，因為這意味著額外的資源消耗，包括時間、人力和專案進度的考慮。在硬體設計角度而言，通過標準匯流排協議，可以最大限度的講模組之間實現相對獨立和快速整合，所以對於目前專案進度不斷縮緊的現狀來看，一方面是市場的瞬息萬變導致的，一方面也是由於SoC自身逐漸趨向於軟體的快速週期迭代方式而成的。對於一個系列晶片而言，後續晶片的效能提高、功耗優化都是建立在前一代的基礎上的，而這些不斷地提高和優化具體到每一個硬體子系統而言，可能就是他們的儲存大小、時鐘快慢、動態電源開關、匯流排寬度、快取深度來綜合決定的，然而下一代硬體設計自身一般不會有第一代晶片的艱難歷程（否則它也就稱不上是系列晶片了）。 那麼從硬體設計的角度來看，這些更新如果不會在邏輯上面有大的變動，那麼帶來的工作量是可以估計的。而從驗證角度來看，我們也很自然地希望驗證的工作量也不需要太大——可是事實並不一定是這樣的。首先從晶片專案的整合性而言，設計人員相比較驗證人員，在同一功能模組的穩定性是更高的，那麼當一個驗證人員在嘗試閱讀和修改上一個專案的驗證程式碼時，就要看看他的運氣。一般來講，他的運氣會跟上一個驗證人員的程式碼風格有直接的關係……同時，驗證人員在處理一些匯流排協議的時候要有意識引入引數來為日後的複用做好準備。而不斷融合的驗證方法學，走到今天，UVM（Universal Verification Methodology）之所以劃分出不同的功能單元，實現小的顆粒度，提供快速插拔式的環境整合，也是為了複用性考慮的。

• 高效性：指的是用盡可能少的工作量來完成驗證工作。在保證驗證完備性的情況考慮下，實際上覆用性和高效性會有存在衝突的可能。例如，驗證人員會考慮如何“短平快”地在一個緊張週期內完成驗證工作，但可能他不會採用UVM等方法學框架，也有可能他不會考慮將引數引入到驗證環境中，因為這些“額外”的因素雖然是對複用性有幫助的，但是也會跟高效性有衝突。所以，驗證人員需要針對不同的情況來在上述的五種維度之間做好平衡，至少需要保持一種意識，那就是工程學的執行階段本身就是一種平衡，對於驗證人員來講，他需要作出的判斷就是在每一個專案每一項驗證任務中做好取捨，來給出一個合適的驗證考量維度。甚至對於同一項驗證任務而言，採取不同的驗證策略也會有不同的完成效果。例如，一開始考慮採用隨機約束的驗證方法，那麼單單就約束而言，它的約束一開始是比較窄合適，還是一開始比較寬寬合適？
  這裡我們再給出一張示意圖來說明高效性實際上在不同的驗證方法和同一個驗證任務在不同狀態時都需要有相應的變化。因為在開始階段，考慮到設計不夠完備而且尚未經歷過驗證，我們一開始的階段稱作基本功能驗證階段

  ，這個階段，我們會將隨機約束域降低到基本範圍，儘可能少的觸碰到邊界情況，而把重點放到如何先將各項基本功能都驗證到。第二個階段是在我們已經完成基本功能驗證以後開始的完備功能驗證，這時我們就可以逐漸放開隨機約束域，而開發的速度跟合適能夠設定最終的開放域範圍需要驗證人員充分考慮到各種合理的情形再做約束域的限定。而當了功能覆蓋率一般上升到80%附近的時候，這就處於了最後的爬坡階段，這個時候，如果再沿用之前廣泛的約束域，那麼會產生很多無效的隨機種子，這些“無效”的隨機種子基本對於剩下的驗證覆蓋率完善沒有什麼幫助，那麼這個時候驗證人員就需要通過理解設計本身和隨機產生的約束兩方面來考慮具體貢獻覆蓋率的測試序列，再進一步縮窄隨機約束域，來定向（biasing）產生一些激勵，對於最後的這一階段，一種極端的情況就是將隨機約束域縮到儘可能窄的情況，甚至和直接測試（directed test）沒有什麼區別。
  
   

• 高產出：指的是在一定的時間，可以除錯、報告、幫助修正出多少個設計缺陷，以及可以建立多麼完整的驗證環境。多年來數字硬體設計（RTL級別）的基礎並沒有發生太多變化，同時EDA廠商提供的自動化工具又進一步提供了便利，提高的設計本身的可靠性。但是這一情況卻並不適用於數字驗證，因為EDA工具目前仍然只能作為輔助手段，例如提供更多方便的除錯功能和介面，卻不能也隨之自動化幫助建立複雜的驗證環境。這也就不難解釋了2014年Wilson在功能驗證領域的調查資料顯示，今天在設計和驗證領域面臨著最大的挑戰之一就是為快速的晶片產品和員工數量增長之間找到一個平衡點， 實現單位產出的提高。

• 程式碼效能：關於這一點要講詳細一點，需要專門開個話題。程式碼效能似乎也跟高效高產出有衝突的地方，因為對於驗證程式碼的整潔性、複用性甚至一點點地美感都對於數字意義上的驗證完備性沒有直接聯絡，這也包括你的驗證經理可能有好長時間都不會注意到你寫的驗證程式碼，除非有一天你驗證的那個設計出了一個缺陷，而且是一個顯而易見的缺陷卻沒有被發現，這可能才會引起驗證經理的注意專門來訪問可能是一團糟的程式碼結構。 但是每一位驗證人員也需要記住一句臺詞“出來混遲早是要還的”，無論是你在看著別人寫的驗證程式碼沒有註釋、沒有縮排、超長if-else判斷語句等等這些讓你已經無力吐槽是時刻，還是你因為專案緊張快速搭建驗證環境和編寫測試用例的時候沒有考慮到“後來閱讀者”和“你後來閱讀”而偷的各種懶，相信我，時間會讓你為此買單的。所以，作為一名驗證人員，請在你寫每一行程式碼的時候把它當做你日後行業名聲的榮譽牆，儘管你還在迫於專案的壓力快速建立環境疲於完成驗證，但等到你有閒的時候會去再改善那些程式碼嗎？不要再相信這些鬼話了，現在就去做吧！

從上面的五個維度來看，做一名合格的驗證人員實屬不易，更不要說考慮到每一個專案每一項驗證任務來分別針對制定出合適的五個維度指數。雖然專案執行沒有盡善盡美，但是針對驗證人員自身，如果可以意識到這五個維度的存在，並且能夠在實際工作中都照顧到它們，運用到驗證任務的考量當中，那你就是有意識地在培養自己成為一名驗證師了。