汽车SoC也开始跑分！看看谁家Soc得分最高？

CPU、GPU、DSP以及硬件加速器——如何实现优化?

车用芯片商一直在探讨为先进驾驶辅助系统(ADAS)设计的SoC。但其他人呢?包括记者、分析师，以及最重要的——汽车制造商，我们该如何区别当今的各种ADAS SoC性能有什么不同?

事实是，我们做不到。由于缺少科学工具和基准检验，让我们几乎别无选择，只能相信供应商的说法。或者，我们可以依靠诸如每秒兆次运算(TOPS)之类的不完美测量方法，来比较英特尔(Intel)/Mobileye的EyeQ5以及Nvidia的Xavier——这真的很愚蠢……

为此，开发嵌入式硬件基准的产业联盟EEMBC日前推出了自动驾驶基准检验套件——‘ADASMark’，现已可用于授权。

据EEMBC表示，新的工具套件有助于一线供应商和汽车制造商在设计自家ADAS系统时，用于优化其利用来自CPU、GPU和硬件加速器的运算资源。

The Linley Group资深分析师Mike Demler看好ADASMark，他说：“这不仅仅是一个抽象的性能指针，而且还使用了真正的工作负载。”Demler并表示，得力于加拿大工程设计服务公司AU-Zone Technologies以及恩智浦半导体(NXP Semiconductors)和德州仪器(TI)等芯片供应商的参与，使得EEMBC的测试比百度(Baidu)的通用DeepBench更有意义。

“架构”(framework)至关重要

《EE Times》有机会采访了EEMBC总裁兼首席技术官Peter Torelli，针对汽车制造商在设计高度自动化汽车时面临的挑战发表看法。

无疑地，越来越多的汽车嵌入式系统都部署了多个核心。然而，正如Torelli指出的，“能够利用其非对称运算资源的架构(framework)仍然很少。如果没有架构，编译基准检验的每个实例都会因为硬件不同而产生显著差异，而且也很难进行跨平台比较。透过架构有助于移植，而只需很少的修改。”他说，看看ADASMark Pipeline (下图)就知道了。

(来源：EEMBC)

Torelli说：“该系统的基准性能可能会在管线中的所有阶段都使用相同的CPU。但是，如果开发人员想要在最后阶段更换成自定义的神经网络芯片呢?或者，他们也许想用专有的DSP进行色彩空间转换?”

这便是架构得以发挥之处。

“如果没有架构，开发人员就必须在基准检验和计算设备(NN、DSP或GPU)之间插入程序代码。这相当耗时、复杂且容易出错，并且很容易破坏基准检验的目的(或破坏结果)。”Torelli解释，透过架构则有助于让计算设备更易于重新定位。

EEMBC最初审查了当今市场上可用的选项。Torelli说：“AMP和OpenAMP试图解决这个问题，但它们是对称多核心的规范，无法在这方面真正提供协助。我们也看过OpenCV和OpenVX，但他们对于制造商的支持力度也不足。”

这就是EEMBC为什么开发基于新架构的ADASMark之故。

专注于成像管线

根据EEMBC，ADASMark Benchmark Suite的主要特色“包括一个OpenCL 1.2 Embedded Profile API，用于确保运算作业之间的一致性;由一系列微基准检验打造的应用流程，用于测量和回报处理计算机视觉、自动驾驶和移动成像任务的SoC性能;以及由Au-Zone Technologies提供的交通号志识别CNN推理引擎。”

由于ADAS需要运算密集型对象侦测和视觉分类功能，因此，ADASMark的重点在于成像管线。EEMBC解释，它使用了“代表高度平行应用的实际工作负载，例如环绕视图拼接、轮廓检测和卷积神经网络(CNN)交通号志分类等。”

ADASMark的工作原理

那么，ADASMark如何运作?

据EEMBC解释，ADASMark着眼于对象识别，结合使用了“车辆周围的可见光谱广角相机，以及准备影像供受训练的CNN进行分类的图像处理系统。此外，分类器的输出提供了额外的决策逻辑，例如转向和煞车系统。这种安排需要大量的运算能力。”

确定可用资源的限制且知道如何有效利用它们并不是件简单的事。

为了因应这一挑战，EEMBC解释，ADASMark基准检验将“应用用例与合成测试组合结合到一连串的微基准检验中，用于测量和报告处理计算机视觉、自动驾驶和移动成像任务的SoC性能与延迟。”

不同类型平台的测试结果。以经过DAG图的最长路径决定得分。每项元素(Element)的运行时间和内存开销都会影响总分。(来源：EEMBC)

谁的比分最高?

