介紹

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

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

問題闡述

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

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

功能驗證方案

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

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

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

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

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

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

性能分析方案

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

?

功耗估測方案

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

結(jié)果分析

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

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

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

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

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

Fastest Power Emulation for Hardware-Software Power Verification

審核編輯：劉清