决定、决定：硬件加速器还是 DSP？

在我关于这个主题的前两篇博客中，我谈到了为什么 DSP 突然无处不在，特别是为什么它们开始取代一些定制硬件加速器 (HWA) 作为更灵活和面向未来的选择。在这篇博文中，我想讨论一个更详细的分析，您可以根据这些分析来决定是否应该考虑 DSP 而不是 HWA 实现。

（来源：CEVA）

我在上一篇博客中提到了 DSP 的一些理想应用。调制解调器或音频信号的信号处理就是明显的例子。另一个非常常见的例子是自动驾驶汽车雷达中的信号处理，这与调制解调器中的信号处理非常相似。其中许多是围绕硬件加速器和小型控制器构建的。我们现在看到，这些解决方案提供商有一个显着的趋势，即转向架构，其中更多的功能基于运行在 DSP 上的软件，结合了当前由 HWA 处理的信号处理，甚至是一些控制。原因很简单：软件在功能方面提供了更大的灵活性，并且能够以更低的成本和更及时的能力来适应不断发展的通信标准。

全球定位是另一个应用，在这种情况下，大量利用 DSP 固有的数学功能进行三角测量。您最初可能认为 GPS 支持就是您所需要的，也许您可​​以在硬件加速器中构建一个非常快速的实现。但是，在全球 GNSS 标准中，您还需要考虑对 GLONASS（俄罗斯）、Galileo（欧洲）和北斗（中国）的支持。 GPS 的硬连线实现可能会不必要地限制您的市场，因为如果您在 DSP 上运行，则可以在软件中实现对所有变体的支持。

到目前为止，原则上很好，但是 DSP 实现与自定义硬件实现相比将如何执行？我今天将用一个流行的例子来说明：假设您正在构建一个 IoT 应用程序，并且您计划使用 NB-IoT 进行通信。子帧长度为 1ms，它定义了必须在该时间内完成的某些处理的边界限制。在这个例子中，这将包括物理层算法、L1 控制代码和协议栈。对于以 100MHz 运行的典型低功耗 DSP/NB-IoT 平台，1ms 可为您提供 100k 个周期来完成这些计算。

要估计在等效的 DSP 实现中可以期待什么样的性能，您需要与嵌入式 DSP 供应商合作。这样的公司应该已经在他们的平台上为多个应用程序提供软件解决方案，他们将以其性能和功率为特征。为了性能，他们应该能够为您的功能提供周期计数估计，在这种情况下是 NB-IoT 调制解调器，并为您提供类似于下图的图表。图中的每个点代表执行所需的周期数，并且该图是在随时间变化的负载范围内绘制的。该图还应显示给定选定工作频率的峰值允许周期。

（来源：CEVA）

现在您有一种方法可以估计您的应用程序负载是否会在该频率下工作，或者您是否可能需要增加频率以提供更多空间。当然，这个估计是基于供应商的软件实现的，尽管可以合理地期望它会得到很好的调整。您不必承诺使用他们的软件，但估计值应该足以指导您的决策。

如果您在首选工作频率下有足够的余量，也许您可​​以将更多 HWA 功能移到 DSP 上，或者添加更多差异化功能，例如 GNSS 位置支持。另一方面，如果您需要提高频率以满足延迟要求，这也是可能的，但您应该考虑到提高频率会增加面积和功耗。

获得功耗估计的一种快速方法是查看有多少软件将进入真正的 DSP 代码，使用并行性、MAC 单元等，以及多少将进入控制代码 - 通常的通用 -目的代码调用函数、决策和其他标准操作。你通常可以注意到这个分裂，比如 40% 的控制代码和 60% 的 DSP 代码。 DSP 供应商通常会为这两种情况提供典型的功率数字，例如控制代码为 2mW，DSP 代码为 4mW（在每种情况下都为 100MHz）。在您的计算中，您应该考虑 DSP 的平均活动，例如频率的 50%。因此，在此示例中，您将估计 (0.4 * 2 + 0.6 * 4) * 0.5 =1.6mW 平均功率（假设平均活动率为 50%）。

总之，您应该能够对加速器功能的 DSP 实现预期的性能和功率进行相当合理的估计（除非您正在开发一些非常不寻常的东西——在这种情况下，您应该在 DSP 的SW 工具来获得非常准确的周期计数估计）。当您考虑从软件实现中获得的额外灵活性以及通过将多个加速器组合到一个处理器上来节省成本的能力时，DSP 解决方案看起来非常有吸引力。