介紹

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

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

問題闡述

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

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

功能驗(yàn)證方案

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

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

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

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

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

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

性能分析方案

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

?

功耗估測(cè)方案

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

結(jié)果分析

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

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

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

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

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

Fastest Power Emulation for Hardware-Software Power Verification

審核編輯：劉清