轉眼自己已經碩士畢業快兩年了，時間過得很快，保持頭腦清醒找準方向比努力更重要，所以作為一名技術工程師應該每隔一段時間就要跳出技術細節好好思考下自己做過的和未來要做的事情，這次談談自己從事芯片驗證作業中學到的知識和感受吧，
我們到底需要干什么？
芯片驗證就是保證設計滿足預期和需求，第一步便是制定驗證計劃，要知道驗什么，怎么驗，哪個先驗，哪個后驗，哪些能一起驗，SoC驗證的先決條件是認為IP都沒有問題，當然這只是假設的理想情況，那重點關注的就是IP的例化、連接，IP之間的匹配性，IP與CPU的協同運作，歸結為一句話：帶有功能屬性的連接性檢查，故通過總線實作暫存器訪問、DMA傳輸、中斷回應、IP與IP協同作業、IP與I/O互動資料、時鐘復位、基本功能、例外回應處理以及特殊作業模式下狀態都是必不可少的檢測點，特殊作業模式常見的是low power，
這是只是基本套路，如果待驗證IP是在之前基礎上更新的產物，那更新feature非常容易出問題，你以為這就結束了？這僅僅保證了功能正確，現實往往還需要分析performance和power，驗證是伴隨著整個設計流程推進的，當RTL確保沒大問題了，接下來要檢測被SDF反標的netlist行為是否與RTL一致，總不能全部case都跑一遍，deadline不允許，那保留哪些呢？高速資料傳輸、I/O相關，當時鐘頻率變高，出問題的風險就越大，I/O上也經常會出問題，比如8bit位寬的資料一起翻轉，結果其中一bit往后延遲了0.2ns導致所有資料錯亂也不是不可能，
該如何驗證呢？
在上一小節提到的驗證task有被慣性思維束縛的意味，為什么這么說？人們從專案中發現寫測驗用例這種動態仿真方式沒辦法覆寫到所有場景，因為有時候你根本不知道用戶會怎么用，這時候遍歷窮舉的老方法隨著計算機和EDA技術的高速發展又進入到工程師的視野，
相對的靜態驗證即是采用這種思想，用工具遍歷所有可能激勵，自動觀察回應與預期的關系，筆者之前參與過IOMUX的靜態連結性檢查，它就是利用Synposys廠家的property formal verification (PFV) 配合Verdi觀測波形分析連接性，靜態驗證由于工具比較傻，所以只能使用腳本來做許多前期處理，主要是檔案操作和正則匹配任務，靜態仿真如此強大還要動態仿真何用？naive，你以為埠連接與預期一致就能保證功能無誤？打個比方，A和B兩個模塊，A的輸出連接到B的輸入，當A輸出高脈沖時，B輸出信號b拉高，使用靜態仿真方式發現連接是對的，但是A輸出的脈沖寬度沒有達到B的輸入要求，結果就是信號b始終為0，
所以呢，動態仿真更貼近真實場景，而靜態仿真可以覆寫到邊界情況，不難看出，芯片驗證是沒有盡頭的，因為那個所謂的“邊界情況”也可能出現之前例子中的疏忽！頓時下出一身冷汗，兄弟們辛苦兩年做的專案變成磚頭了，，，這是后可能的補救措施是：在user guide里寫明該芯片不支持這一“邊界情況”，當然這是后話了，
什么時候是個頭？
從靜態仿真角度講，所以已知連接全部正確，從動態仿真角度來說，驗證RTL的前仿所有function test case PASS，performance test case PASS, low power test case PASS, IP頂層toggle coverage 達到100%，驗證SDF+netlist的后仿所有test case PASS，power gating test case PASS, power analysis test case PASS，再完善點，客戶定制專案中用戶重點關注功能點相關use case 前后仿均PASS，交差！總結起來時間維度前仿+后仿，方法學維度動態仿真與靜態仿真，測驗點維度function, performance和power，是不是有點頭大了？
怎么快點結束？
資本家壓榨勞動力我們還得配合:) 首先和design team的思想類似，復用嘛！已經有的資源就不要重復造輪子，除非時間充裕單純為了學習鍛煉（我干過這事），可復用的東西很多，包括VIP、testbench、script、test plan、test case、EDA tool usage甚至是包含這一切的整個flow，所有驗證需要的資源都能夠通過分析表格一鍵生成豈不美哉？除了自己悶頭干，高效率溝通在較大專案中尤為重要，現在chip規模大的嚇人，你所有模塊都懂對于普通人短短幾年時間是不可能的，很多時候問下別人就能快速解決，至少也能提供一個思路，再有一點：拉低完美主義的優先級，先做出來再完善是永恒的策略，
這都是方法層面，時間層面主要包含兩點：加快仿真速率和多task并行跟進，仿真畢竟是軟體模擬硬體行為，時間進度推進1ms到真實時間慢的時候要按小時計算，提高仿真速率應該是未來必然趨勢了，高性能服務器是一方面，更經濟的辦法應該是減少編譯次數，減少需要編譯的面積，提高clock頻率，去除與當前test case無關的配置操作，，，這個仿真在執行，就看看另一個bug有沒有被修復，
如何更勝一籌？
SoC驗證就是系統級驗證，了解更多MCU結構和作業原理事半功倍，所以嘗試著去驗證和SoC作業機制本身相關的common模塊會給你帶來更多的識訓，比如DMA、IOMUX、external memory controllor interface、權限訪問控制單元、platform、bus infrastructure (fabric)、power control、clock generator等等，
上述知識點會解決你很多困惑：怎么時鐘突然不toggle了？這個信號是干什么的？為什么產生例外中斷了？CPU hung住了怎么回事？暫存器讀寫失敗問題在哪里？系統進入low power模式后沒有被成功喚醒怎么回事？但歸根到底，每個人關注的還是具體某幾個IP集成到這個chip上的行為和表現，特定應用領域對應特定的IP，懂PLC、網路通信、USB、加密解密等等能避免一頭霧水，即使所有case跑PASS了還不知道自己在干什么，
懂知識的同時也要精通手段，system verilog常見用法，寫個VIP、testbench、assertion，script功底一鍵生成C function甚至是test case、definition，分析log file，UVM的約束隨機化快速抵達邊界條件，基于此的驗證平臺也可以通過script來自動生成，
寫道最后
由于經驗欠缺和懶的關系寫的比較淺顯，算是對一段時間作業生活的記錄，從橫向和縱向上多接觸多磨練一直是本人所期望的，干IC這一行我始終認為掙錢是順帶的事情，可貴的是能干著自己喜歡的事情，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/285603.html
標籤：Verilog
上一篇：Python 不定長引數 *argc/**kargcs - Python零基礎入門教程
下一篇：Python字典回圈與字典排序