oC開發來說,巨大的掩膜制造成本要求首次流片取得成功。急劇增加的驗證復雜度與日益縮短的上市時間也敦促業界尋找更加有效和自動化的驗證方法。

形式驗證(FV)的自動化就是以上問題的一種可行解決方案。作為成熟的偽隨機驗證技術的補充,FV讓驗證工程師(或設計師)能夠對電路的特定部分進行詳盡的驗證。本文將討論OCP等總線協議的自動化形式驗證。

屬性的概念

為了對任意IP進行形式驗證,設計師或驗證工程師必需從該IP的規范中提取各種屬性。每一種屬性描述了該IP的一個或多個特點。最好是先提取高層的系統屬性,因為這些屬性每個都涵蓋了該IP的一組特點。低層的屬性接近RTL,因此往往被證明用處不大。

設計師提取出的每一種屬性均可以被形式驗證工具(例如Cadence的Incisive Formal Verifier)用作斷言(檢查)或假設(環境約束)。大多數時候,假設被施加到待測設計(DUT)的輸入端,斷言則被施加于DUT的輸出端。例如在OCP協議中有一個屬性,它規定應答狀態只能在出現相應的請求狀態之后啟動。在驗證帶OCP從接口的IP(見圖1)時,該屬性就被用作斷言(檢查),因為應答狀態是該IP的一個輸出。

圖1:驗證帶OCP從接口的IP。

OCP協議的形式驗證

在驗證帶一個或一個以上OCP接口的IP時,理論上只需簡單地提取其OCP屬性,并對其進行形式上的檢驗即可,但實際情況并非如此。形式驗證中最困難的部分在于OCP規范的復雜性。OCP接口極強的可配置性讓我們能夠創建一個十分靈活的系統,但同時也加大了驗證的負擔。確定一組合適的OCP屬性非常重要,因為OCP屬性的錯誤選擇可能導致一些邊界情況被遺漏,從而使驗證出現漏洞。

很明顯,要求為所有可能的OCP配置確定一組完整的OCP屬性列表。OCP-IP組織很早就認識到這一需求。為此,OCP-IP功能驗證工作小組(FVWG)創建了一個OCP-IP一致性計劃(OCP-IP compliance plan)。該計劃對所有OCP屬性進行了定義,同時也大致描述了每一個屬性應由哪些配置參數激活。同樣,在OCP接口配置的基礎上,只有相關的一組子屬性可以被識別和證實。更全面的描述請參考OCP-IP 2.2規范中的第13、14和15章。

OCP VIP庫

今天的許多高性能SoC(例如德州儀器公司的OMAP多媒體應用處理器)都是基于OCP的。在使用時,幾個主要器件或主要子系統通過基于OCP的連接與多個從器件(外設和存儲器等)相連,見圖2。

圖2:利用基于OCP的互連實現的內核底層規劃。

為了盡可能減少所有這些OCP接口的驗證工作量,幾家EDA廠商決定創建一個OCP VIP庫。這個庫(見圖3左側)中包含了OCP一致性計劃中定義的所有屬性,其代碼通常是由一個或多個專業驗證工程師采用PSL/SVA+輔助VHDL/Verilog語言編寫的。這種代碼編寫是一次性工作。

圖3:廠商提供的庫與OCP驗證環境的相互作用。

為了選擇一組適合某個特定OCP接口的子屬性,可以用一個腳本對OCP配置文件(即IP_)進行解析。最終被選出的一組屬性可被形式驗證工具用作斷言或假設。

這個VIP庫中還包含了很大的一組cover。這組cover可以檢測出過份約束的環境,因此特別重要。此外,cover還能幫助檢測到虛警狀態(即沒有滿足條件時出現的斷言),從而可以避免出現無意義的錯誤。

最后,不要低估開發一套魯棒性協議VIP的重要性。盡管OCP-IP定義屬性的工作做得不錯,但在實現時仍可能出現大量問題(例如PCL、輔助Verilog甚至屬性子集選擇解析器中的錯誤)。這些問題直接表明一個庫必需經過嚴格測試,在測試階段,該庫被應用于具有不同配置的多個IP。大型EDA廠商通常很適合這一工作,因為他們往往擁有很大的內部IP回歸數據庫。通常要配合工業客戶進行詳盡的測試才能完成整個測試過程。

