雖然IC設計複雜性日益增加,但設計IC被分配到的時間仍與以往大致相同,這迫使工程師加速所有相關流程。筆者所在的團隊最近移植了一個硬體模擬(emulation)環境,好讓測試流程能更快、更有效;本文將分享一些我們從中學到的經驗。

花費太多時間在設計測試上可能會錯過產品及時上市的商機,而花費的太少時間又可能會遺漏設計錯誤;到了光罩階段才發現錯誤則會付出昂貴代價──製作7奈米(nm)光罩的最低成本現在約為1,000萬美元,而且這還是以相對較小的IC來說。

隨著業界轉向更複雜的SoC設計,有效地利用測試時間變得越來越重要。有多種途徑可以測試設計,我們必須選擇最佳方法來最佳化測試和花費的時間。硬體模擬作為一種改善測試時間的方法脫穎而出,雖然這種方法並不簡單。

它需要我們在測試程式(testbench)的設定和設計流程中做一些改變,包括SVA (System Verilog assertions)中的一些修改;我們還確認了哪些層級的測試程式以硬體模擬執行測試,可以提供最佳的投資報酬率(ROI)。

本文從概述開始,並以幾個程式碼範例總結;且將提供注意事項並建議如何有效規劃。使用一個經過改善的Virtual Interface (Vif ++)在移植過程提供幫助;在產業標準驗證方法──通用驗證方法(UVM)中,虛擬介面(Vif)是一個介面中元件之間的程式碼共用片段。

本文中提到的「硬體模擬器」(emulator)能與任何能夠執行RTL或閘級模型的軟體模擬工具(simulator)互換使用,包括軟體HDL模擬工具。以硬體為基礎的模擬方法,最大優勢就在於具備加速整體流程的潛力,這也會是我們的討論焦點。

為何選擇硬體模擬?

要驗證複雜的晶片設計,我們現在有許多工具和技巧可以使用,包括軟體模擬工具、硬體模擬器、SVA、功能覆蓋(functional coverage)和形式化驗證(formal verification)等等,所有這些工具或技巧運用於不同層級,能讓我們盡可能接近零錯誤設計的終極目標。硬體模擬器則能幫助我們將執行時間加速100~100萬倍,甚至更快。

Co-Emulation P1

圖1:IC驗證性能可以透過各種技巧來改善;本文以Level 1、Level 2、Level 3與Level 4 來表示從低到高的性能表現。

在圖1中我們可以看到,改善目前模擬所消耗的時間狀態是我們正在追求的目標;接下來將討論的是可達成Level 3性能的一些技巧。

軟體/驅動程式啟動

加速開發時間的一個重要部分,是在實驗室於交付實際晶片之前改善軟體的啟動(bringup)環境。透過軟體啟動/驅動程式開發,針對目標設計的選項如表1所示。

Co-Emulation P2

表1:軟體/驅動程式晶片啟動選項。

適合以硬體模擬器執行的測試項目

我們發現,在模擬中已經歷了大量清理(cleanup)的長時間測試(高階測試和執行清理一段時間)是很好的選擇。

性能測試(Performance tests)──可能需要在一段長時間內執行才能獲得準確的性能量測。

  • 用於網路晶片:能在特定配置中量測數百萬個資料封包的系統性能。
  • 用於處理器:量測標準化基準測試(如SPEC)的系統性能。
  • 用於深度學習晶片:量測如ResNet推理等標準化基準測試的系統性能。

長時間測試(Long running tests):*測試資源或記憶體耗盡(exhaustion)、老化(設計中具有及時性屬性的任何元素),以及系統重新配置測試、熱儲存(hot banking)或回收再利用物件。

  • 用於網路晶片:可能是測試發送了數百萬個資料封包後的系統行為模式。
  • 用於處理器:可能是測試在發送數十萬甚至更多的執行追蹤(execution trace)之後系統的行為模式。
  • 用於深度學習晶片:可能是測試執行多層神經元之後的系統行為模式;每層神經元可執行包括矩陣乘法(matrix multiplication)、加法和平均(averaging)等。

起因再現(Reproduced wedges):*這類測試必須要讓數件事情同時發生,並且可能需要一些時間才能達到觸發狀態。該類場景通常在圖1的Level 1性能模擬中難以達成或發現。

主機介面連結(Host interface connectivity):*這種屬性可以透過快速執行一種觸及設計中每個暫存器的測試,非常快速地被檢查到。晶片的可程式化程度越高,就越需要對它們進行徹底的測試,因為每種選項都會增加測試案例的組合。

基礎設施檢查(Infrastructure check)測試(具備IO):檢查功能區塊或SoC內的連接,環路(ring)測試等。可以整合任何客製化I/O。加密的Verilog不易處理,可能需要創建一個假行為模型(fake behavioral model)來替換它。

請記住在硬體模擬器中,通常只支援兩個狀態值。使用X-prop和形式化(Formal)解決方案能更充分檢查依據X和Z值的測試。設計和測試程式經常使用X和Z來測試多驅動程式衝突、未賦值變數(unassigned variables)、懸空連接(dangling)以及介面值的錯誤翻轉(incorrect flopping)。

協同硬體模擬架構

為確保不同版本和供應商之間的一致性,最好依循產業標準;設計和驗證語言有SystemVerilog,DV資料庫則有UVM。很幸運的是,硬體模擬也有一個標準介面工作小組──標準組織Accellera的SCE-MI2。硬體模擬方案供應商支援SCE-MI2交易器(transactor)方法。在深入研究SCE-MI2標準之前,先瞭解一下這個架構。

定時/非定時部分和DPI

我們將非定時(untimed)部分稱為HVL域。我們當前環境中的時間意味著推進RTL模擬的模擬時間。大多數UVM測試程式碼位於非定時域中。通常認為測試程式在零模擬時間內執行,排除在外的主要是驅動程式和監視器,因為它們必須根據時脈邊緣驅動資料。

將定時部分稱為HDL域。設計顯然是定時的或可以感知時脈邊緣的,在現代設計中甚至還有非定時程式碼:並發(concurrent ) SVA和一些功能覆蓋。

DPI則如SCE-MI手冊中所定義:「直接編程介面(Direct Programming Interface,DPI)是SystemVerilog和外部程式語言(foreign programming language)之間的介面,包括兩個獨立層:SystemVerilog層和外部語言層。DPI兩側是完全隔離的,實際使用哪種程式語言作為外部語言是透明的,與此介面的SystemVerilog端無關。」

DPI通訊是用於單獨執行同步定時域和非定時域(HVL)的核心思想之一。

SCE-MI2的通訊模式

SCE-MI2通訊有三種主要模式:

  1. 以功能(function)為基礎:功能(利用DPI-C)提供中等抽象。
  2. 以巨集(macro)為基礎:訊息傳遞介面(Message passing interface)旨在應用於不同的使用案例以及被不同族群的使用者應用。
  3. 以管道(pipe)為基礎:交易(transaction)管道是透過功能呼叫(function call)來存取的結構,它提供了一種將交易串流(streaming)進/出HDL端的方法。

以功能為基礎的模式是最容易實現的。

Co-Emulation P3

圖2:SCE-MI2通訊模式。

速度減慢的緣由是定時域和非定時域之間的通訊。我們打算深入研究設計和測試程式所需的程式碼更改,將在未來的文章中加入幾個編碼和方法論指南,然後再介紹規劃流程。

(參考原文:Co-emulation for better IC testing,by Jigar Savla)