驗證的策略篇之二：驗證的層次
從系統定義階段開始，我們就會將芯片系統劃分為子系統，進而又為每個子系統劃分為不同的功能模塊，直到劃分為復雜度合適的模塊。而到了設計階段，我們又會按照自底向上的方式開始做硬件設計和集成。從定義階段到設計階段再到后端部分，我們整個硅前的流程都是將芯片按照層次劃分的，一般我們稱之為芯片系統級（chip level/system level）、子系統級（sub-system level）和模塊級（module level/unit level），這種層次劃分的方式對于芯片的好處有哪些呢？
便于拆解功能模塊，實現人員的并行工作協同，這一點是從項目執行效率出發的。
對于系統定義而言，這是從主要的功能、性能要求量化為系統不同模塊定義的方法。
從設計和驗證角度出發，合適的復雜度模塊也有助于估計合適的工作量和人員分配。設計最終是通過模塊化來集成的，而驗證的環境在模塊化以后，也可以方便在更高級的驗證環境中復用。
對于后端，在進行了合理的區域劃分后，模塊和SoC可以并行進行后續的物理設計流程，在每個設計階段再合成進行相關電源設計、時序分析等設計項檢查。基于模塊化的設計最終再進行SoC級別的設計檢查并通過流片要求。
如果我們是在為一款手機設計通訊芯片，那么如圖顯示，一開始系統定義階段可能要規劃出來這么多的功能模塊，而且還需要考慮模塊的性能因素。每一款芯片都會包括多個子系統，而每個系統也會包含多個功能模塊，從舉的這款手機通訊芯片來看，他包括的功能子系統有：
處理器子系統
協處理器系統
本地存儲系統
外部存儲控制器系統
數據接口系統
系統模塊外設
多媒體子系統
調制解調子系統
對于核心模塊調制解調子系統來看，其中的2G/3G/4G又因為自身的復雜性依次提高，可以進一步作為獨立的子系統來對待，進而細分下去。所以，如何劃分層次，我們一般會從如下幾個角度考慮：
系統的復雜性：如果該系統相對獨立，那么它自身有作為子系統的條件。如果它本身任然過于復雜，可以進一步細分。
芯片集成的便利性：對于頂層芯片繼承而言，應該一個合適子系統應該與外界應該有清晰的功能邊界，例如系統信號邊界、標準總線邊界、與其它子系統交互的邊界，同時這些信號邊界也盡可能保持穩定和精簡，這是從頂層集成的工作量和后端布局布線的角度出發的。
驗證的階段：驗證人員需要清楚哪些功能點在模塊級驗證、哪些屬于子系統和芯片系統、是否有必要在不同級別重復驗證、最終各個層次是否會保證驗證完備性。
后端的流程：如果一個子系統占到了芯片整體面積的10%以上，那么后端就沒有理由不考慮將其單獨做綜合，因為這樣子系統綜合有助于后期整個芯片綜合的收斂速度。
在這里，我們將主要從驗證的角度來考慮，如何選擇合適的驗證層次到下面不同的驗證環境中：
模塊級（block level/unit level）
子系統級（sub-system level）
芯片系統級（chip level）
硅后系統級（post-silicon system level）
模塊級
如果是圖中的處理器子系統，我們會考慮先將DMA（direct memory access）、cache緩存、和core0/core1分別展開模塊驗證。每個模塊驗證首先要考慮的是哪些功能點是可以在模塊一級完全驗證的，這基于如下考慮：
內部功能如狀態機驗證
內部數據存儲驗證
數據打包功能、編解碼功能
指令執行
寄存器配置
同時我們也需要考慮哪些功能無法在模塊一級被驗證到：
與其它相鄰模塊的互動信號
與其它子系統的互動信號
與芯片外部的互動信號
與電源開關的驗證這些部分我們需要考慮在更高的層次來驗證他們。
子系統級
對于一個成熟的子系統而言，它既擁有完備的功能可以執行專門的任務，也有足夠穩定的接口用來在更高級做集成。與模塊相比，子系統更穩定也更封閉，這對頂層集成是有好處的。也正是這種便于集成相對封閉的特征，我們可以從公司外部或者內部得到不同的子系統。合格的子系統交付不單單包含著它的設計部分，也應該包括如下：
設計包
驗證包
遞歸測試表
覆蓋率收集腳本和數據
完整的文檔（設計、驗證、集成、后端）
完備的交付才會增強頂層集成的信任，同時減少在集成過程中發生的一些接口理解分歧和參數化配置問題。
那么單就驗證而言，除了充分驗證內部功能以外，對于子系統的外部接口如果存在參數或者編譯預處理（compiler directive）時，驗證人員需要就這些參數和不同的編譯選項（可能因此產生不同的硬件結構功能）給出完備驗證。因為從子系統的封閉性和復用性來看，它們會在多個芯片項目中被使用，這對于設計復用來講是一件好事，而驗證也需要將驗證環境參數化來適應硬件的參數化配置。只有充分驗證了參數化的子系統，才可能讓它在不同的芯片項目中都能夠按照預期實現它的功能。
對于驗證管理而言，子系統驗證也是一個理想的可以切分的單元，因為這一層下面的模塊之間互動很多，而這一層本身又趨于封閉，也即是與外圍的接口有限，所以便于在子系統層建立驗證小組——包產到組。
芯片系統級
在芯片系統級，我們的驗證平臺的復用性較高，這主要是因為
外圍的驗證組件不需要像模塊級、子系統級的組件數量多且經常需要更新，它們主要側重于驗證芯片的輸入輸出
芯片內部的子系統之間的交互、協作檢查主要交給了處理器和子系統，從寄存器檢查和數據檢查入手，寫直接測試（directed test）用例
在芯片系統級的驗證側重于不同子系統之間的信號交互問題，以及實現更貼近實際使用的用例。這里的實際用例并非是在系統軟件層面的，而是將系統軟件層面的場景進一步拆分為多個模塊互動情景，再分類測試的。
硅后系統級
盡管我們硅前驗證部分與硅后系統軟件開發聯系較少，但是如果可以盡早將硅后軟件開發的實際用例在硅前測試，也能夠可以發現一些實際使用中的問題。實際上，系統軟件用例和硅前的隨機測試有著互補的特性，對于功能驗證上面缺陷的理解是，如果沒有被硅后測試、軟件開發、用戶使用的過程中發現，那么隱藏的缺陷也會永遠靜靜躺在那里，也許永遠也不會被發現（沒有零缺陷的芯片，卻有用戶沒有發現缺陷的芯片）。所以，如果可以將硅后的驅動、固件和系統軟件盡早在硅前就引入驗證過程的話，這可以跟硅前的驗證方法形成互補，使得驗證更加完善。
我們上面介紹了驗證的四個階段，也給出了他們各自使用的測試場景。這里我們再給出幾點可以遵循的原則幫助大家選擇適合的級別來進行驗證：
如果更低的級別可以完成某一項功能驗證，那么就不要在更層去驗證它。因為更小的驗證環境更有利于控制激勵場景的產生，更加全面的覆蓋功能點。
如果低層次已經充分驗證過某一項功能，那么高層次不需要重復驗證。而對于低層次無法完全覆蓋功能點驗證的時候，應該在高層次完全覆蓋。
如果是低層次的驗證階段，應該適當地考慮高層次的測試用例，而在低層次創造一些條件來進行模擬發生。
如果是高層次的驗證階段，驗證環境中的參考模型、數據比對、監視器等模塊首先考慮從低層次環境復用，在無法滿足的情況下再考慮重新構建。
如果是新的模塊或者新的功能，應該投入更多的精力和優先級在不同層次充分驗證。
最后，我們通過一張列表來更好的理解，不同的驗證層次的驗證側重、性能、使用方法：
懂得選擇一個合適的驗證層次，并且通過在不同層次分配不同的功能驗證點，是最終邁向驗證完備性的一項必備技能。