基于Palladium AVIP的SoC驗證方案

程 濤

（哲庫科技（上海）有限公司，上海 201210）

0 引言

本文主要聚焦于消費電子類的SoC 芯片驗證領域，為芯片驗證過程中遇到的功能、功耗、性能驗證方面的一些難題提供了有效的解決方案。相比傳統的驗證方式，基于Palladium AVIP的驗證方案能更加快速高效地達成驗證目的，為芯片按時成功流片提供了強有力的保障。

1 AVIP 簡介

AVIP 是在仿真VIP的基礎上專門針對Emulator 平臺而設計的。如果仿真用的是Cadence的VIP的話，很容易就可以切到基于Emulator的AVIP 上去。基本原理是把原本跟待測設計（Design Under Test，DUT）交互的driver、monitor、interface 等模塊做了一些拆分和修改：軟件側的代理模型（proxy）提供控制接口給用戶控制發包行為，并與硬件側的BFM 進行事務處理（transaction）級別的交互；硬件側通過總線行為模型（Bus Function Model，BFM）來獲取軟件側的發包請求并驅動DUT。通過Palladium（Cadence 公司的Emulator 產品） 可以大大加速硬件側DUT的原理，達到加速整體仿真的目的。目前Cadence的AVIP 支持各種標準協議，如：MIPI、AMBA、通用串行總線（Universal Serial Bus，USB）、高速串行擴展總線標準（Peripheral Component Interconnect Express，PCIE）等。

1.1 AVIP 架構

AVIP 由如下兩部分組成：

（1）硬件側與DUT 信號直接相連的BFM；

（2）軟件側提供函數接口給用戶開發測試平臺。

軟件和硬件之間底層物理交互是通過仿真加速卡（Simulation Acceleration，SA）把Palladium 仿真加速器和服務器連接起來的，運行時通過AVIP 軟件側的proxy 與硬件側的BFM 進行transaction 級別的通信。AVIP 架構圖如圖1 所示。

圖1 AVIP 架構圖

1.2 AVIP 支持的接口

AVIP 支持多種不同的測試平臺接口及使用模型，支持接口有：UVM、C++、TLM2、嵌入式等。不同的接口可以有不同的使用方式：

（1）UVM 接口一般用來作為仿真加速；

（2）C++也是用來作為仿真加速，相比UVM 接口少了UVM 相關的方法學的外殼；

（3）TLM2 接口可以連接虛擬平臺來使用；

（4）嵌入式速度最快，需要把測試平臺寫成可綜合的形式并綜合到Emulator 里去。

用戶需要使用者根據自己平臺的特性選擇合適的接口和使用方式，各接口比較如表1 所示。

表1 各接口比較

2 基于AVIP的仿真加速

AVIP的一個重要作用就是用來做仿真加速，通過加速硬件側的DUT，同時減少軟件側和硬件側的交互，達到大幅加快整體仿真速度的目的。

對于一些大場景的測試用例，軟件仿真速度太慢了，比如有的可能需要一兩周的時間才能跑完，對于芯片驗證來說很難滿足驗證計劃的時間要求。如何在盡可能少改動原有仿真環境以及測試用例的前提下大幅提升仿真速度是一個難題。

針對不同的模塊以及場景，本文將介紹2 種不同的加速方案：UVM 仿真加速和C++仿真加速方案。UVM仿真加速方案適合設計驗證（Design Verification，DV）人員，可以基于現成的UVM 仿真環境，把VIP 替換成AVIP 并在Emulator 上進行仿真加速。C++的仿真加速方案適合SOC DV 或芯片驗證（Chip Validation，CV）人員，尤其是驗證case 是基于C 代碼寫的用例，優點是環境相對比較簡單，沒有UVM 那一套復雜方法學，可以快速地搭建好仿真環境。并且運行速度理論上會比基于UVM 仿真加速的方案快一些，缺點是環境復用性差一些。

2.1 基于UVM的仿真加速方案

2.1.1 UVM 仿真加速原理簡介

使用硬件加速DUT的同時仍然受益于UVM 提供的高級驗證環境，如果是使用Cadence的VIP 搭建的驗證環境，那么可以很方便地切到AVIP的UVMA 環境，只需要編譯的時候增加一些編譯選項和宏定義并指定兩個頂層：硬件層和軟件層，軟件側主要是實現UVM 環境并運行在仿真器上。硬件側主要是實例化DUT 和AVIP的BFM，把AVIP 和DUT 連接起來并運行在硬件加速器上。同時AVIP 把原本VIP 里與DUT 交互的interface做成可綜合的邏輯并放到了硬件側，軟件側的driver 和monitor 可以調用硬件側interface 定義的task，這樣軟硬件之間就可以通過transaction 進行交互了。這樣在做仿真加速時就能復用原本的UVM 環境和測試用例，減少了重新搭建環境的工作量。

