完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
摘要:文章分析了3G基站符号级信道纠错的数字信号处理几种实现方法,比较了它们的优缺点,一个实例着重详细分析了DSP加协处理器方案,包括其在从开发周期、功耗和系统容量方面优点。
|
|
相关推荐
5个回答
|
|
尽管有着随时随地因特网接入及传送多媒体流方面的美好前景,第三代(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为例作一详细分析。 |
|
|
|
|
|
|
|
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看出。 |
|
|
|
只有小组成员才能发言,加入小组>>
1932个成员聚集在这个小组
加入小组我的项目我做主,使用GN+Ninja来完成构建系统(VSCode开发RT106X)
36419 浏览 0 评论
NXP IMX8应用处理器快速入门必备:技巧、使用、设计指南
4831 浏览 1 评论
6103 浏览 1 评论
6815 浏览 0 评论
NXP i.MX6UL开发板(linux系统烧录+规格+硬件+模块移植)使用手册
4247 浏览 0 评论
642浏览 2评论
求助,S32G上Core M启动后如何让Core A在Flash指定位置加载uboot?
639浏览 2评论
ESP32-WROVER-IE + LAN8720以太网,GPIO0电压只有1.6v,无法正常进入spi flash boot模式如何解决?
640浏览 2评论
求分享适用于PN7160 Android的NFC工厂测试应用程序
727浏览 2评论
840浏览 2评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-21 12:56 , Processed in 1.161261 second(s), Total 86, Slave 69 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号