CPU、GPU、DSP以及硬件加速器——如何實現優(yōu)化?

車用芯片商一直在探討為先進駕駛輔助系統(ADAS)設計的SoC。但其他人呢?包括記者、分析師，以及最重要的——汽車制造商，我們該如何區(qū)別當今的各種ADAS SoC性能有什么不同?

事實是，我們做不到。由于缺少科學工具和基準檢驗，讓我們幾乎別無選擇，只能相信供應商的說法?；蛘?，我們可以依靠諸如每秒兆次運算(TOPS)之類的不完美測量方法，來比較英特爾(Intel)/Mobileye的EyeQ5以及Nvidia的Xavier——這真的很愚蠢……

為此，開發(fā)嵌入式硬件基準的產業(yè)聯盟EEMBC日前推出了自動駕駛基準檢驗套件——‘ADASMark’，現已可用于授權。

據EEMBC表示，新的工具套件有助于一線供應商和汽車制造商在設計自家ADAS系統時，用于優(yōu)化其利用來自CPU、GPU和硬件加速器的運算資源。

The Linley Group資深分析師Mike Demler看好ADASMark，他說：“這不僅僅是一個抽象的性能指針，而且還使用了真正的工作負載。”Demler并表示，得力于加拿大工程設計服務公司AU-Zone Technologies以及恩智浦半導體(NXP Semiconductors)和德州儀器(TI)等芯片供應商的參與，使得EEMBC的測試比百度(Baidu)的通用DeepBench更有意義。

“架構”(framework)至關重要

《EE Times》有機會采訪了EEMBC總裁兼首席技術官Peter Torelli，針對汽車制造商在設計高度自動化汽車時面臨的挑戰(zhàn)發(fā)表看法。

無疑地，越來越多的汽車嵌入式系統都部署了多個核心。然而，正如Torelli指出的，“能夠利用其非對稱運算資源的架構(framework)仍然很少。如果沒有架構，編譯基準檢驗的每個實例都會因為硬件不同而產生顯著差異，而且也很難進行跨平臺比較。透過架構有助于移植，而只需很少的修改。”他說，看看ADASMark Pipeline (下圖)就知道了。

(來源：EEMBC)

Torelli說：“該系統的基準性能可能會在管線中的所有階段都使用相同的CPU。但是，如果開發(fā)人員想要在最后階段更換成自定義的神經網絡芯片呢?或者，他們也許想用專有的DSP進行色彩空間轉換?”

這便是架構得以發(fā)揮之處。

“如果沒有架構，開發(fā)人員就必須在基準檢驗和計算設備(NN、DSP或GPU)之間插入程序代碼。這相當耗時、復雜且容易出錯，并且很容易破壞基準檢驗的目的(或破壞結果)。”Torelli解釋，透過架構則有助于讓計算設備更易于重新定位。

EEMBC最初審查了當今市場上可用的選項。Torelli說：“AMP和OpenAMP試圖解決這個問題，但它們是對稱多核心的規(guī)范，無法在這方面真正提供協助。我們也看過OpenCV和OpenVX，但他們對于制造商的支持力度也不足。”

這就是EEMBC為什么開發(fā)基于新架構的ADASMark之故。

專注于成像管線

根據EEMBC，ADASMark Benchmark Suite的主要特色“包括一個OpenCL 1.2 Embedded Profile API，用于確保運算作業(yè)之間的一致性;由一系列微基準檢驗打造的應用流程，用于測量和回報處理計算機視覺、自動駕駛和移動成像任務的SoC性能;以及由Au-Zone Technologies提供的交通號志識別CNN推理引擎。”

由于ADAS需要運算密集型對象偵測和視覺分類功能，因此，ADASMark的重點在于成像管線。EEMBC解釋，它使用了“代表高度平行應用的實際工作負載，例如環(huán)繞視圖拼接、輪廓檢測和卷積神經網絡(CNN)交通號志分類等。”

ADASMark的工作原理

那么，ADASMark如何運作?

據EEMBC解釋，ADASMark著眼于對象識別，結合使用了“車輛周圍的可見光譜廣角相機，以及準備影像供受訓練的CNN進行分類的圖像處理系統。此外，分類器的輸出提供了額外的決策邏輯，例如轉向和煞車系統。這種安排需要大量的運算能力。”

確定可用資源的限制且知道如何有效利用它們并不是件簡單的事。

為了因應這一挑戰(zhàn)，EEMBC解釋，ADASMark基準檢驗將“應用用例與合成測試組合結合到一連串的微基準檢驗中，用于測量和報告處理計算機視覺、自動駕駛和移動成像任務的SoC性能與延遲。”

不同類型平臺的測試結果。以經過DAG圖的最長路徑決定得分。每項元素(Element)的運行時間和內存開銷都會影響總分。(來源：EEMBC)

誰的比分最高?

因此，從上表來看，Device C顯示了最佳性能。Torelli說，Device C是其于開發(fā)基準檢驗時使用的云端AWS Nvidia系統。至于Device A和Device B呢?Torelli說說：“很遺憾的是我不能說出前兩種組件是什么，因為他們還不打算在此時公布得分。”

