1. 前言
毛澤東在《實踐論》中提出“實踐、認識、再實踐、再認識”的辯證過程,主張理論與實踐的辯證統一,這一理論為中國共產黨實事求是思想路線奠定哲學基礎。芯片驗證理論應遵循同樣的原則,在客觀實踐中總結理論,且該理論能在客觀實踐中得到證明,如此反復進行并完善理論,而不是脫離實際的空洞理論。
2. 驗證存在的必要
有人做事情,就需要有辦法去檢查事情做得對不對,這是亙古未變的道理。芯片設計工作從市場需求→產品需求→功能需求→RTL代碼→網表→芯片產品,每一個環節都出現形式轉換。如果轉換過程不是完全端到端的自動golden執行,任何人為參與的轉換過程都有不確定性和不可重復性,就可能存在問題。
圖1 環節轉換
有幾種方法可以用于減少人為干預導致的錯誤:
自動化:識別流程中哪些環節可以讓機器自動化處理,機器的穩定性和效率遠遠高于人類的穩定性和效率,盡量多開發一些腳本和工具去完成一些需要反復執行的操作。如今AI的大規模應用,讓自動化處理變得越來越簡單了。
規范流程:將人為干預的動作轉換為一個個簡單和標準的步驟,減少人的主觀發揮,只能執行預定的流程。
冗余:冗余要求投入雙倍的資源去處理每一環節的轉換,例如在國家層面需要檢察院對刑事訴訟、民事訴訟、行政訴訟等活動進行法律監督,確保司法公正。類似在芯片設計中,就需要芯片驗證人員去監督芯片設計人員是否正確地進行環節轉換。
芯片設計人員和驗證人員都要基于對功能需求的理解去開發代碼,并在收斂點處比較兩者行為是否一致,也就兩份結果可以互相印證,以此減少人為轉換過程引入的問題。顯然,目前沒有什么工具可以做到自動將功能需求轉換為RTL代碼,那么芯片驗證人員的存在是非常有必要的。或許等到哪一天,EDA廠商利用AI等工具開發出可以識別功能需求規格并自動生成RTL代碼的解決方案時,那就是芯片驗證人員失業的時候。
圖2收斂路徑
3. 驗證的衡量標準
上節論述了芯片驗證存在的必要性,那么衡量驗證工作好壞的主要標準有哪些呢?這點我們可以從驗證的目的出發來談下,驗證目的說白了就是找出驗證對象的所有bug,因此完備性是最基本的衡量指標。另外隨著項目周期的縮短,更短的時間、盡可能少的工作量完成驗證工作也很關鍵,因此驗證的高效性和復用性也是衡量驗證的重要標準。
3.1 完備性
驗證人員經常遇到靈魂拷問:“你的驗證充分了嗎?你如何確保沒有bug遺漏?”。回答這種問題,其實就是回答如何保證驗證的完備性,用證據來打消提問者的顧慮。那么,哪些證據是必須的呢?應至少包含以下幾點:
完整的驗證流程規范:所有驗證人員需要嚴格遵守驗證流程規范(當然,有些環節需要設計人員的配合),不要隨心所欲,怕麻煩,逃避心理。驗證流程必須有功能需求規格講解、設計方案講解、驗證反串講需求規格和設計方案、驗證方案講解、驗證測試點講解、驗證環境檢視、驗證波形檢視、RTL問題舉一反三的頭腦風暴、覆蓋率分析、checklist檢視和驗證報告講解。當然有些講解和檢視不只是進行一次,可以反復多次進行,而且會議要充分討論,各抒已見,對事不對人。
完整的測試點清單:測試點分解可以說是驗證工作的核心,完整的測試點清單是驗證完備性的充要條件。測試點可以由設計或驗證寫都行,但一定需要系統人員、設計人員和驗證人員的共同努力去完善它,將需要測試的特性盡可能提取細分出來,并反復檢視。測試點也為覆蓋率的撰寫提供了輸入。
覆蓋率:覆蓋率數據的量化指標為驗證進度提供了一些反饋,覆蓋率包含了代碼覆蓋率、功能覆蓋率和統計覆蓋率。當這些都達到100%后,驗證人員對充分驗證會更有信心。當然100%的覆蓋率并不代表全部驗證空間都驗證了,只能說明我們識別到、關心的測試點覆蓋了。
波形檢視:設計人員需要對關鍵場景、關鍵信號等功能重點檢視下,進一步確保關心的場景有覆蓋且功能正確。
3.2 高效性
在完備性確保的情況下,花更少的時間和資源完成驗證工作可以使項目進行得更加順利。那么如何才能使驗證時間和資源花的少呢?以下列了幾點:
驗證策略選擇:同一項驗證任務而言,采取不同的驗證策略會有不同驗證效果。對驗證對象的全體或部分采取受約束隨機激勵的動態仿真、定向激勵驗證、形式驗證還是FPGA驗證等,極大影響到驗證進度;另外考慮是否可以復用歷史驗證環境或部分模塊組件,也可以加快環境的開發;對驗證對象的不同模塊采用合適的方法,分清輕重緩急,比如對IP的話,更多關注的是它和其余模塊間的配合,而不是IP內部自身的功能。
團隊建設:明確團隊成員的任務,以及成員之間相互依賴的地方,注重成員能力的培養,老帶新,積極討論的氛圍。這里就比較考驗領導的能力了,能根據成員能力的不同安排相匹配的任務,而且調動大家的積極性,利出一孔。
3.3 復用性
如果能復用歷史的驗證環境,可以極大地減輕驗證工作量。但要開發一個復用性強的驗證環境有時候會和高效性存在沖突的可能。例如在緊張周期的驗證工作中,驗證人員可能不會考慮將參數化引入到驗證環境中,因為這些“額外”的因素雖然對復用性友好,但當下是不高效的。這時候就需要驗證人員根據實際情況,在高效性和復用性之間進行平衡的,就像設計人員對PPA的平衡一樣。
復用性可能在短期內看不出來,但是在頻繁改動的項目或迭代多個版本的項目中,會發揮巨大的作用。關于如何提高復用性,下面列了幾點:
方法學選擇:使用主流的驗證方法學,如UVM。
參數化:對可能發生變化的地方引入參數,方便后期改動,比如地址位寬、包的長度等。
代碼準則:遵循一致的代碼準則,方便他人進行檢視和修改。
標準公共庫:對于常用的功能,抽象并封裝成單獨的公共庫,方便多個地方直接使用。比如時鐘和復位產生器,幾乎所有驗證環境都需要它們。
Callback:在寫代碼時,可以留一些后門,方便實現多樣化的激勵和后期增加新功能。SystemVerilog中引入的Virtual多態功能特別有助于這個功能。另外在UVM中也引入了重載和callback的功能,方便用戶操控。
4. 驗證的流程
不同公司的驗證流程各不相同,但最基本的應該包含圖3的流程。不過流程不是死的,要根據具體情況具體應用。
圖3 基本驗證流程
4.1 驗證策略和驗證計劃
驗證策略是芯片驗證的戰略性指導文件,驗證計劃是芯片驗證的戰術性指導文件,兩者密切關聯。通常情況下,一個驗證環境會單獨寫一份驗證計劃,由于可能需要用幾個驗證環境去覆蓋驗證對象的全部功能,因此一份驗證策略可能對應多份驗證計劃。
驗證策略是在高層次上描述對項目驗證的整體規劃,包括整體目標制定、時間安排、工作流程、驗證方法學、版本管理、覆蓋率要求和RTL驗證層次(UT/IT/ST/FPGA/Emulation/FPGA等)。
驗證計劃是對驗證策略進一步詳細地闡述,它會對驗證對象的環境展開具體的說明。一般會包括驗證環境結構、配置、測試點分解、用例規劃、驗證環境的局限性、人力需求、詳細時間安排以及各個關鍵節點的驗收標準等。
驗證策略和驗證計劃是驗證人員必須了解和遵守的指導文件,它是驗證人員同其它組進行交互的接口,也讓組內同事做事有依據可循。
4.2 環境開發和環境調試
按照驗證計劃的內容進行環境開發,激勵(Stimulus)、檢查器(Checker)和覆蓋率(Coverage)是環境開發的重點。激勵決定了RTL場景的產生,檢查器確保在場景發生后,RTL行為是符合預期,覆蓋率確保激勵是否真的產生了預期的場景。其中檢查器和覆蓋率的實現要萬分注意,如果它們倆實現不足或實現有誤,會直接導致驗證人員漏驗證了某些功能測試點,而且還不好發現。編寫激勵的人員最好要和編寫檢查器/覆蓋率的人員分開來,防止錯到一塊去,這也算是交叉驗證雙方代碼。
圖4 激勵、檢查器和覆蓋率的關系
環境調試是驗證工作中花時間比較多的環節,一般從簡單場景到復雜場景逐步遞增的方式去調試。先穩定驗證環境,再去定位問題是否來源于硬件設計。當判斷設計存在bug時,驗證人員可以定位bug的大致位置,然后提交給設計人員。設計人員修復問題后,驗證人員應在出錯的設計版本上遞交同一個種子同一個驗證用例,也就是確保激勵場景是一致的,來確保問題是否真的被修復了。設計修復問題后,通常也需要跑一下回歸測試,防止引入新的問題。
圖5 用例調試流程
4.3 回歸測試和問題分析
當代碼發生變化時,這個變化可能來源于硬件設計的改動或驗證環境的更新,需要跑下回歸測試,確保改動沒有引起新的問題,而且回歸也會產生新的場景去測試驗證對象。在回歸用例列表建立起來后,驗證團隊也會定期跑回歸測試,通常可以按天、周、月等單位,以發現新的問題。回歸測試也是實現驗證完備性的一項重要手段,只有通過大量驗證用例并行提交到服務器群,才可能撞擊到更多的場景,并完成覆蓋率的收集。
回歸測試通常是用腳本或工具自動進行的,流程包括回歸用例提交、服務器分配、收集仿真結果、錯誤分類以及給出總的仿真報告。
在大量回歸測試后,合格的驗證環境總會報出各種各樣的問題,這些問題有可能是RTL的問題,也有可能是TB的問題。把這些問題歸類后,會分配給不同的人去定位分析。當把所有問題都分析解決完畢后,并且所有RTL特性和驗證用例都開發完了,在回歸測試累計多少個時鐘周期或者累積發送多少個激勵包后,驗證環境再也沒有報錯,這時候可以宣稱完成了RTL的驗證。
5. 總結
任何書籍或文章所講的驗證知識都不是金科玉律,只是前人給的一些經驗之談,只是對某些問題的行動指南,切勿把它們當作教條。一切問題要從實際出發,理論結合當前的問題,在實踐中繼續完善理論。
從實踐中來,到實踐中去。要積累盡可能多的經驗,在每一個關鍵節點養成總結的習慣,并在下一個階段有意識地去完善,保持一種不斷成長的態度。
歡迎加入EETOP IC驗證群
(加群方法參考下圖 選擇IC驗證群)
芯片驗證精品課程推薦
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.