|
DSP/协处理器组合优化3G基站
|
DSP Combined With Co-processor to Optimize 3G
Base Station
|
■德州仪器(中国)有限公司 丁刚
|
摘要:文章分析了3G基站符号级信道纠错的数字信号处理几种实现方法,比较了它们的优缺点,一个实例着重详细分析了DSP加协处理器方案,包括其在从开发周期、功耗和系统容量方面优点。
尽管有着随时随地因特网接入及传送多媒体流方面的美好前景,第三代(3G)移动电话标准还是迟迟未能商用。这里一方面有市场环境的影响,另一方面也与技术上的实现难度有很大关系。实际上,3G标准使得无线基础设施(基站和核心网)的复杂性增大了几个数量级,从而给核心处理器带来极大运算压力。3G不仅要求提供语音业务,而且要求提供并且主要是数据业务,如因特网接入,电子邮件,视频和图像传输,在线听歌等等。而对传统的语音业务则要求更高的音质,更多的容量。这些都对基站处理能力提出了很高的要求。
然而考虑到机架空间和功耗的限制,以及每信道单元成本的要求,处理能力的提高需要从整个基站系统的优化开始。本文则针对符号率的处理提出探讨。在符号率的处理中信道纠错占用了系统大量的处理能力,例如在一般的设计中,这部分的任务大约需要花去70%的DSP处理能力,并且在某些情况下会升至90%。本文主要从这方面来分析对基站系统的优化。
符号率信道纠错及其解码具体实现方案
在所有基于码分多址的主要3G标准中,为保证信道质量,一般是采用卷积码或并行级联卷积码(Turbo码)等前向纠错码来实现信道纠错,其中卷积码用于语音信道而Turbo码用于数据信道。
卷积码解码一般运用维特比Viterbi算法解码。而Turbo码解码则使用迭代结构的MAP(Maximum A Posterior,最大后验概率)译码器。这些前向纠错码的解码算法都已很完善,在具体的实现中变化的余地很小。
作为基站接收器中整个符号率信号处理功能的一部分,有以下几种方案可实现Viterbi与Turbo解码。
第一方案是在软件中处理所有前向纠错码,DSP在处理必需的任务外同时执行解码任务。这种方法在语音占主导地位的2G设备中很普遍,因为在2G标准中只有维特比算法用于前向纠错码译码,而维特比算法较易适用于软件中。但在3G系统中这种分工基本不现实。一方面Turbo译码使得运算量提高了一个数量级,纯用DSP来处理,600-MHz
TMS320C6416也仅能处理2个信道,更不谈那些180MHz到300MHz的DSP了。这种方案的主要优势在于灵活性,算法的实现精度及可编程控制。例如,使用硬件实现一般只处理8位数据,而需要12位以提供更高精确度或希望实施特定归一化方法的开发人员就会对此不满意。然而,在实际系统环境中,这种差别并不大,研究显示,MAP算法全浮点与8位实施间的BER降级不到0.1dB。同时,精度的提高或可编程性带来的优势并不能弥补处理能力的损失或降低DSP的需求量。
如果直接使用硬件来完成这些任务,性能将会大大加强,如同样是Turbo译码,硬件可以同时处理36个通道。再比如维特比译码,600MHz的DSP能处理134个通道,而硬件可以处理358个通道。较少的信道意味着更高的系统成本。一个纯软件的方案会需要2到3倍的600-MHz
DSP、更大板级空间,以及更高的耐热(功耗)这些都是不易被人接受的。增加DSP可能会超出系统功率预算并要求更为复杂的散热方案。如设计目标是翻新2G设备以执行3G处理,那么空间限值可能导致牺牲可处理的信道数量。
第二种方案是使用专用集成电路(ASIC)。依靠ASIC执行所有信号处理是个比较直接的解决方案,但会丧生可编程性。3G标准或处理方案的每次变化均需要开发新的ASIC进程,其面市时间通常需要9个月到1年,从而也会增加系统成本。相对来说,在可编程DSP上执行的软件就可轻松升级。一种低成本的替代方案就是ASIC仅完成纠错码解码工作,同时使用DSP做其他的信号处理。这种方式一个不利之处在于增加DSP与ASIC之间的通信,消耗大量I/O带宽。因为前向纠错码发生在符号速率处理中,因而会有大量地数据传递发生在必须在DSP与ASIC间。结果通常会增加延迟时间及功耗。在某些情况下,芯片间的通信带宽可能会占用过大以限值能被处理的信道数量。
如果没有成品的专用集成电路,开发商就需要自己开发ASIC。这时开发成本是很昂贵的,需使用百万门级的FPGA来开始。如果将这些FPGA流片成专用集成电路(ASIC),尽管最终芯片价格不高,但中间的开发成本和风险却不言而喻。
从这两种方案的介绍,我们可以得到两个结论,第一,硬件方案从性能和信道成本上来讲更加合适一些。第二,如使用DSP,则与ASIC之间的通信很重要,这些通信会影响整个系统的性能。这两个结论意味着如果有一个DSP集成了Viterbi和turbo硬件加速器,那将是一个很好的选择。这就是第三种方案,我们将以TI
TMS320C6416为例作一详细分析。
将维特比译码器和Turbo译码器集成进DSP片内——TMS320C6416
将Viterbi与Turbo加速器集成到DSP芯片中可提供其他两种方法所具有的优势,同时消除众多不足之处。专用协处理器可减轻DSP的前向纠错码解码处理负担,将其能力释放出来以执行其他功能,包括可编程、细分的系统功能。TMS320C6416就是这样的一颗芯片,片上除了高性能的C64x数字信号处理内核外,另外集成了用于维特比译码的协处理器VCP(Viterbi
decoder CoProcessor)和Turbo码译码的协处理器TCP(Turbo decoder CoProcessor)。图1、图2分别是TMS320C6416芯片中VCP和TCP的框图:
将DSP与VCP及TCP结合在一起尽管有可能无法发挥软件方案的灵活性,比如数字精度是没法更改的,但对于诸如约束长度以及生成多项式系数等编码参数,仍有充分的可编程性。
与软件方案相比,该方案的最大优势无疑是将前向纠错码转移到VCP和TCP后,DSP的处理能力得到释放。以时钟频率达600MHz的DSP
TMS320C6416来说,当把Viterbi处理转至VCP后,实际上所有额外的592MHz均可用于执行其他任务。当DSP在软件中进行Viterbi解码时,只可处理所剩的3MHz以及134个语音信道(表一所示)。Turbo解码的结果类似。剩余的容量为开发人员创造了通过改变处理的信道数量、改进语音质量、缩短系统延迟时间或其他符合3G标准的创新型细分其系统的机会。容量部分可用于控制功能,包括控制系统ASIC执行的控制操作。
与ASIC相比,由于DSP是可编程的,因此局限性要小的多。这就是说,每次标准变动时或可进行关键升级时无需重新构建设备。可编程设备能适应全球不同地区标准的细微变化,同时能通过软件修改接受创新。另一方面,Viterbi和turbo解码器所需的低级别操作,如MAP解码器中alpha与beta递归和Viterbi的蝶形运算,都已完好定义并可用硬件实施。由于在芯片中有效实施turbo与Viterbi解码,与VCP和TCP集成的DSP占用空间及功耗与当今无线基站普遍采用的DSP一样(比如,TMS320C6416
21毫米见方,600MHz功耗1.6瓦)。这样,现有2G设备可轻松改进新型处理器卡。此外,将片上VCP和TCP与DSP集成可解决占用I/0带宽的通信问题。与单纯的ASIC解决方案相比,这可极大地缩短开发时间。接下来我们就TMS320C6416详细介绍这种方案下的DSP与协处理器的通信,以及相应的协处理器的数据流。
DSP CPU与协处理器的通信
从概念上讲,VCP或TCP协处理器可看作能中断、与串行端口或Utopia接口类似的片上外设。但是,协处理器并不与芯片以外的任何东西通信,而上述外设却拥有外部连接。
在DSP与协处理器间的通信中,DSP为主协处理器为辅。通信协议是:DSP中央处理单元(CPU)将所需的输入数据与控制设置信息一起“传输”到协处理器。然后激活协处理器,等待协处理器完成数据处理,再从协处理器接收处理过的输出数据。
DSP CPU将数据发送至并从协处理器接收数据的概念可以也可以不如字面意义实施。例如,协处理器可能会具有本地内存,可进行输入及输出缓冲。此种情况下,DSP
CPU实际上是采用一个直接内存存取(DMA)控制器将内部或外部DSP内存间的数据传输到协处理器本地内存中,以避免浪费数据传输的CPU循环。此外,DSP
CPU及协处理器也可拥有共享内存,以某种仲裁逻辑控制不同内存区域的存取。
协处理器需要通知DSP CPU解码进程完成。可通过在专用寄存器中设置标志或生成到CPU核心的中断信号完成。
如上所描述的那样,数据到协处理器的传输到数据处理完返回时有一段延时。由于CPU和协处理器彼此独立运行,CPU不需要在等待协处理器完成解码时处于空闲状态,可以做些其他工作。一般情况下,处理的进行方式是:在协处理器对当前帧解码的同时,CPU会预处理下一个帧或对先前的数据帧进行后续处理。
与CPU和协处理器间数据传输有关的问题,如时间延迟、CPU中断以及共享内部总线等,可通过采用具有高吞吐量、高传输链接功能,以及具有支持每个协处理器专用I/0信道的有效增强DMA引擎轻松加以克服。通过DSP
CPU与协处理器,有效传输与并行操作可使时钟有效利用达到最大化。
以TMS320C6416为例,它有TCP和VCP两个协处理器,CPU与TCPVCP之间有一条32位的外围总线和一条64位的EDMA总线。CPU通过外围总线(访问映射在CPU内存空间的寄存器)来控制协处理器的运行,而通过EDMA与协处理器进行数据交换。在DSP64个EDMA通道的事件资源中,有四个事件被用于协处理器与CPU的通讯,每个协处理器占用两个事件用来发送或接受数据。这些事件如下:
事件28是VCP接受事件 (VCPREVT),作为EDMA从VCP到DSP传输(DSP接受数据)的同步事件。
事件29是VCP发送事件 (VCPXEVT),作为EDMA从DSP到VCP传输(DSP接受数据)的同步事件。
事件30是TCP接受事件 (TCPREVT),作为EDMA从TCP到DSP传输(DSP接受数据)的同步事件。
事件31是TCP发送事件 (TCPXEVT),作为EDMA从DSP到TCP传输(DSP接受数据)的同步事件。
在解码过程中,协处理器会发出不同的事件来驱动EDMA完成相应的数据传输。作为示例,图3是独立模式下TCP事件的产生:
输入和输出数据流
一般来说,Turbo或卷积码解码的输入是从信道接收到的软判定数据帧,该数据代表发射机编码器的输出加上传输中引入的噪声。解码器的输出是硬判定帧,是或最接近编码器的输出。
具体到TMS320C6416,它的VCP协处理器把分支度量(Branch Metrics)作为输入,该度量由信道软判定计算而来。软判定并不直接输入到VCP,以便兼容2G、2.5G和3G不同标准并可实现2G的Viterbi均衡。输出是上述的硬判定或16位软判定。软判定可用于后处理,以便提高编码性能并进一步降低BER。TCP把系统和奇偶比特的对数域似然率作为输入,对数域似然率通过缩放信道软判定得到。它也输出硬判定。
另外,TMS320C6416还可以输入诸如约束长度、编码速率、编码生成多项式、帧长度以及帧终止(即,尾比特结构)等控制参数,提供了一定的灵活性和可编程性,以支持更多的标准。如C6416的VCP可支持5到9的约束长度,支持三种码率等等,TCP支持3GPP或3GPP2所有的Turbo码。
对于TCP而言,附加参数包括交织表及迭代次数。由于Turbo译码是一个迭代过程,TCP有一个功能是,在指定数量的重复完成之前,按照用户定义的阈值确定解码质量是好还是坏,如果以达到需求的阈值则退出迭代,从而可以减少处理时间。它还可以执行不同的软件/硬件分工,在此TCP只是一个MAP解码器(运算量最大的部分),而其它所有功能在软件中实现,给开发者更大的灵活性。
结论
站符号级信道纠错的数字信号处理几种实现方案的分析,比较了它们的优缺点。从成本和灵活性上来看,DSP集成协处理器的方案有着很大的优越性,这一点可以从TMS20C6416看出。
|
|