晶元驗證全視之七 驗證的週期(下)

2021-08-26 15:18:54 字數 2042 閱讀 1648

本文**:

這一節我們繼續剩下的驗證週期裡的四個階段。

遞迴測試

遞迴測試指的是去驗證之前的硬體功能在某個缺陷修復或者新增了某項新功能以後,仍然可以通過以前的所有測試用例(test case)和可能新增的新的測試用例。這些可能存在的環境變化包括硬體設計自身的改進、缺陷修復、功能新增和驗證環境的更新。在每次的遞迴測試中可能會發現新的缺陷、新增新的測試用例或者更新驗證環境。每次遞迴測試都會幫助完成兩個目標:

是去確保這次改動沒有引入新的缺陷,而且也修復了之前的漏洞,或者按照預定目標實現了新的功能

由於隨機驗證在每次遞交時,預設的隨機種子是不同的,這對於重複遞交一套遞迴測試表也是有意義的。伴隨著功能覆蓋率,可以通過保持往復的遞迴測試表和定向新的隨機約束域兩種方式來將驗證完成率逐步提高。

遞迴測試在這裡是一項流片前驗證完備性檢查的重要輔助手段,因為只有通過大量的測試用例同時提交到伺服器群組,才有可能完成覆蓋率的快速上公升,並且滿足專案進度的要求。

晶元生產

當經歷過遞迴測試階段(rtl遞迴和門級網表遞迴)兩部分之後,這意味著晶元的邏輯部分和物力部分資料都經過各項檢查了。在將晶元最後送交給半導體生產商(fabrication facility, fab)之前,專案經理也會同設計經理,驗證經理,後端經理一同回顧整個檢查表,確保所有的標準都已經通過。晶元的資料部分被提交給生產商以後,就最終會被製造出來,此時我們稱之為流片(tape-out)。

但值得注意的是,此時功能驗證的流程並沒有全部走完,也並非停止,而是仍然需要提交遞迴測試,通過不停地保持隨機測試的運算量在可能覆蓋的新的狀態空間上測試是否有可能會發現新的問題。如果確實是在遞交給廠商生產以後又發現新的問題,這樣的問題我們也會同矽後的系統測試發現的問題一樣對待,通過分析這些缺陷,來考慮是否有軟體補救辦法,或者提交設計修改意見,在下一次流片前準備好設計的更改方案和驗證方案,將其計畫到下一次驗證週期內。

矽後系統測試

在晶元返回之後,系統測試人員也會依照系統整合的順序從底層模組開始測試。在測試之前,我們需要將晶元同測試開發板結合起來,或者將晶元植入到待開發的系統上面。而後,矽前人員(設計人員、驗證人員、系統人員)和矽後人員(測試人員)需要保持頻繁的溝通。因為一旦測試出了問題,需要第一時間判斷是測試的方法不恰當,還是歸屬於硬體自身問題。之所以要求矽前人員也參與進來,是因為我們實際上不希望矽後測試出現太多的問題,尤其是致命的缺陷。那麼當乙個硬體缺陷被發現之後,矽前人員就需要討論這個缺陷的嚴重性、從軟體層面上討論可行的補救辦法、最後再到硬體層面是是否有其他辦法使能這項功能或者不使這項功能擴大影響面導致整個晶元的致命缺陷。如果,我們最終無法避免這項缺陷,而且這項缺陷很嚴重的時候,我們就需要在下個晶元設計週期內去修改和驗證這項功能

逃逸分析

有些時候,我們難以避免一些驗證漏洞一直被忽視,導致它們可以從矽前驗證階段通過到了矽後測試直至被發現出來。遇到這樣的情況,硬體設計人員和驗證人員都需要去跟測試人員溝通,嘗試在矽前的**環境中重現遇到的測試失敗場景。如果可以復現,那麼設計人員和驗證人員需要再檢查這個漏洞之所以逃脫的原因;如果無法復現,那麼我們仍舊無法保證硬體做出的更改是否可以在下次流片以後修復這次測試問題。

這種矽後測試失敗要求矽前驗證重現的情況相比較在交給客戶之後遇到的應用失敗場景還是容易一些的,因為一旦從硬體級別向上堆疊經過驅動層、韌體層再到客戶的應用側,我們更加難以重現客戶應用失敗場景的重現,而如果作為驗證人員你有幸遇到過這樣的場景重現和失效點定位的問題,那麼想必你會深深記住它的。

當逃逸分析完成以後,這一過程會對下乙個晶元週期中,設計人員如何規避設計陷阱、完善設計經驗,驗證人員如果充分完善驗證方案、產生盡可能多的測試序列都是很有意義的,而在整個晶元過程中都貫穿著吸取教訓四個字,因為要完成晶元從矽前到矽後的過程本身就很漫長(相比軟體的迭代開發而言),那麼要積累盡可能多的經驗,對於每一位晶元工程師,都應該在每乙個關鍵節點就養成總結的習慣,並且在下乙個階段有意識地去完善,保持一種不斷成長的姿態

晶元驗證全視之三 驗證能力的五個維度

本文 可能在貫穿到整個驗證系統思想裡面,我們都會不斷重複驗證人員該具備的素質。為了可以將抽象的詞彙具象出來,我們列出了驗證人員在驗證流程中需要具備的五個技術維度。接下來讓我分別解釋這五個維度 從上面的五個維度來看,做一名合格的驗證人員實屬不易,更不要說考慮到每乙個專案每一項驗證任務來分別針對制定出合...

驗證的週期

功能驗證有著一整套完備的流程,而且從硬體系統定義貫穿到矽後測試部分。一般來講,乙個驗證團隊會基於時間差同時進行多個專案,多個專案之間自然也存在著借鑑 更新的關係,所以驗證的環境和復用性也是在不斷提高的。而每乙個專案在進行瀑布模式的開發時,驗證團隊也會在不同細分的流程當中完成每一項任務,同時在進入到下...

SCUER的晶元驗證之路

開頭講一講自己學習晶元的驗證的路程,現在scu的三維感測與機器視覺實驗室,咋一聽應該和ai有著很大的關係,沒錯,三維感測與人工智慧密不可分,研一剛進去對ai充滿了無限的熱情,學習機器學習和深度學習的知識,乙個光學前沿的分享課,導師作為863專案中光刻機子專案的負責人給我們講述了很多國產晶元的路程。也...