适用于汽车的集成式MBSE

来源：Mentor    作者：Anoop Saha & Andrew Macleod

高层摘要

       自动驾驶汽车和 ADAS 的实现取决于能否融合来自 LiDAR、雷达、摄像机和其他装置的传感器数据。传感器融合任务将越来越多地使用定制处理硬件FPGA 或 ASIC 来完成。而且需要更多的定制芯片来应用机器学习和 AI，以基于这些传感器数据做出决策。本白皮书介绍了如何使用高层次综合 (HLS) 方法加快设计流程和应对验证挑战，在某些情况下，该方法远优于手工编码的RTL。

       自动驾驶汽车需要复杂的传感器结构才能正常运作。这些传感器包括 LiDAR、雷达、视频等，它们持续产生大量与汽车周围环境相关的实时数据。传感器不断地将其输出发送到与处理单元连接的功能强大的域控制器以进行分析。来自不同传感器的离散数据随后会合并，产生与车辆的位置、速度、方向和周围环境有关的有意义信息。此过程称为传感器融合。

       传感器融合通常利用定制硬件 FPGA 或 ASIC 完成。数据经过处理后，系统做出影响 ADAS 系统的决策，例如转弯、刹车或车速控制。硬件结合了复杂人工智能 (AI) 应用中的机器学习算法，以便于对传感器数据进行实时处理。

       传感器融合面临的挑战包括设计和验证定制芯片，以及通常情况下设计和验证运行芯片的车辆硬件和软件系统，这也概括了 ADAS 和自动驾驶领域的工程团队所需的跨领域工作。实际上，鉴于各种城市景观和人类驾驶行为，理想情况下，设计和验证任务甚至应该延伸至城市交通场景，而这些场景本身就是非常复杂的系统。要解决的问题贯穿芯片到城市的整个范围，必须最终进行通盘考虑，即使特定学科（例如芯片设计）内的工作和以往一样复杂也是如此。

用于自主传感器处理的复杂算法

图 1：用于字符识别的简单 2 层 CNN

       在硬件中实现机器学习算法本身就是一个挑战。例如， 一种常见的对象检测算法是基于 CNN（卷积神经网络）， 它支持 “自适应巡航控制” 和 “前/后碰撞警示系统” —— 这对于实现全自动驾驶汽车显然至关重要。CNN 由多层组成，每层执行多组卷积。每层的卷积滤波器都是经过编程的 “特征检测器”，用于查找某些特征，例如水平线、垂直线等。

       通常，输入和输出通道的数量会随着数据在各层中行进而翻倍，导致卷积滤波器和滤波器权重（系数）的数量激增。图 1 显示第一层有 1 个输入通道和 16 个输出通道，需要 16 个不同的卷积滤波器核。第二层有 16 个输入通道和 36 个输出通道，需要 36 x 16 = 576 个 2-D 卷积滤波器。在许多 CNN 中，最后一层或几层是全连接层， 通常利用矩阵乘法实现。

       已优化性能和功耗的硬件实现 CNN 需要多人经年累月的努力。抽象性质决定了硬件设计本身相当复杂。对于自动驾驶汽车的定制硬件，设计人员需要探索各种架构以确保实现最佳的推理精度。

       为了实现该精度，自动驾驶汽车的推理芯片需要应对如下额外挑战：

       a.性能：一台高清摄像机能够以每秒 60 帧的速度捕获1920x1080 图像。一部汽车可能有 10 台或更多此类摄像机。推理引擎必须能够处理以该速率传输进来的数据，做出有意义的决策。因此，CNN 的性能变得至关重要。

       b.功耗：功耗虽然不那么直观，但却是推理引擎的另一个重要指标。AI 推理是一种会耗费大量功率的操作， 其中一个重要原因是需要大量访问远程存储器。对于电动汽车，减少 ADAS 系统的功耗很重要，这样电池电量可以更有效地用于汽车的物理操作。

       c.功能安全：对自动驾驶汽车而言，功能安全是另一个越来越重要的方面。算法应能检测到硬件的各种故障可能造成的功能安全问题。通过前期验证来确保适当故障覆盖率的能力至关重要。

HLS 设计流程：从架构到经过验证的 RTL

图 2：ASIC 设计时间与每年的机器学习论文数量

