本文**：
伴隨著隨機驗證的方式，遞迴（regression）驗證的方式變得更加有意義。一般來講，我們基於兩種目的來提交遞迴測試表：
通常而言的遞迴測試指的是每次將所有測試用例提交到伺服器上，檢查測試結果。對於模組級的遞迴測試，這種方法在時間和計算資源上也許是可行的，然而對於晶元級，這種方式每次要消耗的時間和資源恐怕需要重新考慮。在實際專案中，採取何種方式使用遞迴測試，需要考慮的是下面幾個因素：
遞迴流程
我們在驗證週期中，通常都是從模組級到子系統級再到晶元級，對於設計、整合和驗證都是這樣的步驟。那麼，採取瀑布整合的方式是否可以滿足目前快速的soc晶元週期呢？恐怕會很難。雖然我們之前將不同專案節點的內容列舉出來，但是實際的窘境是，由於緊張的節點安排，往往是「一波未平，一波又起」。例如我們本應該在rtl2之前完成模組級驗證工作，在rtl3完成晶元級驗證，但實際情況卻往往是在rtl2節點上，我們可能只完成了80%以上的驗證工作，而剩下的模組驗證工作需要和晶元驗證工作一同完成。一方面，作為驗證經理，需要頂著壓力，在rtl2結束以後，開展晶元驗證工作，另外一方面，他也需要同時追蹤各個模組的驗證進度。
所以，遞迴流程沒有一致的標準，更多的是去符合實際的專案情況，但同時又需要在節節落後的情況下要保證最終流片的按時完成。這看起來可能是一種同專案進度的妥協，但更多地需要驗證經理詳細清楚哪些任務是必要在節點前完成，哪些任務可以適當延遲，總體控制風險，這同走鋼絲一樣，平衡一詞始終需要牢記心間。
那麼，單獨拿出遞迴流程舉例，讓我們看看如何在快速的專案週期下，做出合理的遞迴流程吧。
那麼當以上流程中一旦出現了缺陷該怎麼辦呢？我們應該遵循的原則是：
遞迴質量
在軟體的迭代開發中，除了保證測試質量之外，也需要通過單元測試來保證設計在每次提交之後（版本更新或者缺陷修復）保證設計的自檢，使得在提交給測試人員之前可以保證基本功能通過，減少由於明顯設計錯誤帶來的設計與測試人員之間的溝通和時間消耗。而這種有效的方式，也被越來越廣泛地運用到晶元驗證過程中。
儘管晶元設計在每次完成後，無法通過整合開發環境簡單地通過乙個敲鍵就完成設計模組的單元測試，但是，我們仍然可以通過有效的遞迴測試工具將設計、驗證環境的編譯、**、結果檢查集成為一體，使得設計在完成以後，也可以通過一些簡單的命令由設計者首先檢視是否設計的基本功能是否正常工作，只有在保證這項基本功能遞迴列表完成以後，我們的版本管理工具才會允許設計文字的簽入，同時通知驗證人員設計的更新，由驗證人員直接展開其它高階功能或者更高層次的驗證工作。
在之前提到的如果驗證人員發現缺陷之後，設計人員首先完成缺陷修復並且通過基本功能測試之後再次遞交給驗證人員。那麼驗證人員需要做的是，檢查之前錯誤的場景是否可以通過，同時建立專門針對該缺陷的基本測試來更有目的地完成測試。在這些激勵確定性較明顯的測試完成之後，我們也會給出更寬鬆的激勵，產生更複雜的可能場景來對設計產生更豐富的測試場景。
通過隨機遞迴測試，我們可以在每次遞迴測試完成之後收集覆蓋率，分析一些功能點覆蓋漏洞，在下一次遞迴測試開始之前，有意地調整隨機約束，使得產生的激勵更有可能填補那些功能點漏洞。
除了隨機測試以外，我們也會通過形式驗證的方式來完成驗證。對此，我們提供的多種屬性檢查也可以分為基本功能屬性和高階功能屬性，這種簡單的分類也可以保證設計每次提交以後保證基本功能屬性，而高階功能屬性的驗證可以由驗證人員完成。同時，覆蓋率的收集，也可以從形式驗證中得到，並且和其它動態**的覆蓋率資料實現合併和分析。
隨機測試的遞迴序列如果要實現更高的覆蓋率，就需要執行多次，這種方式使得覆蓋率收斂曲線隨著遞迴往復的次數而提高，同時該方式也非常消耗運算資源和時間。所以關於通過遞迴方式來完善功能覆蓋率和檢查設計功能，我們建議將它們區別開來，比較合理的方式應該是：
遞迴效率
遞迴測試雖然是一種確保設計功能通過的穩妥手段，而且由於它方便管理操作，也可以用來提公升覆蓋率，但同時，追求驗證完備性的同時，遞迴測試的效率問題也變得越來越引起重視。遞迴效率的重要性基於以下幾個方面：
通過上面的考慮，我們在日常工作中，建議採取以下的辦法來提公升遞迴效率：
驗證的收斂
隨機驗證的方式使得回歸測試更加有意義。一般來說，基於兩種目的來提交回歸測試表 回歸測試指的是每次講所有測試用例提交到伺服器上執行，並且檢查測試結果。對於模組級的回歸測試，這種方法在時間和計算資源上也許是可行的，然而對於晶元級，這種方法每次要消耗的時間和資源會很大。在實際專案中進行回歸測試，需要考慮下...
驗證的管理篇之六 驗證師的培養
本文 我們在之前的 晶元驗證全視篇 中針對驗證師的 自我修養 提出了包括技術和專案在內的要素分析，從 一名驗證師的自我修養 一文可以發現驗證師需要得到各方面的鍛鍊。在這些因素背後，通過日常的觀察，我們可以發現優秀驗證師之間的共同能力。這些能力不完全是與生俱來，如果你願意下功夫，也可以在下面總結出的出...
驗證的管理篇之七 驗證的專業化
本文 人們對乙個行業所產生的偏見多半是由於沒有親身體驗過，而在晶元領域驗證所接收到的偏見也絲毫不少於其它行業所面臨的窘境。在每次新開學與我的學生們交流的時候，他們對於驗證的理解仍然停留在當初學習vhdl或者verilog所學到的通過乙個簡易包裝的測試盒子，固定的激勵源和細緻的時序激勵調整來測試設計。...