位置:51电子网 » 技术资料 » D S P

DSP/协处理器组合优化3G基站

发布时间:2008/5/27 0:00:00 访问次数:505

摘要:文章分析了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硬件加速器,那将是一个很好

摘要:文章分析了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硬件加速器,那将是一个很好
相关IC型号
版权所有:51dzw.COM
深圳服务热线:13692101218  13751165337
粤ICP备09112631号-6(miitbeian.gov.cn)
公网安备44030402000607
深圳市碧威特网络技术有限公司
付款方式


 复制成功!