基于ARM7TDMI的SoC语音处理系统的设计

4 性能优化

语音处理的实时性要求很高，否则，若数据处理速度跟不上语音变化速度，就会在录音时出现刚采样的数据覆盖了先采入但未处理的数据；在放音时，出现播放的速度比实际语音慢。当然，如果用足够大的缓冲，可以避免录音出现的问题，但放音出现的问题是无法避免的。同时，鉴于存储资源对于嵌入式系统是很宝贵的，故此方案没有实际价值。上文介绍的“双Buffer”机制，能够使采样和编码之间、解码和播放之间分别互不影响、并发执行，易于控制；但要满足实时性要求，还要使编解码速度符合采样和播放的要求。语音速率是8 KB/s，而系统中一个采样点用16位表示，故编解码速度不能低于16 KB/s（即每秒至少编码16 KB的PCM码，每秒至少解出16 KB的PCM码）。表1是未对系统优化前，测试裸机无操作系统情况下，处理512 KB的PCM码（对应128 KB的ADPCM码）所用时间。该测试是使用SoC内部定时器TIMER进行的，见参考文献。测试结果显示,系统优化前没有满足语音实时性要求。 　


  
到此，系统目标代码都是在SDRAM中运行的。SEP3203提供了一个很有用的模块——片内高速存储器eSRAM。eSRAM存取速度非常快，可达到0.89 MIPS/MHz，所以对系统性能有很大的优化作用，而SDRAM却只能有其性能的1/3左右。表2是在50 MHz时钟、32位ARM指令情况下,SDRAM和eSRAM的性能比较。各项指标的意义见参考文献。

但是，SEP3203的20K的资源是有限的，不可能也不必要将所有代码都放在其中执行。ARM集成开发工具提供了Profile功能，可以对整个程序进行统计分析，得到各部分代码（主要以标准C函数为单位）所耗时间占系统总时间的百分比。通过对软件系统做Profile分析，得到各编解码库函数在总编解码时间内所占的百分比，其中主要部分如表3所列。


  
以上三个函数在总编解码时间内占用了近80 %的时间（Quan()、Fmult()、Update()的功能分别为量化表查找、定点化的浮点数乘法、状态变量更新），对这些代码优化就会明显提高编解码速度。把这些函数代码整合到文件rec_esram.c中，然后加载remap.scf文件进行内存映像（*.scf文件是ARM ADS集成开发工具提供的链接脚本文件）。下面是remap.scf文件的内容：


  
进行内存映像后，rec_esram.c的目标代码rec_esram.o（约为1.5KB）就加载到eSRAM（起始地址为0x1fff0000）中执行了。表4是经过eSRAM优化后编解码速度测试结果。


  
在有操作系统的情况下，也对语音系统性能进行了测试，如表5所列。该操作系统为东南大学专用集成电路系统工程技术与研究中心自主研发的面向嵌入式应用的ASIXOS，提供图形用户界面、网络、时钟、实时中断管理等支持和清晰的应用程序开发接口。语音系统为该OS环境中的一个应用，有独立的用户界面和底层服务。限于篇幅，本文不再详述。

从以上测试可以看出，在经过eSRAM优化后，无论是在裸机上还是在有操作系统的情况下，编解码速度都能满足语音实时性的需要，达到了设计要求。


   
结语

在设计一款面向多媒体应用的嵌入式系统时，实时性能非常重要。本文提出了一种基于ARM7TDMI内核的SoC中语音处理系统的设计方案，并根据该款SoC具有eSRAM的特点，进行了系统性能的优化。对样机的测试表明系统在主频70 MHz、有操作系统的情况下编码速率为19.88 KB/s，解码速率为22.68 KB/s，达到了语音系统的实时性要求。而且，如果语音处理作为样机的子系统应用，其硬件设计也支持MP3播放和LCD触摸屏的功能，实现了系统板面积减小、整机成本降低的目的，不失为一种高效价廉的设计方案。