2.1.2 待測設計介紹

DUT 是一個有兩個AXI 接口的圖像處理模塊，一個AXI 口是用來配置模塊控制寄存器的。另一個AXI 口是待測設計用來讀取雙倍數據速率存儲單元（Double Data Rate，DDR）獲得原始處理圖像數據以及處理完數據之后把結果數據寫回DDR 通路的。

圖2 UVM 仿真加速架構圖

2.1.3 仿真加速流程架構

（1）在硬件側實例化AVIP的BFM 模型并與待測設計通過信號連接起來。同時實例化一個帶AXI 口的存儲模型來模擬DDR的功能，并與待測設計連接起來。

（2）在軟件服務器側通過調用AVIP 提供的UVM 接口函數來控制AVIP的發包行為。此處的配置信息是從算法組獲得的，可以通過腳本自動生成相應的測試用例。原始圖片數據可以通過DDR的后門加載進去。

（3）DUT 從DDR 讀取原始數據處理完后數據通過AXI 口寫到DDR 里面，結束后可以從DDR的后門導出來離線與期望的正確數據進行對比。

2.1.4 測試結果

使用這種方式的加速比可以達到十倍左右，因為有一部分非標準協議接口在，這部分使用了信號級別的通信對速度有一定影響，如果純AVIP的環境理論上可以達到幾十甚至上百倍的加速比。原本需要運行一周的測試用例可以十多個小時運行完，大大加速了驗證速度。后續優化速度的辦法是對于非標準協議或是沒有AVIP的情況，可以對這類接口做一些優化，處理成自定義的AVIP：主要處理driver 和monitor 與DUT 交互的接口部分，把它做成可綜合的邏輯并放到硬件加速器里去。

2.2 基于C++base的仿真加速方案

2.2.1 基于C++接口的仿真加速原理

Palladium AVIP 提供了運行在軟件服務器側的proxy模型接口，proxy 模型與硬件側的BFM 模型通過transaction發包的形式進行交互。BFM 側則通過解析transaction 成信號級別并驅動DUT。

2.2.2 基于C++仿真加速流程架構

（1）在硬件側：實例化MIPI AVIP的BFM 模型，并與待測設計通過信號連接起來。使用Palladium 硬件來加速DUT 側的運行速度。

（2）在軟件側：通過調用MIPI RX AVIP 提供的C++接口函數，可以輸入各種格式的圖片數據，并控制AVIP按照MIPI 協議把數據打包發送到待測設計里去?？梢酝ㄟ^設置AVIP的時鐘，以及插入空白行等方式控制發幀幀率，以及利用AVIP 提供的現成函數接口控制發包的長度、類型等。

（3）結果比對：MIPI TX AVIP 可以把處理好的圖片數據存成raw 格式的文件，然后通過離線的方式進行比較，判斷測試用例是成功還是失敗了。

（4）AVIP 與中央處理器（Central Processing Unit，CPU）上執行的軟件代碼的交互：通過選取待測設計里不用的寄存器來作為AVIP 和DUT的交互通道。比如CPU如果往某個寄存器寫0x123，testbench 側可以通過調用在硬件描述語言（SystemVerilog，SV）里定義的直接編程接口（Direct Programming Interface，DPI）函數，來解析出這個編碼，不同的編碼代表不同的測試用例以及發包方式，這樣就可以進行測試用例的連續測試。如此就達到了通過CPU 軟件配置寄存器來達到間接控制AVIP 發包的目的。

2.2.3 測試結果

原來需要運行7 個多小時的測試用例，使用基于MIPI AVIP的仿真加速方案只需要10 min 左右就可以運行完，加速比達到了43 倍，大大加速了芯片驗證的進度。

3 基于MIPI AVIP的功耗分析方案

功耗分析傳統的流程是運行出波形用Synopsys的PTPX 或者Cadence的Joules 來算出具體的功耗值。如果是使用仿真的方式來抓取波形，對于一些大場景的測試用例面臨的挑戰：（1）仿真運行時間很長，有的要以周計，效率很低；（2）波形數據很大，但是功耗分析工具只能分析很短的一段波形，如何在很長的一段測試用例里準確抓取到感興趣的那一小段波形是一個難題。

通過結合MIPI AVIP 發包來模擬真實場景、Palladium 網表編譯流程以及Cadence的動態功耗分析流程（Dynamic Power Analysis，DPA），HW-WTC（Hardware Weighted Toggle Count）可以解決上面提到的仿真速度慢以及難以找到感興趣功耗波形窗口的難題。

3.1 HW-WTC 原理

