1. spec文檔
芯片整體系統以及細分模塊都需要功能詳述文檔，包含信息：
- 接口信息
接口版本，標準，若是標準接口，則不需要時序信息，命令，數據傳輸信息等，只需要時鐘，復位，接口信號名；若是自定義接口，則需要詳細描述。 - 結構信息
模塊細分爲各個功能組件，以及邏輯關係； - 交互信息
模塊和外界模塊交互示意圖，時序信息
2. IC設計流程
整體上分爲系統設計——電路/邏輯設計——物理設計流程，得到GDSII文件後交由工廠生產
（1）系統設計
a. 制定規範
b. 算法設計：用C或MATLAB來研究制定一個IC系統的可執行規範
c. 架構設計：用SystemC進行性能估算和仿真，確定設計中採用的數據通路結構。如設計中需要多大乘法器，採用何種濾波器，採用並行還是串行方式，是否需要流水線等；在該過程中，需考慮那些模塊用IP完成，哪些自己實現。
（2）電路/邏輯設計
數字IC設計一般採用synopsys公司的Galaxy平臺，裏面包括以下軟件：
前端：
a. 用VCS編寫編譯RTL，Verdi看波形，然後 Design compiler添加約束,對設計進行綜合，得到滿足條件的門級網表。在該過程中，可進行可測性設計（DFT）。
b.同時用primetime進行STA；
後端：
c. 將門級網表輸入到JupiterXT 平臺進行版圖規劃
d. 將版圖規劃和門級網表輸入到 Physical Compiler 進行物理綜合和優化，可對時序，功耗，面積等進行優化
e. 在物理綜合的基礎上，用Astro再進行優化佈局，以及時鐘樹的綜合和佈線
f. 有了設計好的版圖後，用 Star-RCXT 對版圖進行寄生參數提取，以便進行時序和功耗分析，建立工藝庫模型
g. 用Primetime 進行功耗和時序分析（STA）。
h. 將最終版圖輸入到Hercules 進行層次化的物理驗證，保證版圖和線路圖的一致性。
3. IC驗證
驗證貫穿了設計的每個階段，可劃分爲前端仿真和後端仿真。前端主要爲了檢測功能邏輯的缺陷，後端是爲了檢測問及電路由延遲導致採樣失敗所產生的功能缺陷。
a.系統設計時，採用仿真進行性能分析和協議分析
b.電路/邏輯設計時，採用軟硬協同驗證：FPGA驗證；靜態時序分析工具驗證時序；用形式驗證檢查綜合過程及ECO是否正確。
c.物理設計時，採用物理驗證（LVS,DRC）:用靜態時序工具驗證最終時序；用形式驗證檢查佈局佈線過程及ECO
- 驗證解決的問題：
- 窮盡所有的可能的情況給設計產生激勵（一般會給出隨機約束激勵）
- 在各種激勵情況下判斷處不符合硬件描述的行爲並報告出來
- 驗證環境：
- 激勵產生器
模擬與DUT相鄰設計的接口協議 - 參考模型
- 數據比較器
- 迴歸測試
在某個缺陷修復或功能修改後，按照以前所有的測試用例（testcase）和可能添加的新的測試用例進行測試。測試要求：
- 確保本次改動修復以前的漏洞，沒有引入新的缺陷，實現了新功能。
- 遞交不同的隨機種子（random seed）進行隨機測試，確保每次測試都能提高功能覆蓋率
- 驗證層次
爲了便於拆解功能模塊，方便分工協同，通常會把進行分層次驗證，以手機通信芯片爲例：
- 芯片系統級（手機通信芯片）
該部分驗證的複用性較高，主要側重於驗證芯片的輸入輸出；從寄存器檢查和數據檢查入手，實現定向測試子系統間的交互協作。 - 子系統級（數據接口 I/O）
需完成設計包；驗證包；迴歸測試表；覆蓋率收集腳本和數據；完整的文檔（設計，驗證，集成，後端） - 模塊級（USB3.0 PCIe I2C ）
考慮的因素：內部功能（狀態機等）；內部數據存儲；數據打包，編解碼；指令執行；寄存器配置；與其他模塊，子系統，芯片系統以及電源開關的互動情況 - 硅後系統級
功能驗證，與硅前隨機測試互補
- 驗證透明度
- 黑盒測試
應用場合：對設計細節缺乏認識。
該部分測試只需要將激勵給入設計的外部接口，檢查設計輸出，建立參考模型，無需關心設計本身。但是該測試透明度較低，導致無法深層次地定位問題，從而解決一些較深的缺陷。 - 白盒測試
應用場合：瞭解內部工作邏輯、層次，信號等。
無需參考模型，只需要植入監視器和斷言來檢查各個內部邏輯，從而對底層的設計細節進行測試。但是該測試專注於設計內部邏輯檢查而忽視整體功能測試，且一旦設計更新，驗證文件的可複用性很差。 - 灰盒測試
實際應用場合中通常將黑百盒兩種測試方法結合。其特點是前兩種測試折中。
- 動態仿真
通過測試序列和激勵生成器給入待測設計適當的激勵，跟隨仿真進程的推進，判斷輸出是否符合預期。
- 定向測試
激勵內容在仿真前確定下來，測試用例給出的激勵序列不會在下一次提交任務時改變。一般應用在模塊測試早期或這系統級芯片測試場景中，它適合於測試設計的基本功能 - 隨機序列測試
通過預先定義的約束，每次隨機產生合理的數值，通過激勵產生器給出測試序列。使用隨機激勵時，需要用功能覆蓋率來評估驗證的進展情況 - 參考模型測試
- 斷言檢查
針對某特定的邏輯或時序進行預設，一旦設計的實際行爲不符合斷言的描述，則給出檢查報告。
- 靜態檢查
本身不需要仿真、波形激勵，可通過工具的輔助發現設計中存在的問題。在設計早期發現功能實現意外的設計問題，完善設計代碼。檢查方法包括：
- 語法檢查
- 語義檢查
在語法檢查的基礎上做深入檢查，檢查範圍包括設計錯誤，影響覆蓋率收斂的問題，可能會產生X值以及受其影響的設計部分 - 跨時鐘域檢查（CDC）
跨時鐘通信要考慮同步問題，由此導致的隨機性可能會導致建立時間和保持時間無法滿足，導致功能失敗。 - 形式驗證
形式驗證可以通過數學方法遍歷狀態空間，進而證明設計行爲符合屬性描述。
等價檢查：用來保證兩個電路的行爲是等價的，檢查不同抽象級的電路是否一致。
屬性檢查：電路的行爲通過驗證語言來描述其屬性，隨後通過靜態方式證明在所有狀態空間都滿足該條件，否則舉出反例。
- 覆蓋率
- 代碼覆蓋率
語句覆蓋率：程序的每一行代碼是否被執行過
條件覆蓋率：每個條件中的邏輯操作數被覆蓋情況
決策覆蓋率：指在if, case, while, repeat, forever, for, loop語句中各個分支執行的情況
事件覆蓋率：記錄某一個事件被觸發的次數
跳轉覆蓋率：記錄某個邊界信號數據位的0/1跳轉情況
狀態機覆蓋率：記錄狀態被進入的次數，以及狀態間的跳轉情況。 - 斷言覆蓋率
記錄斷言的先決條件是否被觸發，以及判斷語句成功或失敗。基本可分爲基於動態仿真或者硬件加速的斷言覆蓋率和形式驗證的靜態斷言覆蓋率。 - 功能覆蓋率
主要關注設計的輸入，輸出和內部狀態，衡量是否實現設計的各項功能，且是否按預想的行爲執行
- 測試平臺（testbench）
整個驗證系統的總稱，包括驗證結構中的各組件，組件間的連接關係，測試平臺的配置和控制，編譯仿真流程，結果分析報告和覆蓋率檢查。
平臺包括時鐘/重置，激勵發生器，DUT，比較器，監測器五個組件
4 STA基本知識
雖然synopsys的Design compiler內部集成了時序分析工具，但是全面的靜態時序分析需由primetime進行
- timing path
STA會把電路分解成一條條timing path，也可稱爲data path，本質就是信號傳播的途徑。每條timing path都有一個起始點（電路中信號被時鐘沿鎖存的點，即寄存器時鐘端口和輸入pin）和終止點（信號經過一系列的組合邏輯的通道或者走線後被另一時鐘沿捕獲的點，即寄存器輸入端口和輸出pin）。其中時延最長的path爲critical path。
slack = required time - arrival time,表示是否滿足設計要求（若爲負則不滿足） - 建立時間 setup time
觸發器在時鐘信號上升沿到來以前，要求輸入數據保持穩定不變一段時間，該時間即爲建立時間。
如不滿足setup time，該數據將不能被這一時鐘打入觸發器。 - 保持時間 hold time
觸發器在時鐘信號上升沿到來以前，要求數據保持穩定不變一段時間，以便能夠穩定讀取，該時間即爲保持時間。
如不滿足數據同樣不能被打入觸發器。 - slew rate
表徵上升或下降的波形跳變的快慢，可理解成上升或下降的坡度。transition time表示電平轉換時間 - 扇入扇出 fan-in / fan-out
扇入：表示一個邏輯門能夠處理的外部輸入的能力。扇入越大，輸入電容就要變大，因此邏輯門的反應速度會變慢。因此可用多級邏輯門代替高扇入的設計。
扇出：表示邏輯門的驅動能力的大小，即可驅動同類邏輯門的最大數 - 延遲類別
單元延遲（cell）：取決於輸入信號轉換時間（斜坡）和輸出負載
線延遲（net）：線負載模型或電路拓撲結構
5. 綜合
對芯片工作狀態和環境做一些定義，並綜合、映射門電路，根據結果進行優化
- 時序約束
設置輸入輸出延遲，則寄存器與寄存器間的延遲會確定下來(設計中的所有端口都需添加約束，否則EDA軟件無法匹配合適的library) - 環境約束
芯片面積，線負載模型，驅動單元，負載大小
6 DFT
芯片出廠後運用一種算法檢測芯片錯誤，這種算法（差異算法）實際上是一種固定輸入對應唯一輸出的邏輯，這種邏輯可在芯片設計過程中確定
7 UVM
見鏈接：https://blog.csdn.net/qq_39815222/article/details/106619641