利用片内FFT改善DSP性能

只看该作者 · 2013-1-24 21:06

从根本上来说，具体选择何种数字信号处理器来处理DSP密集型任务取决于MIPS，以及DSP支持的片内和片外存储器容量。MIPS越多，可以处理计算要求更多的应用，同时执行代码所需的时间也越长。显然，存储器容量越大，就能容纳更多代码，并根据应用需要提供更多中间数据存储。

本文主要介绍片内滤波器/FFT引擎如何帮助显著减轻DSP内核工作负荷，从而节省MIPS，让更多MIPS可以用于进一步后处理任务或执行其他任务。

图1 未采用该引擎的现有框架

MIPS计算
这点完全取决于应用，每种应用均有各自的MIPS要求。假定在音频解码器应用中，经过解码的PCM立体声位流必须以48kHz的速率驱动输出至编解码器，则两个立体声采样/字之间的时间为1/48kHz = 20.8μs。这意味着后续立体声采样应在此时间内准备就绪。一般数据处理以帧形式进行，因此我们应该考虑一个缓冲，而不是一个立体声采样。

假定输出缓冲大小为1024立体声字，那么应用有1,024 * 20.8μs的时间准备相同大小的下一缓冲。通常，输出缓冲采用乒乓式工作模式，当数据从一个缓冲输出到编解码器时，内核上运行的应用会填充另一缓冲。此时应执行DSP内核上运行的解码器代码，以便在此指定帧速率内使另一缓冲获得新解码的采样。如果执行代码和在缓冲中将数据准备就绪所需的时间等于输出帧速率，则意味着应用占用了所有可用的内核MIPS。一般而言，我们会优化应用代码或选择更快的处理器，以确保实时完成数据处理，并避免丢失有意义的音频或视频数据。

图2 图示为同一应用完全在内核上运行时与未改变应用框架但在内核和减负引擎之间分割运行时的差异

减负引擎
音频应用分为两大部分：主处理部分，如解码器；和后处理部分(PP)，如多频段均衡器。PP算法主要由滤波操作构成。例如，多频段均衡器将内置数个IIR滤波器组。支持FIR、IIR和FFT的片内减负引擎可以帮助显著减轻DSP内核的后处理任务负荷，从而最终节省内核MIPS。换言之，DSP现在可以轻松地容纳之前因MIPS不足而无法容纳的算法。

采用片内减负引擎，可以在DSP上封装更多MIPS，因此非常有利。不过，为了适应此类先进的DSP架构，需要修改应用的软件框架。
图1显示在DSP上实现的大多数现有应用框架，这些框架都不支持片内减负引擎。这种情况下，整个信号链中的代码执行和数据处理流程完全连续进行。DSP内核首先执行主要应用算法，然后执行PP，最后再将数据发送到编解码器。经过速度优化的应用和能够以较高内核时钟频率工作的DSP可以获得额外的MIPS。这些额外MIPS更像是支持任何未来功能增强或软件升级的储备空间。

图3 DSP内核与滤波器引擎同时工作

只看该作者 · 2013-1-24 21:07

保留减负引擎
图2显示同一应用完全在内核上运行时与未改变应用框架但在内核和减负引擎之间分割运行时的差异。在减负引擎运行速度低于DSP内核速度时，这样没有任何帮助。通常，DSP架构使用以下两个时钟域：内核时钟和系统时钟。

片内外设和控制器在系统时钟上运行；大多数情况下，系统时钟是内核时钟的一半。如果减负引擎工作速率低于内核时钟速率，那么这种框架会导致性能下降并造成内核MIPS浪费。

如图2中所示，减负引擎以串联方式与整个信号链相连。当减负引擎处于活动状态时，DSP内核就会空闲，因而导致内核MIPS浪费。由于该过程完全按顺序执行，而DSP内核和减负引擎紧密耦合，因此这些未用内核周期将会完全浪费。这就违背了增添减负引擎的初衷，即用于执行FIR、IIR和FFT等DSP操作。

应用框架
要适应此类增强型架构，需要更改应用框架。这一方法的思路是以并行方式运行DSP内核和减负引擎，从而获得更多空闲内核MIPS。这些额外的MIPS可以供给更多后处理级或执行完全不同/不相关的任务。

如图3中所示，DSP内核与滤波器引擎同时工作。滤波任务现在由滤波器引擎负责处理。数据以流水线形式通过这些模块，从而实现并行操作。当滤波器引擎处理帧“X”时，DSP内核处理该引擎为帧“X-1”（前一帧）提供的数据，然后开始处理下一帧“X+1”的数据；这就使得更多MIPS可供内核使用。通过将滤波和FFT任务转移到该引擎，可供内核使用的MIPS变得更多，因此现在就可以轻松地在DSP上实施之前因MIPS不足而无法容纳的应用。

图4 图4a和4b显示一种用作基准的音频解码器的框架以及MIPS分配情况

图5 缓冲管理的执行方式和数据出入这些乒乓式缓冲的方式

