移动通信系统终端的信道译码器及译码方法转让专利
申请号 : CN200510132441.8
文献号 : CN1988521B
文献日 : 2010-07-21
发明人 : 董胜龙 , 郑未
申请人 : 大唐移动通信设备有限公司 , 上海大唐移动通信设备有限公司
摘要 :
本发明公开了一种适用于第三代移动通信系统终端的信道译码器，涉及基于硬件实现译码的信道译码器及其相应的译码方法，为解决现有译码效率低而提出，为解决上述问题，该信道译码器包括：用于判断无线信号数据信道类型的信道类型判断模块；用于各传输信道译码的一个以上的信道译码逻辑模块；用于控制各信道译码逻辑模块启动与否的控制模块。本发明同时公开了一种基于前述译码器的译码方法，包括：判断传输信号数据的信道类型；根据确定后的信道类型选择并启动欲使用的信道译码逻辑模块；按所选择的信道译码逻辑模块进行信道译码。本发明拓宽产品适应面、可节省90％以上的DSP运算资源；并节省了DSP上珍贵的内存资源。
权利要求 :
1.一种适用于移动通信系统终端的信道译码器，其包括：
用于判断无线信号数据信道类型的信道类型判断模块；
用于各传输信道译码的一个以上的信道译码逻辑模块；
用于控制各信道译码逻辑模块启动与否的控制模块，
其中，所述信道译码逻辑模块具体为：用于码组合传输信道信号数据分离的数据分离模块、用于信道解映射的物理信道解映射模块、用于将子帧依次结合起来的子帧级联模块、用于解除第二次交织的第二解交织模块、用于比特解扰的解扰模块、用于恢复和整合数据的解速率匹配模块、用于解除第一次交织的第一解交织模块、用于帧长恢复的帧长恢复模块、用于信道解码的信道解码模块、用于将码块结合的码块级联模块和用于差错检验的循环冗余校验模块。
2.根据权利要求1所述的适用于移动通信系统终端的信道译码器，其特征在于，所述信道译码逻辑模块是根据移动终端需译码的所有传输信道而设置的，即对于任一传输信道，可选择相应的信道译码逻辑模块组合而实现译码。
3.根据权利要求2所述的适用于移动通信系统终端的信道译码器，其特征在于，所述控制模块为命令寄存器，所述命令寄存器通过相应的数字位控制信道译码逻辑模块的工作状态，命令寄存器数字位输出为高电平时，对应的信道译码逻辑模块启动，否则该信道译码逻辑模块关闭，数据旁路。
4.根据权利要求1所述的适用于移动通信系统终端的信道译码器，其特征在于，所述数据分离模块、物理信道解映射模块、子帧级联模块、第二解交织模块和解扰模块依次连接组成码组合传输信道译码加速器，所述解速率匹配模块构成解速率匹配加速器，所述第一解交织模块、帧长恢复模块、信道解码模块、码块级联模块和循环冗余校验模块依次连接组成传输信道译码加速器。
5.根据权利要求4所述的适用于移动通信系统终端的信道译码器，其特征在于，所述码组合传输信道译码加速器的各信道译码逻辑模块由同一个命令寄存器控制，解速率匹配加速器由一个命令寄存器控制，传输信道译码加速器的各信道译码逻辑模块由同一个命令寄存器控制。
6.根据权利要求5所述的适用于移动通信系统终端的信道译码器，其特征在于，控制码组合传输信道译码加速器和传输信道译码加速器的命令寄存器至少为5位的寄存器。
7.根据权利要求1至6中任一权利要求所述的适用于移动通信系统终端的信道译码器，其特征在于，所述信道译码逻辑模块是由相应的逻辑电路或芯片实现的。
8.一种基于权利要求1的信道译码器的终端信道译码方法，其特征在于，该方法包括以下步骤：(1)判断传输信号数据的信道类型；
(2)根据确定后的信道类型选择并启动欲使用的信道译码逻辑模块；
(3)按所选择的信道译码逻辑模块进行信道译码。
9.根据权利要求8所述的终端信道译码方法，其特征在于，所述步骤(3)中按所选择的信道译码逻辑模块进行信道译码具体为对各传输信道进行串行译码。
10.根据权利要求8所述的终端信道译码方法，其特征在于，所述信道译码逻辑模块是由命令寄存器启动的，所述命令寄存器通过相应的数字位控制信道译码逻辑模块的工作状态，命令寄存器数字位输出为高电平时，对应的信道译码逻辑模块启动，否则该信道译码逻辑模块关闭，数据旁路。
说明书 :
技术领域
本发明涉及一种移动通信系统中信道译码器及其译码方法，尤其涉及一种基于硬件实现译码的信道译码器及其相应的译码方法。
背景技术
信道译码是3G通信系统终端物理层的一个重要环节。如图1所示，以TD-SCDMA为例，信道译码过程是：接收到无线射频信号后根据相关参数完成JD(Joint Detection，联合检测)，再输出软比特的译码，最后将译码后的数据发送到高层(High Layer)的过程。
信道译码需要处理的信道类型有：DCH(专用传输信道)、BCH(广播信道)、FACH(前向接入信道)、PCH(寻呼信道)、PICH(寻呼指示信道)和FPACH(快速物理接入信道)，其中DCH的译码过程最为复杂，其他信道的译码过程则依据高层配置，可能有所简化。如图2所示，以DCH的译码过程为例进行简单说明。该译码过程包括两部分：解复用前的译码过程和解复用后的译码过程。首先需要针对整个CCTrCH(码组合传输信道)进行译码，然后再针对每个分解的TrCH(传输信道)进行译码。
在目前的3G终端中，信道译码过程在DSP上实现过程主要是通过软件方式实现的。如图3所示，现有的信道译码方法首先确定欲解码的信道类型，然后针对每种信道类型的解码过程，利用软件分别进行编程，当确定了信道类型后，直接调用该信道类型对应的解码程序进行解码。例如，如果确定欲解码的信道类型为专用传输信道，将调用相应的解码程序执行图2所示的解码流程。对于不同的信道类型，解码过程不同。这样，在实际解码过程中，由于软件实现时必须针对不同的信道类型分别进行解码，必然导致各解码程序的不同，导致了工作人员工作量的增加，并且，软件解码的方式对于将来的维护也很不利：必须针对不同信道类型进行；若不同的解码程序是由不同的代码编写(平台不同)，将来则会限制该编码程序的移植性。由于大部分均采用软件进行解码，必然会造成系统资源的大量消耗，这对处理能力有限的终端来讲，无异降低了其总体性能。
具体而言，现有的通信系统终端采用DSP(数字信号处理器)实现信道译码时存在以下缺点：
(1)为满足不同信道的译码方式，现有信道译码大部分由软件实现，这必将消耗大量的DSP运算资源；现有的移动终端大都通过纯粹的软件方式实现信道译码，这消耗了整个系统60％以上的DSP运算资源。另外一些终端只是将Viterbi和Turbo译码算法采用硬件实现，而信道译码的绝大多数过程还是软件实现，这样只能节省很小一部分(大约10％)运算量，整个译码过程仍然需要很多的DSP运算资源。这无疑造成了终端性能的降低。
(2)实现策略：分别针对不同的信道类型调用各自的信道译码函数，这样就需要为每种信道编写和测试译码函数，工作量大。
(3)调度策略：需根据每次得到的传输时间间隔(TTI)参数确定调度时机；由于一种业务可能存在多个传输信道的复用，而且每个传输信道的TTI不尽相同。这就造成信道译码过程的两个阶段：解复用前的译码过程和解复用后。所以要根据当前时刻和信道TTI参数，确定对哪些传输信道进行译码处理。由于每一种业务的译码调度过程中存在大量的判断和计算过程，各种业务之间、同一种业务的多个传输信道之间都存在复杂的调度过程，因此实现起来代码实现难度、出错概率和测试工作量都很大。
(4)内存分配原则：按照最大可能的传输信道组合形式分配需要的最大内存空间；每种传输信道的译码调度周期可能存在不同，在一个TrCH译码过程执行之前，关于该信道的数据必须被完整保留，所以必须开辟一个可以包含所有传输信道完整译码数据的Buffer(缓存)，对于系统资源相对有限的终端而言，造成了巨大的资源消耗。
(5)代码使用效率：软件实现策略很可能导致不同平台的代码开发，可移植性和复用性差。每种DSP使用的语言平台可能不同，当在一个新的DSP上开发时，过去开发的代码往往不能移植，必须重新编码；此外，由于各种平台的指令特点不尽相同，以往的测试经验也不能直接使用。开发和测试的工作量也将比较大。
信道译码需要处理的信道类型有：DCH(专用传输信道)、BCH(广播信道)、FACH(前向接入信道)、PCH(寻呼信道)、PICH(寻呼指示信道)和FPACH(快速物理接入信道)，其中DCH的译码过程最为复杂，其他信道的译码过程则依据高层配置，可能有所简化。如图2所示，以DCH的译码过程为例进行简单说明。该译码过程包括两部分：解复用前的译码过程和解复用后的译码过程。首先需要针对整个CCTrCH(码组合传输信道)进行译码，然后再针对每个分解的TrCH(传输信道)进行译码。
在目前的3G终端中，信道译码过程在DSP上实现过程主要是通过软件方式实现的。如图3所示，现有的信道译码方法首先确定欲解码的信道类型，然后针对每种信道类型的解码过程，利用软件分别进行编程，当确定了信道类型后，直接调用该信道类型对应的解码程序进行解码。例如，如果确定欲解码的信道类型为专用传输信道，将调用相应的解码程序执行图2所示的解码流程。对于不同的信道类型，解码过程不同。这样，在实际解码过程中，由于软件实现时必须针对不同的信道类型分别进行解码，必然导致各解码程序的不同，导致了工作人员工作量的增加，并且，软件解码的方式对于将来的维护也很不利：必须针对不同信道类型进行；若不同的解码程序是由不同的代码编写(平台不同)，将来则会限制该编码程序的移植性。由于大部分均采用软件进行解码，必然会造成系统资源的大量消耗，这对处理能力有限的终端来讲，无异降低了其总体性能。
具体而言，现有的通信系统终端采用DSP(数字信号处理器)实现信道译码时存在以下缺点：
(1)为满足不同信道的译码方式，现有信道译码大部分由软件实现，这必将消耗大量的DSP运算资源；现有的移动终端大都通过纯粹的软件方式实现信道译码，这消耗了整个系统60％以上的DSP运算资源。另外一些终端只是将Viterbi和Turbo译码算法采用硬件实现，而信道译码的绝大多数过程还是软件实现，这样只能节省很小一部分(大约10％)运算量，整个译码过程仍然需要很多的DSP运算资源。这无疑造成了终端性能的降低。
(2)实现策略：分别针对不同的信道类型调用各自的信道译码函数，这样就需要为每种信道编写和测试译码函数，工作量大。
(3)调度策略：需根据每次得到的传输时间间隔(TTI)参数确定调度时机；由于一种业务可能存在多个传输信道的复用，而且每个传输信道的TTI不尽相同。这就造成信道译码过程的两个阶段：解复用前的译码过程和解复用后。所以要根据当前时刻和信道TTI参数，确定对哪些传输信道进行译码处理。由于每一种业务的译码调度过程中存在大量的判断和计算过程，各种业务之间、同一种业务的多个传输信道之间都存在复杂的调度过程，因此实现起来代码实现难度、出错概率和测试工作量都很大。
(4)内存分配原则：按照最大可能的传输信道组合形式分配需要的最大内存空间；每种传输信道的译码调度周期可能存在不同，在一个TrCH译码过程执行之前，关于该信道的数据必须被完整保留，所以必须开辟一个可以包含所有传输信道完整译码数据的Buffer(缓存)，对于系统资源相对有限的终端而言，造成了巨大的资源消耗。
(5)代码使用效率：软件实现策略很可能导致不同平台的代码开发，可移植性和复用性差。每种DSP使用的语言平台可能不同，当在一个新的DSP上开发时，过去开发的代码往往不能移植，必须重新编码；此外，由于各种平台的指令特点不尽相同，以往的测试经验也不能直接使用。开发和测试的工作量也将比较大。
发明内容
针对上述现有3G移动通信系统终端中译码实现方式所存在的问题和不足，本发明的目的是提供一种可大大提高终端数据处理能力、易维护、拓展性强的适用于第三代移动通信系统终端的信道译码器及其相应的译码方法。
本发明是这样实现的：一种适用于移动通信系统终端的信道译码器，其包括：
用于判断无线信号数据信道类型的信道类型判断模块；
用于各传输信道译码的一个以上的信道译码逻辑模块；
用于控制各信道译码逻辑模块启动与否的控制模块。
进一步地，所述信道译码逻辑模块是根据移动终端需译码的所有传输信道而设置的，即对于任一传输信道，可选择相应的信道译码逻辑模块组合而实现译码。
进一步地，所述控制模块为命令寄存器，所述命令寄存器通过相应的数字位控制信道译码逻辑模块的工作状态，命令寄存器数字位输出为高电平时，对应的信道译码逻辑模块启动，否则该信道译码逻辑模块关闭，数据旁路。
进一步地，所述信道译码逻辑模块具体为：用于码组合传输信道信号数据分离的数据分离模块、用于信道解映射的物理信道解映射模块、用于将子帧依次结合起来的子帧级联模块、用于解除第二次交织的第二解交织模块、用于比特解扰的解扰模块、用于恢复和整合数据的解速率匹配模块、用于解除第一次交织的第一解交织模块、用于帧长恢复的帧长恢复模块、用于信道解码的信道解码模块、用于将码块结合的码块级联模块和用于差错检验的循环冗余校验模块。
进一步地，所述数据分离模块、物理信道解映射模块、子帧级联模块、第二解交织模块和解扰模块依次连接组成码组合传输信道译码加速器，所述解速率匹配模块构成解速率匹配加速器，所述第一解交织模块、帧长恢复模块、信道解码模块、码块级联模块和循环冗余校验模块依次连接组成传输信道译码加速器。
进一步地，所述码组合传输信道译码加速器的各信道译码逻辑模块由同一个命令寄存器控制，解速率匹配加速器由一个命令寄存器控制，传输信道译码加速器的各信道译码逻辑模块由同一个命令寄存器控制。
进一步地，控制码组合传输信道译码加速器和传输信道译码加速器的命令寄存器至少为5位的寄存器。
进一步地，所述信道译码逻辑模块是由相应的逻辑电路或芯片实现的。
一种基于前述信道译码器的终端信道译码方法，包括以下步骤：
(1)判断传输信号数据的信道类型；
(2)根据确定后的信道类型选择并启动欲使用的信道译码逻辑模块；
(3)按所选择的信道译码逻辑模块进行信道译码。
进一步地，所述步骤(3)中按所选择的信道译码逻辑模块进行信道译码具体为对各传输信道进行串行译码。
进一步地，所述信道译码逻辑模块是由命令寄存器启动的，所述命令寄存器通过相应的数字位控制信道译码逻辑模块的工作状态，命令寄存器数字位输出为高电平时，对应的信道译码逻辑模块启动，否则该信道译码逻辑模块关闭，数据旁路。
本发明通过将3G移动通信系统终端中的信道译码器拆分为不同的信道译码实现逻辑模块，并利用命令寄存器来实现对信道译码逻辑模块的开启或关闭，针对3G移动通信系统终端要译码的各种信道，可通过命令寄存器来选择需要使用的信道译码逻辑模块组，相应的数据依次经所选择的信道译码逻辑模块组而完成译码。本发明的信道译码逻辑模块全部由硬件实现。
具体而言，本发明具有以下优点：
(1)硬件的信道译码逻辑模块实现脱离平台的束缚，拓宽产品适应面；并可节省90％以上的DSP运算资源；
(2)信道译码逻辑模块可由命令寄存器单独控制，提高了可测试性及可维护性；同时降低芯片的硬件设计和实现风险；
(3)串行实现信道译码的方式，只需要分配一个TrCH所需要的最大内存容量即可，节省了DSP上珍贵的内存资源。
本发明是这样实现的：一种适用于移动通信系统终端的信道译码器，其包括：
用于判断无线信号数据信道类型的信道类型判断模块；
用于各传输信道译码的一个以上的信道译码逻辑模块；
用于控制各信道译码逻辑模块启动与否的控制模块。
进一步地，所述信道译码逻辑模块是根据移动终端需译码的所有传输信道而设置的，即对于任一传输信道，可选择相应的信道译码逻辑模块组合而实现译码。
进一步地，所述控制模块为命令寄存器，所述命令寄存器通过相应的数字位控制信道译码逻辑模块的工作状态，命令寄存器数字位输出为高电平时，对应的信道译码逻辑模块启动，否则该信道译码逻辑模块关闭，数据旁路。
进一步地，所述信道译码逻辑模块具体为：用于码组合传输信道信号数据分离的数据分离模块、用于信道解映射的物理信道解映射模块、用于将子帧依次结合起来的子帧级联模块、用于解除第二次交织的第二解交织模块、用于比特解扰的解扰模块、用于恢复和整合数据的解速率匹配模块、用于解除第一次交织的第一解交织模块、用于帧长恢复的帧长恢复模块、用于信道解码的信道解码模块、用于将码块结合的码块级联模块和用于差错检验的循环冗余校验模块。
进一步地，所述数据分离模块、物理信道解映射模块、子帧级联模块、第二解交织模块和解扰模块依次连接组成码组合传输信道译码加速器，所述解速率匹配模块构成解速率匹配加速器，所述第一解交织模块、帧长恢复模块、信道解码模块、码块级联模块和循环冗余校验模块依次连接组成传输信道译码加速器。
进一步地，所述码组合传输信道译码加速器的各信道译码逻辑模块由同一个命令寄存器控制，解速率匹配加速器由一个命令寄存器控制，传输信道译码加速器的各信道译码逻辑模块由同一个命令寄存器控制。
进一步地，控制码组合传输信道译码加速器和传输信道译码加速器的命令寄存器至少为5位的寄存器。
进一步地，所述信道译码逻辑模块是由相应的逻辑电路或芯片实现的。
一种基于前述信道译码器的终端信道译码方法，包括以下步骤：
(1)判断传输信号数据的信道类型；
(2)根据确定后的信道类型选择并启动欲使用的信道译码逻辑模块；
(3)按所选择的信道译码逻辑模块进行信道译码。
进一步地，所述步骤(3)中按所选择的信道译码逻辑模块进行信道译码具体为对各传输信道进行串行译码。
进一步地，所述信道译码逻辑模块是由命令寄存器启动的，所述命令寄存器通过相应的数字位控制信道译码逻辑模块的工作状态，命令寄存器数字位输出为高电平时，对应的信道译码逻辑模块启动，否则该信道译码逻辑模块关闭，数据旁路。
本发明通过将3G移动通信系统终端中的信道译码器拆分为不同的信道译码实现逻辑模块，并利用命令寄存器来实现对信道译码逻辑模块的开启或关闭，针对3G移动通信系统终端要译码的各种信道，可通过命令寄存器来选择需要使用的信道译码逻辑模块组，相应的数据依次经所选择的信道译码逻辑模块组而完成译码。本发明的信道译码逻辑模块全部由硬件实现。
具体而言，本发明具有以下优点：
(1)硬件的信道译码逻辑模块实现脱离平台的束缚，拓宽产品适应面；并可节省90％以上的DSP运算资源；
(2)信道译码逻辑模块可由命令寄存器单独控制，提高了可测试性及可维护性；同时降低芯片的硬件设计和实现风险；
(3)串行实现信道译码的方式，只需要分配一个TrCH所需要的最大内存容量即可，节省了DSP上珍贵的内存资源。
附图说明
图1是现有下行链路数据流程图；
图2是现有3G移动终端中DCH的译码流程图；
图3是现有3G移动终端中传输信道的译码示意图；
图4是本发明信道译码器的结构示意图；
图5是本发明CCTrCH加速器的逻辑结构示意图；
图6是本发明解速率匹配加速器的逻辑结构示意图；
图7是本发明TrCH加速器的逻辑结构示意图；
图8是本发明的传输信道的译码示意图。
图2是现有3G移动终端中DCH的译码流程图；
图3是现有3G移动终端中传输信道的译码示意图；
图4是本发明信道译码器的结构示意图；
图5是本发明CCTrCH加速器的逻辑结构示意图；
图6是本发明解速率匹配加速器的逻辑结构示意图；
图7是本发明TrCH加速器的逻辑结构示意图；
图8是本发明的传输信道的译码示意图。
具体实施方式
下面结合附图对本发明作进一步的详细描述。
本发明根据信道译码的特点，将执行过程复杂、规则固定的译码操作步骤，根据其被执行的周期特点分成3个硬件加速器完成。如图4所示，这3个硬件加速器分别为可完成CCTrCH分离的CCTrCH加速器、用于恢复和整合数据的解速率匹配加速器和完成单个传输信道译码的TrCH加速器。该3个硬件加速器分别连接于命令寄存器C、R、T。命令寄存器C、R、T由控制软件控制。该3个硬件加速器共用终端内存，该内存用于存储无线信号数据、译码后数据及执行指令等。CCTrCH加速器、解速率匹配加速器和TrCH加速器由逻辑电路或相应芯片等硬件实现。控制比特提取、TFCI(传送格式组合指示)译码、调度等和平台相关的操作交由控制软件处理。该信道译码器还包括用于接收下行无线信号数据的输入模块和用于数据译码后输出的输出模块，但未在图中示出。
本发明的重点在于CCTrCH加速器、解速率匹配加速器和TrCH加速器的设计，CCTrCH加速器、解速率匹配加速器和TrCH加速器按信道译码的特点，分别设计为不同的实现模块，这些信道译码实现逻辑模块是根据移动终端需译码的所有传输信道而设置的，对于任一传输信道，均可选择相应的信道译码逻辑模块组合而实现译码。本发明针对所有待解码的信道，确定需要解码这些信道所需要的各流程，并对这些执行流程进行整合，以使其尽可能多地共用相同的解码模块；以下分别进行说明。
如图5所示，CCTrCH加速器包括5个主要的信道译码逻辑模块，分别为：用于码组合传输信道信号数据分离的数据分离模块、用于信道解映射的物理信道解映射模块、用于将子帧依次结合起来的子帧级联模块、用于解除第二次交织的第二解交织模块和用于比特解扰的解扰模块；该5个信道译码逻辑模块均由硬件实现，其依次串接，并由命令寄存器C所控制。其中，命令寄存器C的设计为：
Bit#15～#5 Bit#4 Bit#3 Bit#2 Bit#1 Bit#0 Reserved C4 C3 C2 C1 C0
而命令寄存器C的每个控制比特Ci(i＝0，1，2，3，4)独立控制其中的一个信道译码逻辑模块，当控制比特Ci置为“1”时，则控制比特Ci对应的信道译码逻辑模块启动，否则，该信道译码逻辑模块功能关闭，数据旁路。
如图6所示，解速率匹配加速器由用于恢复和整合数据的解速率匹配模块单独构成。该解速率匹配模块由命令寄存器R所控制。其中，命令寄存器R的设计为：
Bit#15～#1 Bit#0 Reserved R1
控制比特R1置为“1”，则解速率匹配模块启动，否则，该解速率匹配模块功能关闭，数据旁路。
如图7所示，TrCH加速器包括5个主要的信道译码逻辑模块，分别为：用于解除第一次交织的第一解交织模块、用于帧长恢复的帧长恢复模块、用于信道解码的信道解码模块、用于将码块结合的码块级联模块和用于差错检验的循环冗余校验模块；该5个信道译码逻辑模块均由硬件实现，其依次串接，并由命令寄存器T所控制。其中，命令寄存器T的设计为：
Bit#15～#5 Bit#4 Bit#3 Bit#2 Bit#1 Bit#0 Reserved T4 T3 T2 T1 T0
每个控制比特Ti(i＝0，1，2，3，4)独立控制其中的一个信道译码逻辑模块，当控制比特Ti置为“1”，则该信道译码逻辑模块启动，否则，该信道译码逻辑模块功能关闭，数据旁路。
这样，命令寄存器可以使用每个硬件加速器中的任意一个子模块，所以对每一个子模块功能的单独测试变得相当简单。例如，测试Turbo译码器的性能时，只需将命令寄存器T设置为Ox0004，而控制软件将TrCH加速器的输入地址输入测试向量，并启动TrCH加速器后得到输出数据，再和输出测试向量比较即可完成Turbo译码器的性能测试。这里，控制用的命令寄存器采用5位的即可实现。本发明采用的芯片中的命令寄存器位为16位的。
本发明采用这种多模块分别控制的方式可满足不同类型信道的译码要求。具体实现见表1：
表1
信道类型 命令寄存器C 命令寄存器R 命令寄存器T 备注 DPCH Ox001f Ox0001 Ox001f P-CCPCH Ox001e Ox0001 Ox0015 无TFCI， 无须做数 据分离 S-CCPCH Ox001f，0x001e Ox0001 Ox001f 可能出现 没有TFCI 的配置 PICH Ox006，0x0002 Ox0000 Ox0000 可能对 5ms数据 做PICH 译码 FPACH Ox0000 Ox0001 Ox0014 数据重排 交给软件 处理
仍以DPCH信道为例进行说明，对于DPCH信道，命令寄存器C设置为Ox001f，即启动了CCTrCH加速器的全部5个信道译码逻辑模块。
命令寄存器R设置为Ox0001即意味着解速率匹配加速器处于启动状态；同样地，命令寄存器T设置为Ox001f，即同样启动了TrCH加速器的全部5个信道译码逻辑模块。为了更好地理解本发明，再以FPACH为例说明一下子模块的选择：对于FPACH信道，命令寄存器C设置为Ox0000，即关闭了CCTrCH加速器；命令寄存器R设置为Ox0001即意味着解速率匹配加速器处于启动状态；命令寄存器T设置为Ox0014即意味着启动了循环冗余校验模块和信道解码模块。
如图8所示，本发明的译码方法非常简单：控制软件首先判断信道类型，查找表1给出的数值设置3个控制寄存器，然后分别启动所选择硬件。由于硬件译码器的输入端已经和译码输入数据相连，则一旦接收到启动命令，则会根据控制寄存器的设定自动完成译码，并输出最终的译码结果。
本发明针对每一个TrCH译码配置参数，串行启动TrCH加速器完成一个TrCH的译码。这样，按照一个TrCH的最大存储空间需求分配内存即可。和软件译码针对一个CCTrCH的多个TrCH一次调度的做法相比，大大节省了译码所需的缓冲区域。
本发明的实现过程非常简单，不需要编写、调试和维护大量的软件代码；查表设置控制寄存器的复杂度几乎可以忽略不计；并且由于多个传输信道的译码结果串行输出，最大程度节省了系统内存空间的占用。
当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，本领域技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。
本发明根据信道译码的特点，将执行过程复杂、规则固定的译码操作步骤，根据其被执行的周期特点分成3个硬件加速器完成。如图4所示，这3个硬件加速器分别为可完成CCTrCH分离的CCTrCH加速器、用于恢复和整合数据的解速率匹配加速器和完成单个传输信道译码的TrCH加速器。该3个硬件加速器分别连接于命令寄存器C、R、T。命令寄存器C、R、T由控制软件控制。该3个硬件加速器共用终端内存，该内存用于存储无线信号数据、译码后数据及执行指令等。CCTrCH加速器、解速率匹配加速器和TrCH加速器由逻辑电路或相应芯片等硬件实现。控制比特提取、TFCI(传送格式组合指示)译码、调度等和平台相关的操作交由控制软件处理。该信道译码器还包括用于接收下行无线信号数据的输入模块和用于数据译码后输出的输出模块，但未在图中示出。
本发明的重点在于CCTrCH加速器、解速率匹配加速器和TrCH加速器的设计，CCTrCH加速器、解速率匹配加速器和TrCH加速器按信道译码的特点，分别设计为不同的实现模块，这些信道译码实现逻辑模块是根据移动终端需译码的所有传输信道而设置的，对于任一传输信道，均可选择相应的信道译码逻辑模块组合而实现译码。本发明针对所有待解码的信道，确定需要解码这些信道所需要的各流程，并对这些执行流程进行整合，以使其尽可能多地共用相同的解码模块；以下分别进行说明。
如图5所示，CCTrCH加速器包括5个主要的信道译码逻辑模块，分别为：用于码组合传输信道信号数据分离的数据分离模块、用于信道解映射的物理信道解映射模块、用于将子帧依次结合起来的子帧级联模块、用于解除第二次交织的第二解交织模块和用于比特解扰的解扰模块；该5个信道译码逻辑模块均由硬件实现，其依次串接，并由命令寄存器C所控制。其中，命令寄存器C的设计为：
Bit#15～#5 Bit#4 Bit#3 Bit#2 Bit#1 Bit#0 Reserved C4 C3 C2 C1 C0
而命令寄存器C的每个控制比特Ci(i＝0，1，2，3，4)独立控制其中的一个信道译码逻辑模块，当控制比特Ci置为“1”时，则控制比特Ci对应的信道译码逻辑模块启动，否则，该信道译码逻辑模块功能关闭，数据旁路。
如图6所示，解速率匹配加速器由用于恢复和整合数据的解速率匹配模块单独构成。该解速率匹配模块由命令寄存器R所控制。其中，命令寄存器R的设计为：
Bit#15～#1 Bit#0 Reserved R1
控制比特R1置为“1”，则解速率匹配模块启动，否则，该解速率匹配模块功能关闭，数据旁路。
如图7所示，TrCH加速器包括5个主要的信道译码逻辑模块，分别为：用于解除第一次交织的第一解交织模块、用于帧长恢复的帧长恢复模块、用于信道解码的信道解码模块、用于将码块结合的码块级联模块和用于差错检验的循环冗余校验模块；该5个信道译码逻辑模块均由硬件实现，其依次串接，并由命令寄存器T所控制。其中，命令寄存器T的设计为：
Bit#15～#5 Bit#4 Bit#3 Bit#2 Bit#1 Bit#0 Reserved T4 T3 T2 T1 T0
每个控制比特Ti(i＝0，1，2，3，4)独立控制其中的一个信道译码逻辑模块，当控制比特Ti置为“1”，则该信道译码逻辑模块启动，否则，该信道译码逻辑模块功能关闭，数据旁路。
这样，命令寄存器可以使用每个硬件加速器中的任意一个子模块，所以对每一个子模块功能的单独测试变得相当简单。例如，测试Turbo译码器的性能时，只需将命令寄存器T设置为Ox0004，而控制软件将TrCH加速器的输入地址输入测试向量，并启动TrCH加速器后得到输出数据，再和输出测试向量比较即可完成Turbo译码器的性能测试。这里，控制用的命令寄存器采用5位的即可实现。本发明采用的芯片中的命令寄存器位为16位的。
本发明采用这种多模块分别控制的方式可满足不同类型信道的译码要求。具体实现见表1：
表1
信道类型 命令寄存器C 命令寄存器R 命令寄存器T 备注 DPCH Ox001f Ox0001 Ox001f P-CCPCH Ox001e Ox0001 Ox0015 无TFCI， 无须做数 据分离 S-CCPCH Ox001f，0x001e Ox0001 Ox001f 可能出现 没有TFCI 的配置 PICH Ox006，0x0002 Ox0000 Ox0000 可能对 5ms数据 做PICH 译码 FPACH Ox0000 Ox0001 Ox0014 数据重排 交给软件 处理
仍以DPCH信道为例进行说明，对于DPCH信道，命令寄存器C设置为Ox001f，即启动了CCTrCH加速器的全部5个信道译码逻辑模块。
命令寄存器R设置为Ox0001即意味着解速率匹配加速器处于启动状态；同样地，命令寄存器T设置为Ox001f，即同样启动了TrCH加速器的全部5个信道译码逻辑模块。为了更好地理解本发明，再以FPACH为例说明一下子模块的选择：对于FPACH信道，命令寄存器C设置为Ox0000，即关闭了CCTrCH加速器；命令寄存器R设置为Ox0001即意味着解速率匹配加速器处于启动状态；命令寄存器T设置为Ox0014即意味着启动了循环冗余校验模块和信道解码模块。
如图8所示，本发明的译码方法非常简单：控制软件首先判断信道类型，查找表1给出的数值设置3个控制寄存器，然后分别启动所选择硬件。由于硬件译码器的输入端已经和译码输入数据相连，则一旦接收到启动命令，则会根据控制寄存器的设定自动完成译码，并输出最终的译码结果。
本发明针对每一个TrCH译码配置参数，串行启动TrCH加速器完成一个TrCH的译码。这样，按照一个TrCH的最大存储空间需求分配内存即可。和软件译码针对一个CCTrCH的多个TrCH一次调度的做法相比，大大节省了译码所需的缓冲区域。
本发明的实现过程非常简单，不需要编写、调试和维护大量的软件代码；查表设置控制寄存器的复杂度几乎可以忽略不计；并且由于多个传输信道的译码结果串行输出，最大程度节省了系统内存空间的占用。
当然，本发明还可有其他多种实施例，在不背离本发明精神及其实质的情况下，本领域技术人员当可根据本发明作出各种相应的改变和变形，但这些相应的改变和变形都应属于本发明所附的权利要求的保护范围。