數字芯片驗證流程
什么是驗證及其方法學?
芯片驗證就是采用相應的驗證語言，驗證工具，驗證方法，在芯片生產之前驗證芯片設計是否符合芯片定義的需求規格，是否已經完全釋放了風險，發現并更正了所有的缺陷，站在全流程的角度，它是一種防范于未然的措施。我們知道芯片流片回來測試時發現硬件bug，那時基本就無力回天了（芯片內的硬件bug一般都沒辦法修正，當然部分bug是可以通過軟件或燒efuse等措施來屏蔽），因此把問題攔截在流片之前非常之重要，這正是驗證存在的意義。什么是驗證方法學？驗證工程師繞不開的一個基本概念。芯片規模越大功能越復雜，潛在的問題也就越多，驗證的難度也就越大，驗證方法學，就是研究怎樣降低驗證工程復雜度的同時，還能保證驗證的可靠性，提升驗證效率的一門學問。從它被提出到今天，其核心依然是帶約束的隨機激勵、覆蓋率驅動以及重用，并利用面向對像語言的特性對常用功能進行高度封裝，再提供統一的事物層接口使不同抽象層級的建模數據得以共享和有效通信，從而極大地提升驗證平臺的構建效率，并加速EDA仿真，最終對縮短芯片面市周期做出貢獻。驗證的主要工作
芯片驗證的主要工作是根據規格文檔和詳細設計文檔提取驗證功能點，編寫測試激勵，并搭建驗證環境，或利用已有的驗證環境對DUT進行驗證和回歸。驗證具體崗位還可以進行細分，例如功能仿真驗證，FPGA原型驗證，硬件模擬加速平臺驗證（Palladium，ZeBu，Veloce），后端時序驗證等，常見工作如下：①熟悉芯片規格主要是學習各種相關的文檔材料，包括但不限于協議、需求、規格、功能說明、歷史芯片文檔、重用環境評估與恢復。②提取驗證功能點測試點一般分解過程如下，首先根據各種文檔梳理出驗證特性，然后根據驗證特性細化出測試點。
測試點分為場景類、功能類、性能類、白盒測試點(設計人員提供)、接口類、異常類等維度，全面、明確、細致，無歧義的將所有驗證特性細化為一個個不可分割的小點，每個點明確采用directtest還是coverage覆蓋還是assertion覆蓋。功能覆蓋需要細化覆蓋范圍，比如典型值、邊界值、異常值、cross。當然測試點也不是一次分解完成，在整個驗證過程中會進行多次分解和review，直至完善。測試點分解絕對算是芯片驗證工作中的最重要的一環，是充分體現驗證人員經驗、能力、智慧、價值的一項工作。芯片中的bug往往都是沒有想到的點或者沒有覆蓋到的點。所以測試點分解一定要追求完備、細致、無歧義，要做到測試點分解完成后，無論哪個驗證人員測試，驗證質量都是有保證的。過于粗糙的測試點會導致不同的驗證人員在測試用例設計時有不同的理解和實現，或許就會遺漏掉一些corner點。同時粗糙的測試點也會造成工作量評估不準確，導致后期突發任務增多，造成項目延期。③撰寫模塊級和系統級驗證方案對于驗證方案，每個公司可能有不同的標準，目的是設計驗證架構指導后續驗證工作，保證所有測試點都能在該驗證過程中覆蓋到。標準化、參數化的方案設計是非常重要，要考慮到該模塊的后期集成和重用，驗證方案中一般還包括進度安排、風險評估等。注意：設計參考模型或checker時一定不要過多參考設計方案或代碼，理論上設計和驗證從spec開始就要分開，是平行獨立的兩條線，過多的參考設計是非常不可取的，造成的后果就是參考模型/checker和設計代碼實現一樣，case總是一跑就過，完全測試不出設計bug。④開發驗證環境、參考模型和驗證腳本這是驗證人員的基本功，一個足夠完備靈活自動化的驗證環境能節省后面測試用例實現的很多工作量，測試用例會變得很簡單，不同的測試用例只需要開關某些配置和修改一些約束；反之一個糟糕的驗證環境會讓測試用例變得冗長、復雜、低效。軟仿測試平臺現在流行基于UVM搭建環境，一般使用高級硬件語言如SystemVerilog開發。⑤驗證執行驗證執行階段，按照測試點一個一個進行覆蓋，寫測試用例（直接測試、隨機測試）、debug，后期進行代碼覆蓋率和功能覆蓋率的收集分析、用例增加以及最后用例檢視。這個階段把驗證發現的debug做好登記。⑥撰寫驗證報告驗證執行做完后，需要輸出驗證報告（一般都會有評審環境），報告主要包括各功能點覆蓋情況、代碼覆蓋情況、性能分析、功耗分析、風險評估等類容。⑦配合其他工程師的工作主要是查找修復設計缺陷，帶領其他工程師完成項目驗證工作；協同設計和固件工程師在硬件加速器/FPGA平臺進行驗證調試；與硬件工程師共同確立硬件實現方案，提供硬件設計建議；協助測試工程師完成芯片測試等工作也是驗證人員需要干的活。
數字IC驗證流程
一般意義上，數字芯片驗證就是對RTL代碼進行EDA仿真，并從中發現RTL代碼BUG后，再提交設計工程師進行BUG修復的過程。實際項目操作中，驗證工作的參與不僅僅是在RTL代碼的仿真階段，它應該貫穿整個項目的始終。如果說開發一顆芯片是一場戰斗，那么設計與驗證是同時投入，積糧草、挖戰壕、沖鋒陷陣都在一起，但拼殺結束后，設計可以陸續撤離，而驗證則要負責打掃戰場，確認所有敵人都不再喘氣兒，保證萬無一失。下面用這張圖示意驗證各重要環節在整體開發流程中的位置與配合關系。
架構師從原始需求提煉出來功能規格(FS)與架構規格(AS)，兩套流程使用不同的思路和方式對其進行實現，實現過程中互為對照同步收斂，產生分歧時以架構為根本決策依據，最后殊途同歸。
驗證流中，首要環節為測試點(亦稱驗證特性 Verification Feature，我習慣稱測試點)提取，驗證的后續所有動作基本都是圍繞測試點來展開的。測試點實際就是把一個有機整體的功能分解成一系列單個的功能點，起到化整為零，化繁為簡的作用，從而方便構建測試用例對其進行驗證。分解的粒度沒有一定之規，但有幾個大原則要把握：完備性，即不能遺漏任何功能點，特別是異常處理，邊界處理，容錯處理這些往往容易被忽視；低耦合，不同測試點之間的相關性越低越好，這也直接決定了分解粒度，并影響testcase的開發難度；無歧義，測試點的描述要直接而明確，不同測試點之間不存在矛盾之處。
測試點的主要來源為FS和AS，這也就要求驗證工程師在項目架構設計階段并不能置身事外，而是和設計工程師一樣，要參與到架構文檔的Review活動中來，在不改變產品功能的前提下，甚至可以向架構師提出可驗證性方面的設計建議或需求，參與度越高，理解越深刻，越能保證測試點的提取質量。測試點也有少部分來源于設計工程師的微架構或設計規格(DS)，主要針對一部份corner case，來源于DS的測試點不能有悖于FS/AS的要求。測試點是驗證活動的核心，直接決定驗證結果的可靠性與完備性，非常重要，但因為它是一個相對主觀東西，很大程度上依賴于工程師的經驗、理解能力、以及責任心，可以說衡量一名驗證工程師的技術水準，不在于他的Testbench寫得多漂亮，UVM玩得多熟，而在于他的測試點分解質量。為了保證驗證源頭的正確性，驗證工程師應該對FS/AS反復研讀，項目組內進行交叉串講，并通過答辯后再行測試點分解，分解結果依然需要通過架構師、設計工程師、以及組內其他驗證工程師（特別是相鄰模塊）的Review后，方可進入后續流程環節。這個過程看似繁瑣，但磨刀不誤砍柴功，切不可圖省事而草草了之。測試點明確以后，便可以針對性的設計測試激勵與相應的功能覆蓋點，并明確覆蓋手段。功能覆蓋率讓自然語言描述的測試點變得更加具象和量化，由主觀變成客觀，是驗證出口標準中最重要的依據之一。功能覆蓋點的選取尤其要注意邊界值與異常值，并設置合理的cross，確保完備。同樣，相互之間反復Review是必不可少的操作。驗證平臺的設計現在已經非常標準化，UVM一統天下后，基本框架都差不多，主要取決于對UVM的理解與System Verilog的編程能力，在這里沒有太多可說的，當然它也有很多細節，可另外開文單獨進行講解。我覺得需要稍加注意的幾個點，一是transaction中，對隨機約束的設計要符合測試點的要求，每一個constraint的粒度把握好，方便在testcase中進行擴展與差異化控制；二是功能覆蓋率編碼不要遺漏，也不要加入毫無意義的cover bins,嚴格符合測試點階段的結論；三是適當考慮組件的可重用性，提升整體效率。重用的問題，后面會講到，這里不展開。和設計工程師對自己的代碼進行單元測試一樣，驗證環境搭建完成后，也應該進行自測試，以排除低級簡單的錯誤。比如可以采用driver的輸出接monitor輸入的方式，檢查測試激勵是否可以生成，整個平臺的數據通路是否暢通，自檢測機制是否正常等，這是一個簡單而必要的步驟，能使RTL與VE的第一次集成，即Sanity Test變得事半功倍。Sanity Test（冒煙測試），顧名思義，就是一跑就冒煙掛了。這是設計代碼和驗證環境都剛剛完成后的測試，目的就是確保寄存器讀寫OK和打通基本數據流。這個過程設計人員和驗證人員高度配合，發現bug會立即修改。這個過程會發現很多代碼問題，這個階段發現的bug一般不提問題單。冒煙測試完成后，DUT已經基本可以正常工作，這時候就正式開始進入驗證執行階段。驗證是一個不斷迭代的過程，需要不斷編寫或修改測試用例來覆蓋功能點和rtl代碼。仿真中發現問題，更正問題，記錄問題，回歸測試，往復循環的同時，分析功能覆蓋率與代碼覆蓋的空洞，根據分析結果增加用例運行次數，或者調整隨機約束，或者增加direct testcase，使覆蓋率趨于收斂。Regression 在Sanity test后將一直持續到Tape Out。流程走到Sanity Test，正式開啟EDA動態仿真之旅。Sanity Test是一條最基本的測試用例，使用最正常的測試激勵，最小的隨機范圍或不進行隨機，以快速確認基本的數據流能通以及寄存器讀寫正常(如果有的話)， 是后面復雜測試進行下去的前提。以后不論是RTL還是VE的每一次代碼增改，在提交版本服務器之前，通過sanity test是最基本的要求。流程再往后延伸，就是一個不斷迭代的過程。根據最前面的測試點分解，驗證工程師不斷添加測試用例，對RTL代碼進行仿真，發現問題，更正問題，記錄問題，回歸測試，往復循環的同時，分析功能覆蓋率與代碼覆蓋的空洞，根據分析結果增加用例運行次數，或者調整隨機約束，或者增加direct testcase，使覆蓋率趨于收斂。在實際的項目管理過程中，往往會把這個階段根據功能實現比率再進行細分，比如按85%網表、95%網表、100%網表分為三段，達到每一段的出口標準后，將對設計和驗證代碼進行固化鎖定，作為后續的基線版本，這樣既有利于項目進度的精細化控制，也方便問題的管理與回溯。100%網表以后，設計將全面進入后端設計流程，RTL代碼的變更將變得很少且嚴格，但這并不意味著驗證工作可以停步，Regression 在Sanity test后將一直持續到Tape Out。在我以往的工作經驗中，一直都堅持Daily Regression的形式，即每天下班前，都會將所有測試用例提交服務器進行回歸測試，在**CRV(constraint random verification)**機制下，用例跑得越多，最終的驗證結果越可靠，但如果全部采用Direct testcase進行驗證，daily regression將變得毫無意義。 EDA仿真到最后，完成標準主要有三個，一是所有testcase全部通過，二是代碼覆蓋率達標，最后是功能覆蓋率達到100%。代碼覆蓋率通常情況下不要求100%，但所有空洞需要經過分析確認并記錄在驗證報告中，其它兩個標準是硬性指標絲毫不能打折扣。即使以上標準全部達到，通常還需要穩定回歸兩個星期以上，如果回歸期間出現了新的問題，一切歸零，問題修復后重新開始計算回歸周期。實際上，成熟規范的公司對出驗證出口標準的要求比這個嚴格得多，會有一長串checklist需要逐一確認，每一條check項后面，是一系列的質量保證活動，比如文檔檢視、代碼檢視、文檔代碼一致性確認、Bug收斂趨勢分析、Bug Review、Corner Case確認、End_of_Check確認、編譯仿真Warning分析、異步路徑分析、網表仿真結果、后仿真結果、寄存器遍歷、接口信號翻轉遍歷…………，這樣的checklist通常都是用慘痛的代價換來的，每一條都要認真對待。做芯片就是這樣，永遠要保持“戰戰兢兢，如履薄冰”的心態，驗證尤為如此，畢竟如果流片回來存在BUG，板子往往是先打驗證。?
數字驗證的定位
我始終認為驗證工作是一項科學嚴謹重要的研發活動，驗證人員也是核心研發人員，絕不是設計人員的附屬品，更不是產線操作工。驗證工作是芯片前端開發的最后一道保障，是保證芯片一版成功的重要基石，小的芯片或許重點依靠設計人員能夠一版成功，大的SOC成功必然是設計驗證緊密配合共同努力的結果。那些把驗證人員當designer附屬品或產線操作工的公司，得到的也基本會是附屬品或操作工的芯片質量；反之，把驗證工作看做跟設計工作同等重要地位的公司，芯片質量往往會好很多。需要掌握的技能
①linux基礎，腳本語言（bash、tcl、perl、python等，要掌握一門或多門腳本語言）；②數字電路和IC設計基礎知識；③C/C++、Verilog、System Verilog編程語言；④驗證方法學（UVM）。
審核編輯：彭靜
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容侵權或者其他違規問題，請聯系本站處理。
舉報投訴
-
數據
+關注
關注
8文章
7231瀏覽量
90621 -
代碼
+關注
關注
30文章
4872瀏覽量
69913 -
數字芯片
+關注
關注
1文章
110瀏覽量
18643
原文標題：你真的了解數字驗證嗎？
文章出處：【微信號：mcu168，微信公眾號：硬件攻城獅】歡迎添加關注！文章轉載請注明出處。
發布評論請先 登錄
相關推薦
芯片失效分析的方法和流程
? 本文介紹了芯片失效分析的方法和流程，舉例了典型失效案例流程，總結了芯片失效分析關鍵技術面臨的挑戰和對策，并總結了芯片失效分析的注意事項。
NX CAD軟件：數字化工作流程解決方案(CAD工作流程)
NXCAD——數字化工作流程解決方案(CAD工作流程)使用西門子領先的產品設計軟件NXCAD加速執行基于工作流程的解決方案。我們在了解行業需求方面累積了多年的經驗，并據此針對各個行業的具體需求提供
芯片封測架構和芯片封測流程
在此輸入導芯片封測芯片封測是一個復雜且精細的過程，它涉及多個步驟和環節，以確保芯片的質量和性能。本文對芯片封測架構和芯片封測流程進行概述。
數字設計ic芯片流程
主要介紹芯片的設計流程 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? &
發表于 11-20 15:57
?0次下載
工業產線機械臂數字孿生 流程工業應用
圖撲軟件根據實驗室構建的工業產線機械臂數字孿生環境，對數字孿生關鍵構件、工作過程進行驗證，形成此文，與大家共同探討數字孿生系統構建的關鍵技術。
數字芯片設計驗證經驗分享文章 實際案例說明用基于FPGA的原型來測試、驗證和確認IP——如何做到魚與熊掌兼
本系列文章從數字芯片設計項目技術總監的角度出發，介紹了如何將芯片的產品定義與設計和驗證規劃進行結合，詳細講述了在FPGA上使用硅知識產權（IP）內核來開發ASIC原型項目時，必須認真考
【「數字IC設計入門」閱讀體驗】+ 數字IC設計流程
：將芯片設計結果交出去進行生產制造。
上述這些只是芯片設計過程中的主要節點，細節還有很多，如果驗證測試中不通過，就需要從數字前端設計開始找原因，之后再經歷一次全
發表于 09-25 15:51
芯啟源助力復雜數字芯片設計與驗證
全球頂尖電子設計自動化盛會DAC 2024在舊金山成功落下帷幕。作為國內領先的數字前端驗證工具供應商，芯啟源攜旗下MimicPro系列產品及解決方案再度亮相，不僅受到來自全球頭部IC設計企業的工程開發人員的一致好評，更代表著國產EDA硬核技術在世界舞臺亮相從而引起廣泛關注
芯片設計流片、驗證、成本的那些事
前言我們聊聊芯片設計、流片、驗證、制造、成本的那些事；流片對于芯片設計來說就是參加一次大考。流片的重要性就在于能夠檢驗芯片設計是否成功，是芯片
名單公布！【書籍評測活動NO.40】數字IC設計入門，多角度透視芯片設計
系統地介紹了IC設計及仿真驗證過程。初學者可完整、詳細地學習IC設計及驗證流程，不僅有數字IC的設計介紹，還有模擬IC的設計介紹，內容涵蓋全面。同時書中對IC設計常用工具及操作方法進行
發表于 08-08 15:31
大規模 SoC 原型驗證面臨哪些技術挑戰？
引言隨著電子設計自動化（EDA）驗證工具的重要性日益增加，開發者們開始尋求減少流片成本和縮短開發周期的方法。其中，使用可編程邏輯芯片（FPGA）來構建有效的驗證流程成為一種流行的解決方
SMU數字源表測試IC芯片電性能方案
芯片測試作為芯片設計、生產、封裝、測試流程中的重要步驟，是使用特定儀器，通過對待測器件DUT(DeviceUnderTest)的檢測，區別缺陷、驗證器件是否符合設計目標、分離器件好壞的
芯片測試和芯片驗證的區別
這是芯片在設計過程中的一個環節，主要通過EDA（電子設計自動化）工具進行仿真檢驗。它的主要目的是在芯片生產之前，驗證芯片設計是否符合預定的需求規格，是否已經消除了所有的風險，發現并更正
基于自研芯片+頂級AMD FPGA，西門子EDA發布“快而全”的Veloce CS
電子發燒友網報道（文/吳子鵬）在大型芯片設計過程中，驗證被認為是整體流程中最復雜、最耗時的環節之一。有數據顯示，目前功能驗證約占整個芯片開發
工商網監
評論