图4a和图4b显示一种用作基准的音频解码器的框架以及MIPS分配情况。图4中未使用减负引擎，包括PP在内的整个应用都由DSP内核执行。此处PP算法可视作图形均衡器，其主体为IIR滤波器代码。此外，复杂的PP算法可以在DSP内核活动和减负引擎活动之间分割，而后者可转移到减负引擎。由于大多数PP任务会转由片内引擎来处理，因此就可以容纳需要更多内核时间(MIPS)且更为复杂的PP算法。

只看该作者 · 2013-1-24 21:07

图4和图5显示此方法的实现方案。图中显示缓冲管理的执行方式和数据出入这些乒乓式缓冲的方式。采用这种方法时，DSP内核和滤波器引擎之间并无紧密耦合。DSP内核和滤波器引擎均耦合至输出串行端口DMA。DSP内核在数据的输入帧运行解码器，并用经过解码的音频数据采样填充缓冲。然后，处理前一帧经过滤波器引擎处理的数据，并填充串行端口输出缓冲。假定所有这些操作都在输出帧周期内完成，那么内核会等待串行端口DMA的指示，表明前一缓冲已输出并且现在可以重复使用或覆盖新数据。滤波器引擎也遵循相同流程。不过，数据处理以流水线方式进行，确保DSP内核和滤波器引擎之间不存在相关性，两者能够各自独立工作并依赖于输出数据速率。

图6和图7是不同时刻数据和控制流的简单示意图。图中清楚地显示DSP内核和减负引擎如何以并行方式相互独立工作，同时各自仅依赖于输出帧速率。

图6中，时间之间的关系为(T2-T1) = (T1-T0) = T max，即SPORT DMA以特定帧速率将数据驱动出输出数据缓冲所需的时间。DSP内核和减负引擎必须在此时间周期(T max)内完成各自任务。

 T1时，产生SPORT DMA中断 -> SPORT开始输出“OutPut DataBuffer2”；
 T1时，内核解码“帧X+1”并开始填充“Decoded DataBuff1”；
 T1时，减负引擎读取“帧X”的“Decoded DataBuff2”、加以处理并填充“Off-Load Engine WriteBuffer2”；
 T_Decode_Done时，内核开始读取“帧X-1”的“Off-Load Engine WriteBuffer1”、加以处理并填充“OutPut DataBuff1”；

图6 DSP内核和减负引擎必须在此时间周期(T max)内完成各自任务

图7 不同时刻数据和控制流的简单示意图

只看该作者 · 2013-1-24 21:07

Core_Done时，内核完成所有任务并等待SPORT DMA中断；
 Off-Load_Engine_Done时，其等待SPORT DMA中断；
 “Core_Done”时间必须小于或等于T Max；
 “Off-Load_Engine_Done”时间必须小于或等于T Max；
 内核和减负引擎之间无相关性。

从图7可以看出：

 T2时，产生SPORT DMA中断 -> SPORT开始输出“OutPut DataBuffer1”；
 T2时，内核解码“帧X+2”并开始填充“Decoded DataBuff2”；
 T2时，减负引擎读取“X+1”的“Decoded DataBuff1”、加以处理并填充“Off-Load Engine WriteBuffer1”;
 T_Decode_Done时，内核开始读取“帧X”的“Off-Load Engine WriteBuffer2”、加以处理并填充“OutPut DataBuff2”；
 Core_Done时，内核完成所有任务并等待SPORT DMA中断；
 Off-Load_Engine_Done时，其等待SPORT DMA中断；
 “Core_Done”时间必须小于或等于T Max；
 “Off-Load_Engine_Done”时间必须小于或等于T Max；
 内核和减负引擎之间无相关性。

以这种方式使用减负引擎时，将会有更多MIPS余量供内核使用；用此方法减负效率可以高达98%。

拆分任务法
这是将内核任务转移到片内减负引擎的另一种方法。这种方法更适合涉及多通道数据的应用。由于这种方法并不采用数据流水线结构，因此不需要对现有应用框架做太多修改。其工作方式仍然是完全按顺序执行，并且紧密耦合。通过在DSP内核和减负引擎之间进行数据通道分割，从而节省内核MIPS。假定要处理12个此类数据通道，则8个通道可以转移给滤波器/FFT引擎，而DSP内核负责处理4个通道；这样DSP内核和引擎即可在相同时间内一起处理所有12个通道。DSP内核和减负引擎同时开始处理数据。通过合理地进行分割，应用可以确保内核不会在处理完所分配的通道之后出现空闲状态。换句话说，DSP内核和减负引擎几乎可以同时完成数据处理。

随着这种趋势延续，增强型音频和视频主处理和后处理算法消耗和需要的MIPS和存储器容量会日益增加。高效使用可用MIPS和DSP支持的存储器将仍旧是系统设计人员面临的一大挑战。不过，通过增加本文所述的减负引擎片内支持，并根据增强型架构适当调整软件用法模式，则可在DSP内封装更多速度密集型算法。