TI提供的一些OCP VIP經驗

圖4:Cadence的OCP協議VIP集成到TI的設計中。

如圖4所示,在TI法國公司的無線終端業務部門(WTBU),我們可以輕松將Cadence的OCP協議VIP集成到我們內部的設計流程中。從下圖可以看出,必須要定義的(模板)文件只有:

·.f: 用于驅動IFV

·.tcl:用于初始化電路

·.psl:用于對非OCP的主要輸入(如復位、測試和電源管理)建模

而用戶只需要:

·調用一個Makefile目標對RTL進行分析和詳細描述

·調用一個Makefile目標來解析IP_并獲取正確的子集

·編輯模板文件(.f/.tcl/.psl)

·最后利用IFV執行形式驗證,以檢驗OCP的一致性

為了讓讀者對驗證流程的簡單性與有效性有一個大致的了解,請看以下例子。工程師在驗證一個帶基本從OCP接口的IP時平均要用30分鐘到1個小時的時間。其中大部分時間都用于編寫設置主要輸入約束的PSL模板文件。需要注意的是,這是100%徹底驗證的結果。更加傳統的偽隨機仿真環境則要求將OCP eVC實例化,編寫隨機測試用例,最重要的是對功能覆蓋率進行嚴格定義。由于功能覆蓋的定義存在一些差異,因此動態回歸在OCP接口驗證時很可能會遺漏一些邊界條件。我們發現在許多模塊的動態仿真中常被遺漏的邊界條件是,在OCP傳輸仍未完成時IP就經歷軟件復位情況下的OCP接口行為。此外,在具備多個OCP接口的模塊中,如果一個接口用于配置模塊,另一個用于傳輸實際數據流,那么在采用基于偽隨機的仿真方法時也容易出錯和留下缺陷。最后一個同時也很難找到的缺陷是FSM死鎖,這種缺陷用形式驗證的方式比用偽隨機仿真的方式更容易發現。

我們在多個無線OMAP項目中采用了OCP VIP方法,每個項目中約有50個IP,每個IP具備一個或一個以上的OCP接口。結果我們發現的問題涵蓋了從難以發現的邊界條件到結構性缺陷很大的范圍。

利用協議VIP進行較高層特性的形式驗證

一個IP通常包含:一個clk & rst接口、一個電源管理(PM)接口、一個用于配置其內部寄存器的接口,以及一個或多個用于與外界(串行協議或存儲器)通信的功能總線。

對于SoC中常用的標準協議來說,很可能存在相應的協議VIP(OCP,AXI,AHB)。而對于一些內部協議而言,相應的VIP(例如電源管理)也是可以開發的。通過使用這些VIP(見圖5),驗證工程師既獲得了“自由”環境,也得到了“自由”的低層協議檢查。

5:協議VIP可以改善驗證環境。

在此基礎上,工程師又可以編寫更高層次的系統屬性。最佳情況下,系統級的屬性甚至無需對遺漏的接口(func1 & func2)進行建模就能得到驗證。這時的驗證更加抽象,因為它是在約束不足的環境下進行的。但如果反例顯示出現了有效的違例情況,那么就必須對剩下的接口進行建模。

我們開發的一些最常用的高層屬性例子包括:

·通過橋接進行分組轉換

·存儲器和緩存的一致性

·性能和延遲屬性

·數據完整性(該屬性不是很適合形式驗證但仍值得一試)

本文小結

采用VIP進行自動化形式協議驗證能使關鍵IP接口得到快速詳盡的驗證。VIP庫在編寫和測試之后可用于改善驗證質量并縮短驗證時間。由于最后的VIP提供了一個“自由”的環境,因而還能用于簡化高層系統性能的驗證。

作者:Jeroen Vliegen

WTBU部門形式驗證工程師

TI法國公司