隨著SoC設計中采用的技術愈加復雜，驗證工程師的規劃過程也需不斷改進。基于測試的歸劃正在被更復雜的跟蹤覆蓋和斷言的驗證規劃所替代。引起這種變化的原因之一是支持功能覆蓋點、斷言和測試平臺約束規范的SystemVerilog在業界的普及，而另一個重要的原因則是越來越多的約束隨機測試平臺代替手工編寫測試。
       傳統的驗證過程需要識別設計中的所有重要特性，定義一整套驗證這些特性的直接測試，以及手工編寫測試，并在仿真環境中運行和調試這些測試。這種方法適合小型設計，但SoC器件需要上千個手工編寫的直接測試才能完成所有特性的驗證。租用限制、上市壓力和編寫測試的繁復單調都迫切需要一種更好的方法。約束隨機測試平臺要求驗證小組規定出用于定義設計輸入規則的約束條件。
       一旦這些設置工作完成后，測試平臺自動化工具或仿真器就能產生輸入激勵來驗證設計。通過改變約束條件、選擇不同隨機種子或偏置輸入產生的值，都可能引起所生成的測試發生變化。SystemVerilog可提供定義約束、種子和偏置所必需的結構。
       從直接測試發展到約束隨機測試要求驗證規劃過程也有相應的變化。傳統測試規劃包括設計的特性列表、驗證每個特性的測試和測試狀態。隨著測試的編寫、運行和調試，它們的狀態將在驗證規劃中不斷更新。這些規劃可以用文檔或電子表格的形式進行手工維護，也可以作為驗證過程自動化(VPA)流程的一部分實現自動更新。
       直接測試主要用于驗證設計的特殊部分，而約束隨機測試可以同時驗證設計的許多部分。這就形成了很大的挑戰，因為在特性和測試之間不再有明顯的分界線。
       對驗證小組來說匹配自動測試與相應設計特性的方法是通過功能覆蓋指標規定。設計師和驗證工程師能規定代表重要設計行為的功能覆蓋點。這些點中有一些代表了正常操作，而其它點反映了無法覆蓋的功能點條件，此處可能潛伏缺陷。隨著重點從跟蹤測試向跟蹤功能覆蓋轉移，傳統測試規劃必須加以改進。
       在現代驗證規劃中，特性被更精確地定義，以便在每個特性和功能覆蓋點之間呈現一一對應關系。隨著驗證的不斷進展，規劃可以作為VPA流程的一部分而獲得自動更新。
       SystemVerilog提供了兩種定義功能覆蓋的基本機制。種是源自硬件驗證語言的覆蓋組(cover group)。覆蓋組可包含多個單獨的覆蓋點，允許“儲藏”多個值，支持交叉覆蓋以便跟蹤組合值。由于一些RTL工具不支持覆蓋組，因此覆蓋組經常在測試平臺中被定義。
       另外一種機制是可以在設計或測試平臺中規定的覆蓋屬性(cover properties)。覆蓋屬性結構是SystemVerilog Assertions(SVA)子集的一部分，與斷言規范共享臨時序列和其它構造模塊。覆蓋組和覆蓋屬性指標可以在仿真器中進行收集和報告。一些允許SVA斷言的形式工具也支持覆蓋屬性。現代驗證規劃也可以用來跟蹤設計和測試平臺中規定的SystemVerilog斷言。
       在項目早期，特性是在驗證規劃中確定的。增加了針對覆蓋點和斷言的文本描述。隨著覆蓋點和斷言被加進設計和測試平臺，鏈接將被增加進規劃。根據規劃報告覆蓋結果(覆蓋或未覆蓋)和斷言結果(通過或失敗)。
       約束隨機測試平臺、功能覆蓋和斷言的采納可無縫匹配SystemVerilog的采納。隨著驗證規劃過程從簡單測試規劃發展成VPA驅動的驗證規劃，這些技術的價值也進一步得到了增強。下一步SoC驗證改善所需的所有工具和方法目前都已具備。