介紹

本文中所涉及的AI邊緣推斷視覺處理芯片的實際用例都較為復雜，而且也需要牽扯到多個模塊參與，例如攝像頭輸入、多通道數據的媒體編解碼、圖像處理、多顯示支持等。要去協調這么多的模塊，還要將它們與神經網絡算法結合構建用例。

由于對系統中各個硬件要素的協調調度要求較多，AI視覺處理芯片需要更多使用固件去進行測試，這對于從IP/子系統層的測試用例到系統層的移植、以及在早期階段獲得較為準確的性能數據和功耗數據都提出了要求。這篇論文提供了一個作者在功能、性能和功耗這三個方面的硬件加速驗證方案。

問題闡述

不同于常見的SoC在數據傳輸和控制上的測試方案，AI視覺處理芯片往往需要結合多個高帶寬的多媒體控制器發起多個數據幀，模擬真實應用。而這么大的數據處理量，仿真往往會受制于仿真性能無法有較好的表現，所以在AI芯片驗證方面，如果想要測試真實場景，那么就需要將固件在硬件加速器（emulator）上去處理。

由于功能、性能、功耗三個方面的驗證在工具層面都缺少統一的平臺做處理，而且不同形式的測試向量和方法學也讓這些測試場景無法做到自動化映射。從工程實現角度考慮，一個需求是把功能測試的數據能夠給到性能分析和功耗評估，另外一個需求是將IP/子系統層面的測試用例能夠給到SoC層面測試。

功能驗證方案

下方給出了在采用固件驗證的情況下的測試方案。固件在早期驗證中，可能使用的是例如SystemC/C++這類的純軟件測試平臺，在此基礎上他們可以提供早期的固件和十六進制文件（在后期的硬件加速測試中使用）。同時，在IP/子系統硬件加速測試中，可以根據測試文件（二進制文件和log文件）做后處理繼而獲得測試中的硬件配置數據和圖形文件。

在接下來的SoC emulation，可以將從早期軟件測試中固件、IP/子系統emulation中提取的硬件配置、圖形文件共同作為SoC測試中的元素，讓他們用來盡可能實現從IP/子系統到SoC的測試場景移植。 接下來可以利用emulator中的總線監測組件，獲得總線傳輸數據，并將這些數據信息交由Python腳本去做處理，以便達到數據比較、性能監測等目的。

這個方案意味著測試從大的層面來看，是以最終通過固件測試為目的，也就是說從一開始構建測試場景時，就需要固件的人參與其中。這就不得不考慮在開發AI視覺芯片時的驗證分工協作的場景不單單是simulation、emulation參與在內，也同樣需要固件。盡管一開始硬件可能還不穩定，需要simulation/emulation讓硬件逐步穩定，但固件的人只要前期有SystemC/C++這樣的模型在的話也可以在早期做固件有關的測試準備。

這一點挺重要的，如果固件的人直到emulation階段才參與進來的話，那么也就沒有上面方案里的Software Testbench部分了，所有的信息都只能等到IP/子系統emulation階段得出。更甚至，如果在IP/子系統emulation階段沒有固件參與的話，那么在SoC層面去做固件相關的測試，從開發固件測試用例到做參考比較都會延緩測試進度。更為推薦的是固件也有條件在某個測試平臺（software testbench、IP/subsys emulation testbench）完成測試。

還有一點，在IP/subsys階段的測試，方案中是通過測試中的bin文件、log文件來做后處理，繼而生成SoC層面可以使用的配置。這一點不同于我們以往所理解的將測試文件從IP/subsys到SoC階段的修改移植。可能是為了實現準確的、自動化的配置參數，它是按照后處理的方式，提取出來對目標硬件做的各項配置，這些提取的信息可能按照某個格式做了中間信息的保存，并且結合SoC的結構特征，做了自動化的配置測試生成。

在SoC emulation階段，利用的是內置的總線監測（可能有多個），周期性地獲得數據，并完成數據完整性檢查（可能在測試中或者測試后通過Python腳本完成）。

性能分析方案

在性能分析時，也需要利用測試場景的移植（porting）和分析時的多個深度。從IP/subsys到SoC的移植，就性能分析而言分為了3個階段。 第1階段即是將IP/subsys的傳輸數據移植到SoC層面，這一點可以利用IP/subsys emulation過程中log文件的后處理來獲得。 第2階段是將IP/subsys的固件移植到SoC層面，這一點也可以利用“功能驗證方案”中已有的“software testbench”信息。 第3階段是為了讓多個多媒體控制器、接口的數據信息能夠并行運行以期達到真實的、大規模的數據吞吐。這種場景需要文中提到的一個特殊的混合方法（unique hybrid methodology），共同利用數據網絡（network）和固件，將多個多媒體控制器充分并行調動，構建復雜的測試場景。

?

功耗估測方案

在功耗估測中，需要考慮的是相比于通常在仿真中收集功耗有關數據，如何在emulation中收集數據，并且做到準確的、快速的功耗分析。在下面的方案中，利用了波形數據獲得開關信息文件SAIF，并結合power engine去獲得平均功耗和峰值功耗（論文并沒有就power engine給出詳細的信息）。 這里附贈一篇文章： 《Using Emulators For Power/Performance Tradeoffs》 https://semiengineering.com/using-emulators-for-power-performance-tradeoffs/

結果分析

受益于可以從IP/subsys層將測試用例有關的數據自動遷移到SoC級，使得與VPU（視覺處理單元）、DMA、ISP（Image Signal Processing）有關的測試用例能夠在4周的時間完成交付。這里的測試用例遷移我們應該吸取文章中的經驗，那就是它不是從測試用例自身文本的遷移去實現的，而是通過log/bin文件的后處理，獲得某種中間型的標準信息文件，再結合系統測試的環境配置數據，最終生成SoC測試用例。

從發現的bug類型來看，有接近40%來自于固件級別的測試，這也突出了AI類芯片在測試時需要結合實際場景的需求，畢竟整個系統的調動牽扯很多模塊，需要固件人員在早期就能夠參與進來。這也進一步突出了如何規劃一個跨平臺的方案在系統級測試上面有多么重要，我們不應該被SV/UVM/C所限制，也應該考慮如何讓這個測試平臺能夠被更多的人所使用。

相比于SoC仿真動輒需要用2天左右的時間完成某一個固件級的測試用例，emulation僅需要大概90分鐘的時間即能夠完成測試，并且更快地將性能數據反饋給架構組合設計組。在將simulation與emulation對比過程中，無論是固件測試用例數量、可支持數據幀的數目還是數據保存時間窗口，emulation的優勢都更為明顯。

而在功耗評估中，emualtion的功耗評估數據準確度與傳統的功耗分析工具差別大致在5%以內，而所消耗的時間則顯著縮短（大致是傳統功耗分析工具的125倍）。論文這里仍然沒有給出消耗時間的計算方式，是否包含了每個測試用例在simulation與emulation的耗時差別，還是只是包含了兩種工具用于功耗評估的時間。如果是后者的話，那么文中的power engine可能是內部開發的工具了，線索在文章的引文中（有一篇“pre-silicon power estimation methodology using emulation”，也一并在論文下載鏈接中提供）。

給出的參考論文來自于SNUG India 2020，而在2021年的時候Synopsys推出了業界第一款用來對運行真實軟件做功耗驗證（hardware+software）的工具ZeBu Empower。 https://www.synopsys.com/verification/emulation/zebu-empower.html

Fastest Power Emulation for Hardware-Software Power Verification

審核編輯：劉清