（图片提供方：Samba Nova；改编自 Jeff Dean，Scaled ML）

       最大的挑战仍然在于传统 ASIC 设计流程的周转时间。实现新的 ASIC 硬件需要花费数月到一年的时间。将 ASIC送交制造之前，大部分时间都花在 ASIC 的验证上。由于掩模成本高昂且较低节点的周转时间很长，设计和验证团队希望确保在流片之前达到较高的验证覆盖率。这对机器学习来说非常有挑战性，因为算法在迅速发展。硬件设计必须与软件算法和框架的快速发展保持同步，如图 2 所示。

       最初，自动驾驶系统架构师或设计人员依赖 TensorFlow、Caffe、MATLAB、theano 之类的工具来帮助在高级抽象环境中捕获、收集和明确验证数据。这些高级深度学习框架支持探索众多参数，以便研究、分析、选择算法的最佳解决方案。

       确定算法后，设计人员便可使用 C++ 或 SystemC 捕获流程。C++ 的优点在于它是一种通用编程语言，已经广泛用于硬件和软件的高级算法/行为建模。SystemC 则允许用户通过增添更多实现细节来优化设计，这对于传感器处理单元的硬件实现至关重要。

       下一步是开始设计自动驾驶应用的实际硬件算法模块。这里，设计人员面临以下选择：是手动编写 RTL 代码， 还是使用高层次综合 (HLS) 从 C++ 或 SystemC 生成 RTL。RTL 过去一直是数字设计的起点，但它已变得过于昂贵且耗时（图 2），需要大型团队来生成成千上万行的 Verilog 或 VHDL 代码。微小的更改可能造成昂贵且费时的重新设计，而且很难为这些团队找到技能熟练的工程师。RTL 仿真的运行速度比 C++ 仿真要慢 106 倍，因此验证时间和成本攀升至不可控制。

关键问题：RTL 设计与验证

图 3：关键问题：RTL 设计与验证（图片来源：NVIDIA）

       与 RTL 不同，HLS 通过强大的随时目标定位和实现能力将功能与实现分开（图 3）。因此，HLS 通过更高程度的抽象来缩短算法设计时间，使代码量比 RTL 少 50 倍。这意味着设计团队可以缩小规模，开发时间更短，验证速度更快。算法设计和验证时间可以从一年缩短到几个月，增加新功能只需几天，而非数周。由于可以轻松修改和重新生成算法，因此后期功能变更可以在不影响流片日程的情况下进行。更高的抽象级别使得仿真速度极快，设计人员可以快速探索不同架构选项以实现最优的功耗、性能和面积。

       一旦设计团队对结果满意，HLS 就能从 C/C++ 和/或SystemC 描述生成高质量的 RTL。验证生产率同样需要一种与 RTL 目前所用类似的功能覆盖方法，但将受益于仿真运行时间缩短。形式属性检查和代码检查是该流程的一部分，目的是确保源代码对于综合和仿真而言都是“整洁的”。此外，还需要一些工具来测量代码覆盖率，包括行、分支和表达式覆盖率。转入更高级别的设计需要强大的调试和可视化工具，包括 IDE 和波形视图，以及对优化瓶颈与控制/数据流的可视化能力。其目标是实现 “设计即正确” 的 RTL，即 C++ 算法与综合 RTL 之间的表示和仿真结果精确一致。

图 4：高层次综合平台

       为此，算法设计人员需要决定自动驾驶汽车系统应当使用哪种类型的硬件平台。设计人员可以将算法表示为 CPU、DSP 或 GPU 中运行的软件，但这些平台价格昂贵且有其他缺点。CPU 速度不够快或效率不够高； DSP 虽然擅长图像处理，但缺乏 Deep AI 所需的足够性能。GPU 擅长训练，但对于车载解决方案而言，其功耗过高。另一个选择是在 FPGA、ASIC 或专用形式的定制设计硬件平台中实例化算法。虽然这需要更多的前期设计，但 FPGA 或 ASIC 可提供最优的功耗/性能结果。越来越多的设计团队选择在硬件中实现其算法设计的原因正在于此。

        借助 HLS 很容易在 ASIC 或 FPGA 中实现设计。一种情况是使用 FPGA，其设计周期更简单，无需复杂且耗时的布线、布局和叠层规划方法。相比之下，ASIC 可以胜任大批量芯片生产，但需要的人力和成本要高得多。一些设计人员使用 FPGA 开发初始原型，借以分析软件和硬件设计。一旦满意并准备投入生产，他们便从 HLS 获取输出，快速将其重定向到所选的 ASIC 技术。

图 5：Catapult HLS 平台实现了 HLS 与功率分析、RTL 功率优化以及验证基础设施的融合

       Siemens Digital Indstries Software 的 Catapult® HLS 平台和 PowerPro® 解决方案是业界领先的 HLS 平台，可提供可靠的高质量结果。借助 Catapult，设计人员可以利用行业标准 ANSI C++ 和 SystemC 来描述功能意图，并将其提高到生产率更高的抽象层次。Catapult 平台提供了高层次综合与以下功能的强大组合：可测量、探索、分析和优化 RTL 功耗的 PowerPro，以及用于无缝验证C++ 和 RTL 的验证基础架构（图 4）。

自动驾驶 ASIC 示例

