功能驗證被廣泛認為是SoC設計的主要瓶頸之一。在SoC產品化的過程中,很大一部份工作都花費在驗證上。根據Wilson Research Group的統計,在2014年,典型的SoC專案中有57%以上時間都耗在驗證上。

20170215 ARM TA31P1 圖1:設計專案中驗證時間所佔的百分比 (來源:Wilson Research Group)

雖然付出了如此大的努力,但對於首次設計,功能故障的風險仍然普遍存在。自從多處理器晶片(包括異質設計)問世以來,SoC的複雜度顯著增加。從圖2可以看到隨著時間推移以及製程的演進,SoC中的IP元件數量迅速增加。

20170215 ARM TA31P2 *圖2:典型系統中的IP元件數 (來源:ChipDesignMag) * SoC已經演變成為複雜的實體,整合了多種不同的IP。當今的SoC可能包括多個元件,例如CPU、GPU、互連、記憶體控制器、系統MMU、中斷控制器等。IP本身也是複雜的設計單元,需要經過獨立驗證。即使經過IP級的嚴格驗證,也不可能檢測出全部的錯誤(bug)——特別是有一些錯誤只出現在系統內部IP之間互動時。本文旨在讓讀者瞭解ARM所進行的系統級驗證工作,並進一步帶動廣泛的應用。

很多SoC設計團隊結合使用自家研發和現成的商用工具與方法,分別解決各種驗證問題。系統級驗證目標在於為合作夥伴提供經過驗證而能正確互動操作的高品質IP。這樣可以奠定標準基礎,讓合作夥伴能夠在此基礎上建構自己的系統驗證SoC解決方案。以此堅實的基礎為起點,合作夥伴的設計和驗證工作就能更側重於SoC的設計差異化,以及IP與系統其他部份的互動。

驗證流程

ARM的驗證流程與業界廣泛採用的流程非常相似,如圖3所示。

20170215 ARM TA31P3 圖3:ARM驗證流程金字塔

設計的驗證作業必須從早期以及細部單元開始,這些單元共同構成了獨立的IP。在整個驗證週期中,只有在單元級,工程師才能夠獲得設計的最佳能見度。除非訊號位於設計底層,否則可在單元級對各訊號進行探測,或將其設置為理想值以協助驗證。當單元級驗證達到一定的成熟度之後,這些單元可以組合在一起形成完整的IP(如CPU)。只有在此之後,才能開始IP的IP級驗證。對於CPU而言,這通常是能夠進行組合語言程式級測試的開始時間。在此之前,大多數測試只能透過控制各個線路/訊號進行。在IP級,測試是使用組合語言編寫的。處理器從記憶體(模擬)獲取指令,並對其進行解碼後執行。在IP級驗證到達一定的穩定度後,多個IP組合形成一個系統,開始進行系統驗證作業。

在IP的設計、驗證階段會經過多個里程碑,能夠反映其功能完整性和正確度。其中,Alpha和Beta是內部品質里程碑。LAC(限制存取)是引導合作夥伴存取IP的里程碑;其後則是EAC(早期存取)里程碑,意味著IP已經準備好用於製造,以便獲取工程樣本和測試。在達到REL(發佈)里程碑之前,由於IP已經過嚴格測試,能夠投入量產。

在通過系統驗證流程之前,IP品質通常處於Alpha和Beta之間。在設計週期階段,IP已經過大量測試了,大部分的低層級錯誤已被發現。必須非常縝密細心地構建激勵,才能盡可能地覆蓋每個IP微架構的內部狀態。激勵既可由組合程式碼提供,也可以使用整合於系統中的專用驗證IP。ARM結合使用了這兩種方法。

有些錯誤如果未被檢測到,可能導致最終產品出現嚴重故障。基於以往的經驗,ARM估計需要1至2千兆(peta)個週期驗證,以及4至7個人進行數月的除錯,才能發現這些類型的錯誤。很多情況下,嚴重的延遲會讓晶片錯失在目標時間內推向市場的機會。在整合至一部份的SoC之前,應該在設計週期及早發現這些錯誤,這對確保IP的穩定基礎至關重要。

系統驗證

ARM IP的本質意味著它可用於各種不同的SoC中,從物聯網(IoT)裝置到高階智慧型手機,再到企業級產品。系統驗證的關鍵目標是確保技術能夠一致地、可重現地執行設計的功能,在對IP進行嚴格驗證時,必須始終牢記這個目標。換言之,驗證的重點目標是IP,但必須在實際的系統環境中進行。為此,ARM在多種不同的實際系統配置下對IP進行測試,這些系統配置被稱為套件(kit)。

套件被定義為以子系統形式整合在一起的「IP組合」,針對特定目標的應用市場(例如行動、IoT、網路等)。它通常包括ARM內部開發的一整套IP——CPU、互連、記憶體控制器、系統控制器、中斷控制器、除錯邏輯、GPU和媒體處理元件。

套件可進一步細分為更小的元件,稱為「元素」(element),可以被視為套件的構建模組。它包含至少一個主要IP,周圍有空白邏輯,不過有些元素也是由多個IP整合在一起的。這些套件專為代表不同應用的SoC而設計。一種結果是讓ARM能夠更全面地瞭解整合不同IP元件的生態系統在實現目標系統性能時所面臨的挑戰。

20170215 ARM TA31P4 圖4:系統驗證的多層次途徑

系統驗證團隊結合使用激勵和測試方法,形成強大的測試套件。激勵主要是在系統中CPU上執行的軟體測試。這些測試可以使用組合語言或更高層級的語言等手動編寫,或者使用隨機指令序列(RIS)工具產生。除了編寫在CPU上運行的程式碼,我們還使用一組驗證IP(VIP),為系統注入激勵並觀察執行情況。

