DSP+CPU的结合：物联网处理的最佳选择

一般认为，在需要数字信号处理时（在调制解调器的物理层、智能扬声器的麦克风波束形成或跟踪设备的地理定位时）要使用DSP。如果需要数字控制（运行协议栈或管理音频编解码器或GNSS的控制方面），则要使用MCU。由于典型的物联网设备需要这两种功能，因此必须使用两个或更多内核。对于对续航时间要求不高的高利润设备，这也许不是什么大问题，但对许多物联网应用而言这可能是一个严重缺点。对于这类应用，经优化的复合处理器可以更经济高效地满足这两种需求，并延长设备续航时间。我们对此进行了非常详细的分析；我们认为这样的解决方案不仅可行，而且在各种物联网应用中具有很强的竞争力。

想想共享单车或共享踏板车。这些设备显然需要跟踪，因此嵌入式设备必须能够确定位置，针对这个问题的现代解决方案是使用GNSS（全球导航卫星系统）。它还必须能够进行通信，由于通常远离蓝牙网或Wi-Fi接入点，因此蜂窝接入是理想平台。由于不需要传递大量数据，NB-IoT是最理想的协议。考虑到用户对安全性和隐私性的需求增加，还需要一定程度（可能远多于预期）的本地计算。

这样一来，你的简单设备必须支持4G（可能是5G）、GNSS、应用程序和加密，也许还需要安全区/安全启动。但是，你计划将数以千计的这类设备投放到许多城市的许多地点，能否提供最佳可用性和具竞争力的价格将决定企业的存亡。因此，尽可能降低成本和能耗（减少维护）成为决定企业存亡的关键。

我们认为应该特别关注这些应用中的计算需求，特别是数字信号处理和数字控制的平衡。我们首先研究了NB-IoT连接、GNSS和安全标准的基础算法。我们将以约100MHz运行的资产跟踪器应用程序的活动分解为DSP功能（基带调制解调器和物理层控制的某些部分）和控制功能（协议栈、安全性和一般系统管理）。对于NB-IoT不经常通信的轻量级应用程序，我们发现时钟周期的消耗构成如下：

调制解调器PHY（主要是DSP）- 约35％

L1控制（DSP和控制）- 约25％

协议栈（主要是控制）- 约40％

在此，信号处理和控制的时钟周期分布非常均匀，说明合并处理器是合理之举。如果不能同时运行这两种功能，是否会影响性能？其实不会。这些都不是高性能应用程序。在需要处理速度的情况下（比如最新eNB-IoT版本），通常可通过将功能排序降低净能耗。让每个功能依次快速运行和停止，这是能源管理的常见做法。

为扩展我们的分析范围，我们研究另一种热门应用——声音处理和语音控制。想想智能扬声器、无线耳塞、可穿戴设备、声控设备以及由特殊噪音（如玻璃破碎）激活的安全设备。这些应用具有不同的需求组合：音频编解码器（如杜比音乐播放）、语音/声音拾取降噪、以及用于识别触发短语甚至有限词汇以便进行设备控制的神经网络处理。

在此，我们使用杜比全景声（Dolby Atmos）以及内部降噪和语音识别基准来按时钟周期分析活动，并发现以下大致分布：

音频编解码器- 控制占70％ ，DSP占30%

降噪–DSP（许多滤波器）占90%，控制占10%

RNN / LSTM神经网络- DSP占60％，控制占40％

这些用例更多地偏向DSP活动，但控制活动仍占一定比例，因此采用组合核心是合理做法。

在一个处理器中组合两个功能的理由看起来非常充足，但这不仅仅是将一些MAC纳入控制器。DSP必须达到严格的DSP应用标准，比如最新通信标准。因此，它需要16x16和32x32 MAC、SIMD以及对GNSS需要的浮点和双精度浮点的本地支持。随着NB-IoT和不同GNSS标准的不断发展，该架构必须特别灵活，以便在软件层面进行调整。同时，这样的解决方案必须作为控制器高效运行、代码尺寸非常紧凑（很多数字处理DSP在这方面效率不高）和高效的开箱即用C语音开发支持，以便连接既有代码或者开放生态系统代码。

我们基于这一理念开发出CEVA-BX1和CEVA-BX2内核。最近的Linley Group报告中对它们进行了审核。该报告提供了详细技术细节，并说明平台可独自执行（对另一种解决方案）需要DSP IP和MCU IP一起才能完成的任务。这值得任何关注能耗和成本的人深思。