图 6：适用于汽车应用的复杂、高质量图像信号处理

       自动驾驶汽车的主要半导体供应商已经成功利用 Catapult 实现了算法密集型设计。接下来会简要介绍一些成功案例以帮助读者进行了解。

       Bosch 意识到，要保持自己在汽车领域的领先地位，必须逐步转向自动驾驶解决方案。BOSCH Visiontec 团队负责开发最先进的 IP 和 Ic，其中包含可实现识别汽车摄像头所拍摄图像的算法的高性能处理器。他们需要在不到一年的时间内实现三种图像处理设计，因此事关重大。让团队手动编写 RTL 代码，并在这一不断变化的环境中验证这些设计根本不切实际。因此，他们决定升级到C++ 层次，并采用 Catapult 流程。

       尽管技术规范在设计周期内不断演变，但通过采用包含功耗分析和优化功能的 HLS 流程，BOSCH Visiontec 团队仍得以在七个月内提前成功交付新设计。利用Catapult 的微架构探索，通过持续改进并使用低功耗流程，该团队得以快速开发出更高质量的设计，并将总功耗降低 30%。由于该团队的成功，此流程将被用于未来的新设计以及针对新标准或工艺技术的更新设计。

       Chips＆Media 是为众多市场（包括汽车和自主传感器处理模块）提供高性能视频 IP 的领先提供商。他们采用 HLS 设计流程来开发计算机视觉 IP，其中结合了深度学习和推理对象检测功能，可处理 4K 分辨率和 30fps 的输入视频。由于是第一次使用 HLS 方法，他们决定使用两条路线并行开发 IP。一个团队采用传统方法，使用手工编码的Verilog 开发 IP；另一个团队从 C 开始并使用 HLS 将代码综合到 Verilog 中。然后，他们比较各个流程的结果。

        RTL 编码花费了五个月时间，而学习 HLS 流程和 Catapult、编写 C 代码、综合为 RTL、验证并将 IP 集成到 FPGA 板中以成功演示视频 IP 产品，只用了两个半月的时间。HLS 团队轻松探索了许多架构，这在传统 RTL 流程中是很难实现的。

       STMicroelectronics 的成像部门将 Catapult HLS 用于一系列信号处理应用，包括汽车传感器（图 6）。HLS 的主要优点之一是无需额外工程资源即可提高 IP 价值。由于使用 SystemC 工作更容易，该团队得以高效地添加新功能，并探索不同的体系架构以实现最优的性能、功耗和面积。

       验证时间和工作量也减少。他们能在数小时内运行成千上万的测试，而使用 RTL 则需要数周时间。验证团队发现，自动功能时钟门控节省了大量的重新编码和调试工作，并将功耗降低了 10%。另外，对于这些复杂的设计，生成的 RTL 的结果质量非常出色。由于使用 HLS， 该团队在两年内创建了 50 多种图像信号处理设计，规模从 1 万门电路到 200 万门电路不等。

结语

       自动驾驶设计人员正在利用已针对神经计算和计算机视觉进行优化的新芯片架构，以更胜以往的上市速度打造更优质的自动驾驶车辆解决方案。为了最有效地实现ADAS 芯片，设计人员需要在更高的抽象层上工作，以提高设计和验证生产率。现有基于 RTL 的设计方法无法扩展以满足这种需求，因为自动驾驶汽车的 SoC 设计过于复杂，无法通过手工编码 RTL 进行高效设计。此外， 验证时间越来越长而无法控制，因此有必要尽早验证设计。对于自动驾驶系统，HLS 经证明能比 RTL 更快速、更高效地交付基于算法的更高质量设计。

       在所有支持自动化互联汽车的嵌套系统（例如，复杂的车载传感器和软件网络）以及这些车辆在城市里的最终部署中，都存在类似的设计和验证压力。现如今，大多数人都认同，随着这些汽车的上街行驶，它们将与其他交通节点混合在一起，而所有这些交通节点都会越来越多地作为服务进行消费，而不是由个人拥有并停放在车道上。芯片到城市的思维（以及越来越多的集成式数字孪生设计工具组合）正在帮助实现这一未来前景。

参考文献

       Jim McGregor, “AV Simulation Extends to Silicon,” [https://www.tiriasresearch.com/downloads/av-simulation-extends-to-silicon/] TIRIAS Research, May 2019

       Junko Yoshida, “Robocar SoCs: Designers’ Worst Nightmare | Siemens takes on challenges of AV/ADAS chip design and validation,” [https://www. eetimes.com/document.asp?doc_id=1334711] EE Times, May 17, 2019

       “David Fritz and Jim McGregor on Chips For Autonomous Vehicles, [http:// www.autonocast.com/blog/2019/5/22/144-david-fritz-and-jim-mcgregor- on-chips-for-autonomous-vehicles], The Autonocast podcast, Episode #144, May 22, 2019