Global Sources
電子工程專輯
 
電子工程專輯 > EDA/IP
 
 
EDA/IP  

驗證計畫工作正邁向自動化

上網時間: 2005年12月22日     打印版  Bookmark and Share  字型大小:  

關鍵字:驗證  程式碼覆蓋  聲明  模擬  特殊規格語言 

如果像某些研究報告所指出的,功能驗證已經佔IC邏輯設計流程的絕大部份,那麼當晶片規模達到1千萬閘甚至1億閘時會產生什麼情況呢?

答案非常混亂,但有一點是明確的:功能驗證過程必須變得更可管理化。一些專家們認為,以覆蓋為驅動的驗證(CDV)對今天的設計會有所幫助,但長期的答案需要在重新考慮驗證和設計基礎上才能得到。

隨著晶片複雜性的不斷提高,可能會出錯的事件的數量將呈指數式成長,因此驗證非常有必要。能否在不雇用大量驗證工程師去做指導性測試的情況下完成驗證呢?

形式驗證可以提供有目的的詳盡測試,但它並不能覆蓋全部範圍。加速和模擬能加速驗證過程,但工程師仍需要製作和監視測試過程。面對為數眾多的設計類型、工具和驗證技術,有一點是肯定的,即設計師必須要有計畫。

驗證計畫要做的首先是確定哪些設計部份要測試以及如何做測試。計畫中要確定被測設計需要使用的輸入條件,並盡可能找出可能無法被模擬覆蓋到的偏僻案例。另外,還必須在CDV基礎上制訂出測試進度的計畫。

現在的工程師都很熟悉程式碼覆蓋技術,它能透過檢查發現是否存在未被執行到的程式碼。難度更大的新技術則是功能覆蓋,它適用於檢查各種偏僻案例,例如確定FIFO是空還是滿。

由於功能覆蓋可以提供反饋資訊,因此隨機測試產生更具實用性,能發現隱藏更深的缺陷。另外,基於聲明的驗證的崛起還可以提高聲明覆蓋率,配合其它技術,核查聲明是否確實在起作用。

更高層次的抽象

但這僅僅是開始。一些觀察人士認為,為了真正管理驗證過程,有必要轉向更高層的抽象,並應起始於系統級而非模組級。還有些人認為必須改善設計過程本身,使得首次輸出存在更少的缺陷。

正如Janick Bergeron的‘編寫測試平台:HDL模型的功能驗證’一書所述的那樣,驗證計畫是概括驗證工作的書面性規格。它的主要內容是分割設計、為驗證定義粒度水準、設定策略和工具,並回答也許是最難回答的問題:怎樣知道驗證何時完成?

“驗證計畫應該包括所有被懷疑會對設計構成風險的對象,”新思公司科學家、在線驗證指導論壇主席Bergeron表示。這樣才有可能確定驗證這些對象所需的偏僻案例和覆蓋點。Bergeron指出,目前擬制驗證計畫的工作絕大部份還是“手工作業”。

“這種計畫一般以文字形式提供,”Cadence設計系統公司首席架構師Jay Lawrence表示 ,“目前擬制計畫過程的自動化程度極低,因此我認為這對輔助工具來說是個很好的機會。”

正處於Cadence收購計畫中的Verisity設計公司已經藉由VManager產品朝這個方向邁出了腳步。據Verisity公司負責驗證過程自動化的高級副總裁Ziv Binyamini透露,VManager支援可執行驗證計畫格式。這使得它能夠讀寫機器可識別的計畫。

“VManager可以匯聚和控制包括模擬、形式驗證和加速在內的許多不同驗證任務的執行,然後收集來自功能、程式碼和聲明等不同資源的覆蓋數據。”Binyamini說。

光有驗證計畫、沒有以覆蓋為驅動的方法來對計畫實施監視是毫無意義的,專家們指出。

Binyamini直接了當地說:“沒有覆蓋指導的驗證就象盲人開汽車一樣。如果你不知道怎樣才能到達目的地,那麼你就只能在原地打轉。”

確保設計品質是驗證團隊所面臨的主要挑戰,CDV正是解決這個挑戰的答案,Bergeron表示。“用戶執行上千個測試,但品質卻得不到保證。”他說,“他們無法測試到偏僻案例。唯一可行的方法是用功能覆蓋收斂迴路,並驗證要做的每個性能和偏僻案例是否都得到了執行。”

目前大多數設計人員正使用程式碼覆蓋工具,Bergeron指出。這些工具在程式碼中插入檢查點以便判斷結構句是否得到了執行。這些工具通常提供語句、路徑、分支和表達式覆蓋。

但程式碼覆蓋不能識別丟失的程式碼或功能。這也是一些驗證團隊轉而採用功能覆蓋的原因。功能覆蓋透過插入‘覆蓋點’來確保各種事件產生或不產生(如FIFO是空還是滿),確保特殊指令集透過管線,確保數據封包經過設計所有訊息通道發送等。

明導國際公司首席工程師Richard Ho認為,如果沒有功能覆蓋,設計師只能做指導性測試和已經想好了要做的測試。功能覆蓋則提供了‘受限隨機驅動的’模擬方法。該方法能夠進行隨機測試,然後根據來自覆蓋測試的反饋資訊進行交互修改。

