伴隨著隨機驗證的方式，遞迴（regression）驗證的方式變得更加有意義。一般來講，我們基於兩種目的來提交遞迴測試表：

• 由於隨機驗證環境每次模擬產生的激勵序列不同，這就使得每次模擬均會對覆蓋率產生貢獻，變得有意義。
• 當設計缺陷被發現以後，遞迴測試序列需要再次提交，用來確保之前的功能點測試無誤，同時設計缺陷也被修復。

通常而言的遞迴測試指的是每次將所有測試用例提交到伺服器上，檢查測試結果。對於模組級的遞迴測試，這種方法在時間和計算資源上也許是可行的，然而對於晶片級，這種方式每次要消耗的時間和資源恐怕需要重新考慮。在實際專案中，採取何種方式使用遞迴測試，需要考慮的是下面幾個因素：

• 遞迴流程
• 遞迴質量
• 遞迴效率

遞迴流程

我們在驗證週期中，通常都是從模組級到子系統級再到晶片級，對於設計、整合和驗證都是這樣的步驟。那麼，採取瀑布整合的方式是否可以滿足目前快速的SoC晶片週期呢？恐怕會很難。雖然我們之前將不同專案節點的內容列舉出來，但是實際的窘境是，由於緊張的節點安排，往往是“一波未平，一波又起”。例如我們本應該在RTL2之前完成模組級驗證工作，在RTL3完成晶片級驗證，但實際情況卻往往是在RTL2節點上，我們可能只完成了80%以上的驗證工作，而剩下的模組驗證工作需要和晶片驗證工作一同完成。一方面，作為驗證經理，需要頂著壓力，在RTL2結束以後，開展晶片驗證工作，另外一方面，他也需要同時追蹤各個模組的驗證進度。

所以，遞迴流程沒有一致的標準，更多的是去符合實際的專案情況，但同時又需要在節節落後的情況下要保證最終流片的按時完成。這看起來可能是一種同項目進度的妥協，但更多地需要驗證經理詳細清楚哪些任務是必要在節點前完成，哪些任務可以適當延遲，總體控制風險，這同走鋼絲一樣，平衡一詞始終需要牢記心間。

那麼，單獨拿出遞迴流程舉例，讓我們看看如何在快速的專案週期下，做出合理的遞迴流程吧。

• 首先在模組設計階段，除了需要需要準備驗證環境之外，需要在驗證的基本功能完備之時就建立一些基本測試用例，並形成一份基本功能遞迴列表。該列表在RTL2（模組週期）前必須全部通過。
• 同時，在保證基本功能遞迴列表時，一些高階、附加功能仍然需要儘可能多地在RTL2前完成驗證，但這些功能可能有部分需要在RTL2和RTL3之間完成驗證，所以按照優先順序劃分的高階功能遞迴列表也需要作為最終模組驗證完成的檢查項。
• 由於在RTL2節點時可以保證基本功能的正常工作，這一份遞迴測試表單也使得在RTL3開始時進行的晶片整合工作可以得到保證，在完成整合之後，各個模組之間的互動也能初步得到測試。此時，各個模組同其它模組的通話就依賴於這些基本功能的測試表單。
• 同時，在RTL2與RTL3之間，我們需要在完成模組級的高階功能驗證之後，進行反覆提交遞迴測試列表，通過大規模的隨機測試用來測試設計的穩定性，並且完成覆蓋率收集。
• 模組功能驗證必須在RTL3之前完成，而晶片級驗證則需要在門級模擬之前完成，並且儘可能減小落後於節點的差距，只有這樣才會留給後端小組穩定的設計（出現更少新的缺陷）來做物理實現，為門級模擬提供合理的物理實現時間。

那麼當以上流程中一旦出現了缺陷該怎麼辦呢？我們應該遵循的原則是：

• 選擇更小的驗證環境、給出更少的變數，實現更容易除錯的環境。具體而言，就是在晶片級遇到缺陷，如果可以在模組級驗證，那麼首先在模組級驗證；通過，如果可以固定其它變數，例如配置設計的功能為一些基本功能，減少負責功能配置，來重現錯誤場景，那麼這種方式也會更有利於錯誤定位、設計分析和缺陷修正。在缺陷完成修復以後，也可以在更小的驗證環境中，重複之前的測試，來確保出錯的場景通過。
• 在對缺陷完成修復之後，我們仍然需要先後進行模組級驗證和晶片級驗證的遞迴測試表，確保除了缺陷修復之後，還不會引入新的缺陷，所有之前測試通過的功能仍然可以保證正常工作。

遞迴質量

在軟體的迭代開發中，除了保證測試質量之外，也需要通過單元測試來保證設計在每次提交之後（版本更新或者缺陷修復）保證設計的自檢，使得在提交給測試人員之前可以保證基本功能通過，減少由於明顯設計錯誤帶來的設計與測試人員之間的溝通和時間消耗。而這種有效的方式，也被越來越廣泛地運用到晶片驗證過程中。

