一 芯片開發概述
開發流程：
1. 從市場人員與客戶溝通開始
2. 系統設計人員按照功能划分為各個子系統
3. 子系統被進一步划分為功能模塊，並由設計團隊實現
4. 驗證人員對設計功能展開驗證，發現設計缺陷，交由設計人員修正
5. 驗證沒有出現漏洞后，交由后端人員進行綜合、布局、布線
6. 后端人員將核心數據交由FAB進行流片 pre-silicon
驗證和設計的緊密關系：
- 設計如果沒有經過驗證，是沒有任何信心去流片的
- 設計如果沒有經過充分驗證，是不夠信心去流片的
- 設計如果沒有經過充分量化驗證，是缺一點信心去流片的
- 驗證如果不懂設計，發現了漏洞是沒法和設計好好溝通的
- 設計如果不懂驗證，是沒法體會驗證已經在慢慢轉向軟件化的
- 設計需要驗證盡早盡快盡量地去測試設計發現漏洞
- 驗證人員需要行業的尊重，使其認識到驗證為公司帶來的價值
- 設計和驗證都需要圍繞功能描述文檔
- 設計初步實現后需要驗證入場
- 驗證發現結果不符合預期時，如果漏洞明顯可交由設計修正，待返回再此時；如果功能實現與設計存在分歧，則需共同回顧功能描述，決定哪一方理解正確，統一對功能的理解
- 再系統由底層向高層基礎過程中，驗證與設計需要在每一個層次展開各自工作，確定驗證在每一個階段的充分性
開發流程>>>>>>>>>>>
系統結構 -> 子系統及模塊定義->硬件設計及功能驗證 -> 自動后端綜合布局布線 -> 驅動，固件及軟件開發
<<<<<<<<<<<<<<集成過程
驗證人員做了哪些工作？
在設計人員根據設計功能描述，實現各個模式RTL code之后，開始構建驗證環境，做幾項工作來檢查設計：
- 設計文件是否正確地按照功能描述文檔去實施
- 硬件設計人員是否遺漏掉的邊界情況(corner case)
- 硬件設計是否足夠穩定來處理一些錯誤情況(error response)
note：驗證人員的發送的激勵和要做的比較都是依賴於功能描述文檔
驗證目前面臨的挑戰：
1. 如何窮盡所有可能的情況給設計產生激勵
2. 如何在各種可能的激勵情況下判斷出不符合硬件描述的行為並報告出來
分類：仿真驗證和形式驗證
二 驗證任務和目標
驗證的目標：“按時、保質、低耗”
必須按照項目預先的進度來考慮驗證的節點
盡可能少的將缺陷暴露在流片以后
功能驗證是唯一可以用低成本在硅前流程將上述目標達成的方法
三 驗證周期
驗證周期中的檢查點：
模塊功能詳述 驗證計划問題 驗證代碼檢查 驗證完備性檢查
創建驗證計划 -> 開發驗證環境 -> 調試環境和HDL文件 -> 遞歸測試 -> 硅后系統測試 -> 展開逃逸分析
功能描述文檔：
- 接口信息
- 結構信息：將模塊進一步細分為各個功能組件，以及包含組件之間的邏輯關系
- 交互信息：包含模塊之間交互信息圖
該文檔是硬件設計和功能驗證的基礎部分，也是共同參考依照的標准
制定驗證計划：
- 驗證方法：直接驗證、隨即約束驗證、形式驗證
- 驗證完備標准：量化出一些參數可以衡量驗證任務是否完成
- 驗證的功能點：需要給出驗證的功能點，以及在什么層次去驗證它，更具體的包括生成何種激勵，檢查設計ID何種狀態和數據輸出
開發環境：
從搭建環境開始，實現激勵產生器(stimulus generator)、參考模型(reference model)和數據比較器(data comparator)
note：不同的驗證方法會決定不同驗證環境的結構使用軟件
驗證人員在調式方面的時間投入最多
調試環境好RTL文件：
- 環境是否有瑕疵
- 測試序列是否合理
- 參考模型是否遵循功能詳述文檔
回歸測試：
去驗證硬件在某個缺陷修復或者添加了某項新功能以后，仍然可以通過以前的所有測試用例和可能添加的新的測試用例
目標——
1. 確保這次改動沒有引入新的缺陷
2. 由於隨機驗證在每次遞交時，默認的隨機種子不同。伴隨功能覆蓋率，可以通過王府的回歸測試和補充定向測試來將逐步提高驗證完備性
逃逸分析(Escape Analysis)!!!
硅后測試失敗在硅前驗證重現難度更大