然而程式碼覆蓋和功能覆蓋都存在缺點,驗證諮詢顧問Brian Bailey表示。“程式碼覆蓋可以讓你知道你是否可以控制你的設計,但它不能告訴你你已經正確地獲得了某行程式碼。”他說,“功能覆蓋是一種觀察性的方法。它能讓你發現這個事件,但不會告訴你該事件產生的正確理由。”

有難度的測試

功能覆蓋的問題在於它是一個手工過程。它必須靠人採用SystemVerilog、專有規格語言(PSL)或Verisity公司的‘e’語言等中的結構句插入覆蓋點,然後需要一個模擬器來翻譯這些結構句。

“這樣做的工作量很大。”新思公司的Bergeron說,“雖然可以使用模板加以簡化,但實現非常困難。”

“這通常還存在10%到30%的模擬開銷,”明導公司的Ho指出 ,“但從宏觀的角度看,模擬開銷相對於你不知道該做什麼,更節省了時間。”

功能覆蓋通常是驗證工程師的工作,Ho表示,但他們一般不具備準確插入覆蓋點的專業知識。設計師也許不會對此花心思。在最近的DesignCon會議上發表的文章中,Ho推薦了一個好方法。該方法採用一般由設計師插入的聲明來確定設計中的功能覆蓋點。

“聲明與覆蓋是事物的兩個方面。”Ho表示。聲明可以用來檢查不良的行為,而功能覆蓋點則用來指出想要的行為,他指出。該文討論了設計師如何使用聲明庫自動插入覆蓋點,獲取事務覆蓋點,以及使用PSL和SystemVerilog中有關聲明和覆蓋的屬性。

將聲明用於覆蓋還有一個概念,就是‘聲明覆蓋’,根據陳述對象的不同聲明覆蓋具有不同的含義。諮詢師Bailey認為,理想情況下聲明覆蓋能夠告訴你對象已經從頭到尾成功地得到了驗證,而實際使用時聲明覆蓋工具可能只是告訴你聲明是否已經觸發。

正如Ho指出的那樣,從來沒有觸發的聲明是‘偽’真。因此我們需要一種方法,能夠用來確保聲明真正進入檢查相關事件的狀態。

Lawrence 表示,Cadence的Incisive驗證套件能夠報告某個聲明離開故障狀態的次數,還能確定聲明是否觸發、預置狀態是否設置正確。但聲明覆蓋一般只對‘實際的’聲明有效,他說,而對描述從未產生的特定行為的聲明無效。

形式驗證新創企業Jasper設計自動化公司首席方法學家Harry Foster認為:“聲明檢查‘什麼’,而覆蓋檢查‘怎樣’。”聲明定義了什麼是必須檢查的,而覆蓋點描述需要什麼樣的輸入激勵來啟動關鍵功能。

Foster是基於聲明驗證的倡導者之一,他表示不能肯定‘聲明覆蓋’是什麼意思,但是否有足夠的聲明用來檢查設計是一種可能的意思,有時也被稱為‘聲明密度’。

他指出,因為沒有輸入激勵,形式驗證不需要功能驗證。嘗試所有可能組合的數學模型是形式驗證的基礎。“人們真正需要的是針對書面聲明的覆蓋。”他說。

提高抽象層次

一些觀察人士認為,從長遠觀點看,提升抽象層次是促進驗證管理的最佳方法。提倡電子系統級(ESL)驗證的Bailey堅持認為,基於模組的驗證已經使EDA產業產生了倒退。“我們面臨先有雞還是先有蛋的問題。我們正試圖驗證我們不知道是否需要驗證的事物。”他說。

Dataquest公司首席EDA分析師Gary Smith一直在提倡人們使用‘智慧測試平台’。這是一種超級工具,它能自動分割設計,並調用最適合具體單元的驗證工具。他認為這種先進工具肯定會出現在ESL驗證領域,雖然工具的架構至今還沒有定義好。

不過真正的解決方案也許涉及設計過程而非驗證。在多個DesignCon小組討論會上,參與者和聽眾都認為目前首要的是製作出更佳的設計。

“我們面臨是發現缺陷還是從一開始就做正確的問題,”Jasper設計公司Foster說,“我們應該問一問我們在設計過程中能夠避免多少缺陷,而不是在驗證過程中發現多少缺陷。”

在是否能夠以及如何改善設計才能減少驗證需求的問題上存在不同的觀點。Foster相信形式驗證把握住了“邊設計邊驗證”方法的精髓。如果他是正確的,那麼驗證管理問題的最終解決方案也許是與更好的驗證工具完全不同的。

作者:葛立偉





投票數:   加入我的最愛
我來評論 - 驗證計畫工作正邁向自動化
評論:  
*  您還能輸入[0]個字
*驗證碼:
 
論壇熱門主題 熱門下載
 •   將邁入40歲的你...存款多少了  •  深入電容觸控技術就從這個問題開始
 •  我有一個數位電源的專利...  •  磷酸鋰鐵電池一問
 •   關於設備商公司的工程師(廠商)薪資前景  •  計算諧振轉換器的同步整流MOSFET功耗損失
 •   Touch sensor & MEMS controller  •  針對智慧電表PLC通訊應用的線路驅動器
 •   下週 深圳 llC 2012 關於PCB免費工具的研討會  •  邏輯閘的應用


EE人生人氣排行
 
返回頁首