功能驗證有著一整套完備的流程，而且從硬體系統定義貫穿到矽後測試部分。一般來講，乙個驗證團隊會基於時間差同時進行多個專案，多個專案之間自然也存在著借鑑、更新的關係，所以驗證的環境和復用性也是在不斷提高的。而每乙個專案在進行瀑布模式的開發時，驗證團隊也會在不同細分的流程當中完成每一項任務，同時在進入到下一項任務之前也會進行一些重要檢查點（checkpoint）的核對工作。又由於驗證人員會不斷地在新專案中提高驗證環境，所以驗證的週期也是不斷往復、螺旋上公升的過程。
上圖就將功能驗證的各個關鍵節點列了出來。首先驗證週期的起始點是從建立驗證計畫開始的，而驗證計畫需要參照系統工程師給出的模組功能詳述文件。接著驗證人員會開發驗證環境，在建立驗證環境的過程中，驗證人員一般會邀請設設計人員和系統人員一同回顧驗證計畫，確保驗證計畫沒有明顯的遺漏，所以驗證計畫的回顧是第乙個檢查點。
當驗證環境準備完畢，而且已經有一些可供測試的激勵時，驗證人員會比對設計的輸出結果和參考結果，在這一過程中，如果發現有比對結果錯誤的時候，驗證人員首先需要自己去除錯環境，並且定位到硬體描述檔案存在缺陷的大致位置。如果驗證人員有充分的經驗，他還可以進一步給設計人員修改**的建議。
當硬體設計經過了一定數量的激勵測試，驗證人員就可以準備遞迴（regression）測試了。遞迴測試就是將已有的所有測試序列都執行一次，一般來講，隨機激勵的遞迴測試要大於直接測試的遞迴，不過這種優勢會隨著驗證完成率曲線的增長而變得不那麼明顯，具體的原因就是隨機激勵無法給出定向激勵來填補剩餘的驗證空間，而直接測試則可以被有經驗的驗證人員運用恰當，用來驗證邊界情況。在完成遞迴測試之前，我們需要進行第二個檢查點「驗證**檢查」，這一檢查點的作用就是一通來回顧驗證**以期發現可能遺漏的測試激勵、不恰當的隨機約束、**結構的缺陷等。
在完成遞迴測試以後，我們進行第三個重要的檢查點「流片前驗證完備性檢查」。一般這項檢查是驗證經理最後簽字的，對於驗證經理他會根據乙份檢查清單來將量化的驗證進度綜合評定，最後考慮是否已經完成驗證的任務。當然，這一過程並非只有在流片前才會評估，而是發生在這一期間內若干階段，包括模組驗證階段、子系統驗證階段、晶元系統驗證階段和最後的網表驗證階段，每乙個階段驗證經理都有相應的通過標準和檢查清單，來逐一判定出每乙個模組、子系統和最終的晶元系統是否達到了驗證的目標。
進而，在最終流片以後，驗證團隊也需要和矽後系統測試團隊完成對接。這是由於，矽後系統測試階段才是真正能夠判定小到每乙個功能模組大到整個晶元系統的各項功能能否正常工作的標準 。通常來說，系統測試團隊也會參考功能驗證團隊的驗證計畫，先從底部測試每個模組的功能，在逐步向上層走，最終測試整個晶元的聯合功能。而在系統測試環節中，如果發生了功能測試失敗，那麼系統測試人員會同驗證人員一同協作，最終來定位到是硬體自身缺陷還是測試中的環境配置或者暫存器設定問題。如果最終測試發現了硬體缺陷，那麼硬體團隊和軟體團隊也會一起評估該缺陷是否是不可修復的。一般針對矽後測試發現缺陷的情況，首先會考慮是否有軟體修復的可能，其次才會想硬體上面有無變通的辦法，當兩方面都無法解決的時候，我們只能宣告，乙個缺陷在矽後測試發現了。當然，比這還不幸的是，這個缺陷是乙個致命缺陷。
在經過系統測試以後，驗證團隊會就最終在矽後測試中發現的缺陷展開逃逸分析，來思考為什麼漏洞會在片後測試環節中被發現。這其中可能引起漏洞在矽前驗證階段逃脫的情況包括有：
驗證計畫制定不充分，沒有覆蓋完全功能驗證點。
激勵序列生成不完全，沒有完全覆蓋可能生成的有效激勵情況。
驗證環境不完備，例如比較器（comparator/scoreboard）沒有足夠完善判斷設計的輸出結果。
在展開逃逸分析之後，我們需要展開整個驗證週期的最後一項檢查點吸取教訓。吸取教訓是一種被動的方式，這是因為在已經完成的專案中我們犯了一些錯誤。如果我們不想被同一塊石頭絆倒兩次的話（沒有人會願意吧……），我們需要吸取教訓。這種被動的方式和我們主動去提高驗證效率沒有衝突，恰恰是在我們沒有考慮到的地方學習，在我們考慮到的地方主動完善，使之成為一種內外結合提高驗證能效的方式。在這裡，我們給出一些關於吸取教訓的建議：
1、**請在整個驗證週期內保持收集突發狀況、如何克服、陷阱從哪來、遺憾沒有做到的事情有哪些等等跟驗證完善有關的地方。**之所以建議這麼做，是因為我們通常在專案介紹以後會懈怠下來，而且我們的記性不足以記住事發當時的一些細節，還有我們可能會忘掉當時的一些心理痛苦。所以就像做乙份驗證記錄一樣，保持著這樣乙份完整記錄，將來我們可以從中很快地串起來我們一路是如何走過的。
2、除非有一些個別情況，否則驗證缺陷的暴露會跟整個模組驗證團隊都有關係，因為我們可能一起制定的驗證計畫不夠充分、一起回顧測試序列的時候也不夠仔細、一起……所以在一起接受教訓的時候，要想團隊整體的疏忽在什麼地方，每個人也因此需要考慮到自己在驗證週期的不同階段應該充分履行的責任是什麼。
3、盡量地從一些教訓中去量化今後可以加強的地方。比如，功能覆蓋率和**覆蓋率的指標如果是硬性的，那麼驗證人員就不應該做出妥協，應該想辦法去達到這個標準，又比如一些跨時鐘域的問題沒有發現，或者在網表**的時候才發現，這種情況，我們就應該將跨時鐘域檢查、同步單元檢查作為標準在驗證過程中執行下去。
對驗證週期的細些細節展開討論，目的在於更詳細地幫助大家了解認知清楚每乙個階段的具體任務和值得注意的地方。
驗證週期介紹
主要的事情 建立驗證計畫，開發驗證環境，激勵測試，調整環境，比對設計，準備回歸regression，驗證 檢查，包括激勵不對，隨機不到位，結構缺陷 最後清單checklist檢查，流片。主要的事情 功能文件時設計和驗證的基礎部分，設計人員根據功能文件，將要實現的功能翻譯成rtl 驗證人員按照自己的理...
晶元驗證全視之七 驗證的週期（下）
本文 這一節我們繼續剩下的驗證週期裡的四個階段。遞迴測試 遞迴測試指的是去驗證之前的硬體功能在某個缺陷修復或者新增了某項新功能以後，仍然可以通過以前的所有測試用例 test case 和可能新增的新的測試用例。這些可能存在的環境變化包括硬體設計自身的改進 缺陷修復 功能新增和驗證環境的更新。在每次的...
時鐘週期 指令週期 機器週期 匯流排週期
時鐘週期 時鐘週期也稱為 週期,定義為時鐘脈衝的倒數,是計算機中最基本,最小的時間單位.在乙個時鐘週期內,cpu只完成最基本的動作.對同一種機型而言,時鐘頻率越高,計算機工作速度越快.機器週期 在計算機中,為了便於管理,通常把一條指令執行劃分為若干個階段,每乙個階段完成一項任務.如 取指令,儲存器讀...