儘管晶片設計在每次完成後，無法通過整合開發環境簡單地通過一個敲鍵就完成設計模組的單元測試，但是，我們仍然可以通過有效的遞迴測試工具將設計、驗證環境的編譯、模擬、結果檢查整合為一體，使得設計在完成以後，也可以通過一些簡單的命令由設計者首先檢視是否設計的基本功能是否正常工作，只有在保證這項基本功能遞迴列表完成以後，我們的版本管理工具才會允許設計文字的簽入，同時通知驗證人員設計的更新，由驗證人員直接展開其它高階功能或者更高層次的驗證工作。

在之前提到的如果驗證人員發現缺陷之後，設計人員首先完成缺陷修復並且通過基本功能測試之後再次遞交給驗證人員。那麼驗證人員需要做的是，檢查之前錯誤的場景是否可以通過，同時建立專門針對該缺陷的基本測試來更有目的地完成測試。在這些激勵確定性較明顯的測試完成之後，我們也會給出更寬鬆的激勵，產生更復雜的可能場景來對設計產生更豐富的測試場景。

通過隨機遞迴測試，我們可以在每次遞迴測試完成之後收集覆蓋率，分析一些功能點覆蓋漏洞，在下一次遞迴測試開始之前，有意地調整隨機約束，使得產生的激勵更有可能填補那些功能點漏洞。

除了隨機測試以外，我們也會通過形式驗證的方式來完成驗證。對此，我們提供的多種屬性檢查也可以分為基本功能屬性和高階功能屬性，這種簡單的分類也可以保證設計每次提交以後保證基本功能屬性，而高階功能屬性的驗證可以由驗證人員完成。同時，覆蓋率的收集，也可以從形式驗證中得到，並且和其它動態模擬的覆蓋率資料實現合併和分析。

隨機測試的遞迴序列如果要實現更高的覆蓋率，就需要執行多次，這種方式使得覆蓋率收斂曲線隨著遞迴往復的次數而提高，同時該方式也非常消耗運算資源和時間。所以關於通過遞迴方式來完善功能覆蓋率和檢查設計功能，我們建議將它們區別開來，比較合理的方式應該是：

• 前期設計不穩定的情況下，主要定向提交一些測試用例來快速檢查功能是否通過。
• 在設計較穩定以後，可以規劃用時較短，測試場景較簡單的用例，來較快檢查核心功能點是否通過。
• 在設計後期，應該一方面設計複雜場景，另外一方面大量提交遞迴測試表來完善功能覆蓋率。

遞迴效率

遞迴測試雖然是一種確保設計功能通過的穩妥手段，而且由於它方便管理操作，也可以用來提升覆蓋率，但同時，追求驗證完備性的同時，遞迴測試的效率問題也變得越來越引起重視。遞迴效率的重要性基於以下幾個方面：

• 在模組驗證階段，隨機測試的方式使得傾向於反覆提交測試表用來產生各種可能場景，而到了後期，覆蓋率難以得到更多提升，那麼如何精細控制隨機約束，使得每次遞迴測試總有新增覆蓋率的收穫，這是要深入的問題。
• 在設計缺陷得到修復以後，如何快速檢查設計基本功能，保證設計版本提交的質量，進而轉移到驗證人員一側，提升溝通效率，這也需要設計合適的遞迴表。
• 在晶片級驗證階段，由於測試用例時間明顯加長，那麼每次遞迴整個測試表（ 數以千計）耗時極長，且由於晶片級測試更多基於C的驗證，在專案後期整合改動較少的情況下，反覆遞迴的收益就明顯降低，但同時驗證管理又需要這樣的資料，這種矛盾也需要化解。

通過上面的考慮，我們在日常工作中，建議採取以下的辦法來提升遞迴效率：

• 在可實現的情況下，可以考慮切分測試場景，將一個長的測試序列切分為多個序列併為之建立多個測試用例。這麼做的好處是避免過於冗長複雜的測試，劃分為多個用例可以實現並行提交測試，用計算空間來換取時間。
• 對於一些較難切分測試向量的場景，例如晶片級模擬需要首先完成上電、復位、時鐘使能的流程，同時晶片處理器需要完成初始化、搬運執行程式碼的過程，我們可以考慮通過快速跳轉到該狀態來實現縮短測試時間的要求。
• 對於一些需要通過長時間執行來跳轉到某一狀態的測試，我們建議可以分為兩個階段。第一階段來檢查，跳轉到該狀態的條件是否滿足，進而檢查狀態跳轉。一旦第一階段被驗證過，我們可以在第二階段後的用例，通過直接初始化到該特定狀態來節省時間，例如強行置位硬體暫存器、狀態位等方式，來使得設計可以快速條狀到某一狀態，進而縮短驗證時間。
• 儘可能給予充分的計算資源，目前用於模擬的普遍方式是，中心叢集化的伺服器來提供計算和資料儲存資源，通過資源分配管理辦法來實現儘可能足夠的並行運算資源，使得遞迴測試表可以儘快執行完畢。

至此，關於通過遞迴測試來合理收斂驗證程序的討論已完畢，智慧合理的遞迴測試方式有利於設計的釋出質量和快速穩定。下一節課，我們將帶大家一起看看，如果發現了漏洞，我們應該做哪些事情。