在準備驗證時,必須為套件中的每個IP創建測試計畫。測試計畫包含不同的IP配置、待驗證的功能、涵蓋的場景、激勵與IP的互動、驗證指標、追蹤機制以及驗證中的各種流程。對套件的測試從簡單的激勵開始,然後逐漸升級到更複雜的場景和壓力測試。

測試將執行各個子系統級的評估,例如性能驗證、功能驗證和功率估測。透過報告記錄選定套件的參考資料,包括性能、功率和功能品質,並在內部公佈。

ARM的系統驗證團隊已經建立了可重複的自動化套件開發流程,讓我們能夠構建針對不同市場的多個套件。ARM目前每年建構和驗證大約25個套件。

選擇IP及其內部配置,以及系統的拓撲結構等不同組合,能夠反映廣泛的最終用途。這些套件在兩個主要平台上進行測試——硬體模擬(Emulation)和現場可編程邏輯陣列(FPGA)。通常,測試會先在硬體模擬器(Emulator)上開始,然後在FPGA上完成Soak Testing(浸泡測試)。每個IP平均經過5-6兆次硬體模擬器週期和2-3千兆個系統驗證FPGA週期。為了執行這個級別的測試,ARM開發了一些內部工具。

系統驗證工具

系統驗證主要使用三種工具,分別著重於指令管線、IP層級和系統級記憶體系統、系統一致性、介面級別等互通性等。其中兩種工具是隨機指令序列(RIS)產生器。RIS工具可通過自動化方式探索架構和微架構設計領域,試圖觸發設計中的故障。相較於手動編寫的定向測試,它們能夠更加有效地覆蓋測試空間。這些程式碼產生器可以產生測試,以便透過自動化方式,對架構和微架構的不同區域進行探索。這些測試是多執行緒的組合程式碼,包括隨機的ARM和Thumb指令,目的在於充份執行設計中不同部份的功能。

第三種工具是輕量級的核心,可用作開發定向測試的平台。這種驗證方法結合使用定向測試和基於隨機指令的自動化測試,可支援基本的記憶體管理和執行緒排程,以及一部份Pthreads API,讓用戶能夠開發參數化的定向測試。

方法

為了在系統級對於IP進行壓力測試,採用更隨機而非定向方法。這將足以覆蓋廣泛的場景、激勵多種時序條件並創建複雜的事件。為此,套件可以支援多種有利於驗證的功能,例如在不同介面上更改時脈比、實現錯誤注入以及停用不需要進行功能驗證的元件等。此外,還可以更改系統中不同介面(例如CPU、互連和動態記憶體控制器)的匯流排時脈比,以激勵實際的系統時脈條件。

20170215 ARM TA31P5 圖5:系統驗證發展

圖5顯示系統最初如何發展、調度,以及測試複雜度如何隨之逐漸增加。 整合測試和KVS 初始測試從一系列簡單整合的測試開始,其目的在於確認套件的基本穩定度,並消除較小的整合問題。隨後採用一套名為Kit Validation Suite(KVS)的測試軟體,徹底測試套件的整合度。這些測試在驗證週期的早期進行,以確認套件是否足夠強大,足以執行更大壓力的工作負載。KVS可以配置為在多個套件上執行。它包括了多個子套裝軟體,分別用於測試整合、功耗、CoreSight除錯與追蹤、媒體IP。KVS還提供特定的測試,用於測試GPU和顯示器的整合,以及GPU的一致性。初始啟動通常得先做模擬,然後逐漸轉移至用於整合測試的硬體模擬器。

RIS Boot和BringUp測試 隨後,以套件上的基本上線(bring up)測試啟動所有的RIS工具,以檢測所有的硬體/軟體配置問題。

RIS:預設和重點配置 套件穩定後,測試的複雜度逐漸增加,對於系統的壓力也會隨之提高。相較於定向激勵,隨機激勵可以更快地覆蓋設計空間,在激勵創建方面的工作量也比較小。因此,壓力測試更加依賴於隨機激勵,而不是定向激勵。首先執行RIS工具的預設配置,在經過適當數量的驗證週期後,將重新配置工具,以便對套件中的特定IP進行壓力測試。

RIS浸泡測試 在系統驗證的最後階段,套件在FPGA上進行浸泡測試。雖然硬體加速器更加有利於除錯,但FPGA的速度更快,能提供更多驗證週期。因此,待IP穩定成熟後,在FPGA上進行浸泡測試,以尋找那些複雜的極端案例(Corner Case)。

指標、追蹤、覆蓋和里程碑

為每個套件執行的驗證週期數量是值得追蹤的主要指標之一,目的在於確保達到目標驗證週期數量。這對於確保達到浸泡測試週期的目標尤其有用,從而增強IP在各種應用中的品質信心。此外,利用統計覆蓋方法進行量化和追蹤,則確保整個設計(包括潛在的極端案例)都經過充份測試。

例如,最新版本的ARM Juno晶片經過總計6,130小時的驗證執行時間,相當於8.5個月的測試。這為我們提供可看到系統內部極端情況的獨特視角,因而能夠更有效地為嘗試除錯自家設計問題的合作夥伴提供支援。此外,在驗證流程中發現的錯誤也可以回饋給IP設計團隊,讓他們利用這些資訊改善IP品質,並為下一代產品提供指導。

小結

隨著時間推移,驗證方法已經演進為一種為系統大部份IP測試多個元件與壓力的方法了。而當系統複雜度隨著SoC性能一起增加,導致花費在驗證上的時間和投資大幅增加。ARM在向合作夥伴發佈IP之前均先行驗證IP的互通性,以確保適合各種應用,同時也確保設計IP能夠在合作夥伴建構的系統中協同運作。