HW-WTC的基本原理是通過往硬件里增加額外邏輯統計信號翻轉數，并依據.lib 文件里各個標準單元功耗信息加入相應權重，以此來統計模塊所有信號的翻轉數（動態功耗主要跟信號翻轉率有關）。有了信號翻轉數就可以通過工具分析得到某個場景下動態功耗的趨勢圖，有了這個趨勢圖就可以很方便地找到感興趣的窗口（如峰值功耗：peak power），基于這個窗口就可以只需要抓取一小段波形提供給功耗分析工具，最終得到準確的功耗值。

圖3 HW-WTC 流程圖

3.2 解決方案

待測設計是一個圖像處理芯片，通過MIPI 接口輸入輸出圖像數據，內部是一些處理核。

3.2.1 基于MIPI AVIP的功耗流程介紹

（1）編譯后端提供的標準單元的.lib 文件，生成對應的powerdb（包含各個標準單元模塊功耗信息）。

（2）準備可以在Emulator 上運行的數據庫：

①在硬件側里實例化AVIP的BFM 模型，并通過force的方式與設計連接起來。

②編譯的時候把powerdb 和后端提供的網表文件編譯成可以在加速器上運行的數據庫。

（3）編寫基于C++的MIPI AVIP的測試平臺，模擬照相機傳輸圖片進入DUT，并通過CPU 配置內部圖片處理模塊來處理圖像數據，以此來模擬真實場景下芯片的工作場景。

（4）運行完測試用例后就可以得到.ppfdata的數據庫，可以通過xeDebug工具查看整個測試場景下的功耗趨勢圖，并得到感興趣的窗口。

（5）抓取感興趣那段波形提供給功耗分析工具算出具體的功耗值。

3.2.2 調試技巧

最好是選取與網表相同版本的RTL 代碼先進行測試，因為網表綜合布線之后很多信號的極性會發生變化，所以需要重新連接AVIP的信號到DUT。在RTL 版本上測試通過之后可以確保RTL 和C 代碼是正確的，再上網表版本測試運行迭代次數會少很多。

3.2.3 測試結果

通過這種方案跑省去了抓取全波形的問題，通過確認感興趣窗口以及Emulator的加速，如果有已經可以運行通的測試用例，順利的話兩三天就可以得到一個功耗數據，相比以前需要周計的傳統的方式效率更高，結果也更加準確。

4 基于AMBA AVIP的性能分析方案

傳統的性能分析通過查看波形效率十分低下。一些大的場景在Emulator 上跑下來波形文件很占存儲空間，同時抓波形和轉波形的時間很長。仿真上運行速度又太慢，一些大的場景可能要一兩周才能跑完，效率十分低下。如何能夠方便快捷地得到芯片的帶寬以及延遲等性能數據是個難題。

圖4 為各個主設備掛上AMBA AVIP 性能監視器來抓取各個master的transaction，并使用Palladium 來運行真實場景。測試場景運行完直接就可以得到各個模塊的發包日志。使用SPA（System Performance Analysis）工具分析日志文件就可以得到包括帶寬、延遲、outstanding 等性能結果。

圖4 AVIP 性能監控器框圖

4.1 待測設計介紹

待測設計是一個圖像處理芯片，通過MIPI 接口輸入輸出圖像數據，內部是一些處理核。并且大部分模塊的接口是AMBA 接口。

4.2 基于AMBA AVIP 性能方案流程架構介紹

（1）實例化AMBA AVIP 到各個主設備口上并編譯得到Palladium 能運行的數據庫。

（2）通過CPU 執行C 代碼進行各個模塊的配置，運行期望場景的測試用例，并通過AMBA AVIP monitor 得到性能相關的日志。這些日志里面就包含了transaction的信息。在使用的時候可以應用上multi GFIFO/SFIFO技術，這樣可以更加高效地抓取性能日志。因為一些大的場景日志通常也很大，multi GFIFO/SFIFO 技術可以把各個主設備的日志分開單獨存放，這樣使用SPA 分析的時候可以單獨分析，或者并行分析多個主設備的日志，效率會高很多。

（3）通過SPA工具解析這些性能日志，就可以得到包括帶寬、延遲、outstanding 等性能的結果。

4.3 測試結果

最終解決了性能分析需要抓很大的波形，轉波形的問題，大大節省了性能評估的時間。如果有現成的測試用例，順利的話基本上一天就可以得到帶寬、延遲、outstanding 等性能報告。相比之前抓波形轉波形都要好幾天加上還要人工去分析波形算性能結果，大大節省了人力和時間，對芯片架構調整或者軟件代碼優化提供了極大的保障。SPA 分析結果如圖5 所示。

圖5 SPA 分析結果圖

5 結論

結合Palladium AVIP 來進行SoC 芯片的驗證，可以從多個維度加速芯片開發測試進度，涉及功能、功耗、性能等各個方面。解決了傳統驗證方案耗時耗力的問題，加快了整個芯片的驗證速度，為芯片順利流片提供了極大的保障。