因此，从上表来看，Device C显示了最佳性能。Torelli说，Device C是其于开发基准检验时使用的云端AWS Nvidia系统。至于Device A和Device B呢?Torelli说说：“很遗憾的是我不能说出前两种组件是什么，因为他们还不打算在此时公布得分。”

值得注意的是，ADASMark仅用于处理Level 2 ADAS的一部份。正如Demler所指出的，“这不是批评，但ADASMark并未解决自动驾驶所需的更高阶功能。识别交通号志在各个层级都很重要，因此它既有用又必要，但要用于Level3到Level 5的汽车还不够。”

此外，如同EEMBC所说，“基准时间并不包括视频档案的主线程处理，或者是与分割资料串流到DAG不同边缘相关的开销。”

在针对汽车应用的新一代AI加速器着眼于绘图运算(或某些类型)之际，一旦未来基准检验开始将“视频档案的主线程处理”或“与分割资料串流相关的开销”纳入考虑，ADASMark的分数是否会有所不同?

Torelli说：“或许如此，但这不是这项基准检验要测量的指标。” 他解释说，“此处存在一些权衡，因为在已部署的系统中，核心将会更紧密地整合。为了缓解这种差异，该管线的某些阶段并未纳入评分。尽管在同一平台上的后续OpenCL装置交换核心所需的时间纳入评分，但它通常比该阶段的工作负载执行更小几个数量级。我们还计算内存缓冲的copy-in/copy-out函数，因为这是异质运算的一个重要部份。”

“第22条军规”——进退维谷之境…

Torelli告诉我们，在开发ADASMark时让他最惊讶的是“与测试人员的合作、在SoC开发人员之间移植我们的基准检验，暴露了评估异质运算系统的复杂性，以及每一种新策略都需要开发团队工作的大量努力。”

他补充说：“目前大多数开发人员都处于最少任务的环境中，这反过来阻碍了他们评估其他设计的机会。这就是所谓的‘第22条军规’(Catch-22)：显然每家供应商的客户都要求优化他们自已的堆栈，但太多的限制却让开发人员没什么找到可能更佳解决方案的余地。”

更重要的是，Torelli观察到，“从硬件的角度来看，在此节骨眼很难判断好坏：运算需求每个月都会随着机器学习的新学术研究进展而变化。”处理器产业通常跟不上学术研究的脚步，他说，“但是当今的机器学习/深度学习情况并非如此。所以，工程界的反应还不够快。”

ADAS SoC对车辆安全的影响

《EE Times》最近在““别人家的”L2级ADAS，为什么比你的强那么多?”一文中，报导了美国公路安全保险协会(IIHS)针对配备ADAS的车辆安全性能进行的评估测试结果。

*IIHS检视道路测试和试车场的驾驶辅助功能，并分享其测试结果*

ADAS SoC的性能与ADAS车辆的安全性能之间是否存在任何相关性?我们询问Torelli个别ADAS芯片对于当今ADAS车辆性能的变化具有多大的影响力。

Torelli引用我们文中提到VSI Labs创办人兼负责人Phil Magney的一句话：“由于硬件/软件配置等多方面的因素，这些系统会出现许多性能差异。”Torelli认为，“这种说法过于保守!”

“在我们的案例中，基准检验并未撷取系统在视觉管线之上的响应时间，例如决策逻辑。”他指出，“除了轮廓检测外，ADASMark的每一级管线都具有与输入成正比的确定性运行时间。我认为决策逻辑和实体系统的响应时间都是问题所在。”

针对IIHS的测试结果，Torelli说，“它似乎与决策系统本身受算法(而非硬件)的支配有关;实体响应系统(煞车、转向等)则有各自不同的环境变量。”

他总结说，ADASmark是“一款有用的分析工具，可用于比较非对称硬件的运算行为(很大程度上是确定性的)——这些硬件本身就是我们试图解决的复杂任务。”

同时，针对ADAS SoC性能对于ADAS车辆安全的影响，Linley Group的Demler指出，IIHS的研究报告也进行了一连串的L2测试。

但他补充说，很难只指出一种硬件可能导致这种变化。“一开始，我会先看传感器和传感器处理软件，然后再着眼到像某些汽车中使用的EyeQ3或DrivePX等处理器。”

基准传感器融合?

EEMBC目前的ADASMark专注于视觉。那么，针对整合来自雷达、激光雷达等传感器数据的SoC传感器融合，EEMBC打算如何进行基准检验?

Torelli说，“雷达和激光雷达仍然是视觉(或类似视觉)管线。我不打算深入探索这些领域，因为我目前还没有看到太多性能指针的变化。”但是，他补充说，“传感器融合和决策逻辑绝对是一个令人感兴趣的领域，但我认为它跨越了一个不同的机器学习领域。至于我们的ADAS或机器学习团队是否涵盖这部份，目前还有待观察。”