值得注意的是，ADASMark僅用于處理Level 2 ADAS的一部份。正如Demler所指出的，“這不是批評，但ADASMark并未解決自動駕駛所需的更高階功能。識別交通號志在各個層級都很重要，因此它既有用又必要，但要用于Level3到Level 5的汽車還不夠。”

此外，如同EEMBC所說，“基準時間并不包括視頻檔案的主線程處理，或者是與分割資料串流到DAG不同邊緣相關的開銷。”

在針對汽車應用的新一代AI加速器著眼于繪圖運算(或某些類型)之際，一旦未來基準檢驗開始將“視頻檔案的主線程處理”或“與分割資料串流相關的開銷”納入考慮，ADASMark的分數是否會有所不同?

Torelli說：“或許如此，但這不是這項基準檢驗要測量的指標。” 他解釋說，“此處存在一些權衡，因為在已部署的系統中，核心將會更緊密地整合。為了緩解這種差異，該管線的某些階段并未納入評分。盡管在同一平臺上的后續(xù)OpenCL裝置交換核心所需的時間納入評分，但它通常比該階段的工作負載執(zhí)行更小幾個數量級。我們還計算內存緩沖的copy-in/copy-out函數，因為這是異質運算的一個重要部份。”

“第22條軍規(guī)”——進退維谷之境…

Torelli告訴我們，在開發(fā)ADASMark時讓他最驚訝的是“與測試人員的合作、在SoC開發(fā)人員之間移植我們的基準檢驗，暴露了評估異質運算系統的復雜性，以及每一種新策略都需要開發(fā)團隊工作的大量努力。”

他補充說：“目前大多數開發(fā)人員都處于最少任務的環(huán)境中，這反過來阻礙了他們評估其他設計的機會。這就是所謂的‘第22條軍規(guī)’(Catch-22)：顯然每家供應商的客戶都要求優(yōu)化他們自已的堆棧，但太多的限制卻讓開發(fā)人員沒什么找到可能更佳解決方案的余地。”

更重要的是，Torelli觀察到，“從硬件的角度來看，在此節(jié)骨眼很難判斷好壞：運算需求每個月都會隨著機器學習的新學術研究進展而變化。”處理器產業(yè)通常跟不上學術研究的腳步，他說，“但是當今的機器學習/深度學習情況并非如此。所以，工程界的反應還不夠快。”

ADAS SoC對車輛安全的影響

《EE Times》最近在““別人家的”L2級ADAS，為什么比你的強那么多?”一文中，報導了美國公路安全保險協會(IIHS)針對配備ADAS的車輛安全性能進行的評估測試結果。

*IIHS檢視道路測試和試車場的駕駛輔助功能，并分享其測試結果*

ADAS SoC的性能與ADAS車輛的安全性能之間是否存在任何相關性?我們詢問Torelli個別ADAS芯片對于當今ADAS車輛性能的變化具有多大的影響力。

Torelli引用我們文中提到VSI Labs創(chuàng)辦人兼負責人Phil Magney的一句話：“由于硬件/軟件配置等多方面的因素，這些系統會出現許多性能差異。”Torelli認為，“這種說法過于保守!”

“在我們的案例中，基準檢驗并未擷取系統在視覺管線之上的響應時間，例如決策邏輯。”他指出，“除了輪廓檢測外，ADASMark的每一級管線都具有與輸入成正比的確定性運行時間。我認為決策邏輯和實體系統的響應時間都是問題所在。”

針對IIHS的測試結果，Torelli說，“它似乎與決策系統本身受算法(而非硬件)的支配有關;實體響應系統(煞車、轉向等)則有各自不同的環(huán)境變量。”

他總結說，ADASmark是“一款有用的分析工具，可用于比較非對稱硬件的運算行為(很大程度上是確定性的)——這些硬件本身就是我們試圖解決的復雜任務。”

同時，針對ADAS SoC性能對于ADAS車輛安全的影響，Linley Group的Demler指出，IIHS的研究報告也進行了一連串的L2測試。

但他補充說，很難只指出一種硬件可能導致這種變化。“一開始，我會先看傳感器和傳感器處理軟件，然后再著眼到像某些汽車中使用的EyeQ3或DrivePX等處理器。”

基準傳感器融合?

EEMBC目前的ADASMark專注于視覺。那么，針對整合來自雷達、激光雷達等傳感器數據的SoC傳感器融合，EEMBC打算如何進行基準檢驗?

Torelli說，“雷達和激光雷達仍然是視覺(或類似視覺)管線。我不打算深入探索這些領域，因為我目前還沒有看到太多性能指針的變化。”但是，他補充說，“傳感器融合和決策邏輯絕對是一個令人感興趣的領域，但我認為它跨越了一個不同的機器學習領域。至于我們的ADAS或機器學習團隊是否涵蓋這部份，目前還有待觀察。”