《基于硬件加速的NIOSIITurbo解码器实现外文翻译.doc》由会员分享，可在线阅读，更多相关《基于硬件加速的NIOSIITurbo解码器实现外文翻译.doc（14页珍藏版）》请在三一办公上搜索。
1、基于硬件加速的NIOS-IITurbo解码器实现 摘 要本文提出了一种基于硬件加速的NIOS-II Turbo解码器的实现。首先，需要构建一个包含有一个由两个并行级联的RSC编码器组成的编码器和一个基于两个相同的SOVA解码器的解码器组成的Matlab原型。Matlab原型的仿真结果表明，在解码器中误码率在每次迭代中都有下降（下降至10-4），除了低信噪比情况（低于-5dB）。然后，将描述并比较两种基于FPGA实现的解码器。第一种是由一个运行在NIOS II快速型软核处理器的软件实现，然而另外一种却是加入了一个硬件加速器。解码器的计算能力部分是确定的，并行执行从软件实现转移到硬件加速器。从硬件
2、解码过程加速实施的结果来看，BER大致和软件解码实现相同，但执行时间减少了2534，当解码迭代的次数增加1至20。与软件解码实现相比，硬件加速的方法对资源的需求增加了1016。关键词：Trubo解码；FPGA，软核处理器；NIOS-II；硬件加速；并行第一章 引 言Turbo编码的概念（TC）是在相同的符号序列使用两个或两个以上的码元，然后通过解码其中一个码元获得的相关性来提升第二个码元的解码，以这种迭代的方式，反之亦然。这意味着，两个完全不同的代码，其中原码元数据的所有信息都被保留，TC是能够迭代解码直到在已解码符号序列中没有错误存在。因此TC的纠错性能依赖于两个码元之间的差异。为确保两个代
3、码之间的高差异特性，一种常用的方法是交错地输入序列到其中的一个编码器，以便它以不同的顺序编码相同的位。因此一个典型的TC单元包括四个要素：编码器，解码器，交织器和去交织。TC有很多的用途，因为它接近Shannon极限1。例如，TC被应用在磁性/光学数据存储系统，ADSL调制解调器和卫星通信2。然而，由于解码过程中的迭代操作，纠错性能依赖于实现TC的平台的计算能力和精度。因此，在嵌入式平台实现TC编解码并且充分发挥其潜力是一个巨大的挑战，因为这样的平台往往计算能力和精确度是有限的。这项工作的目的是研究是否能通过硬件加速的方法来改善TC的嵌入式软件实现性能。这是通过在FPGA上合成软核处理器，为这
4、颗处理器定制TC软件实现方法，以及设计和实施一个硬件加速器来减少软件执行时间该软件的执行时间的解决方案。本文的其余部分安排如下：第二章介绍了编码/解码链的MATLAB原型。第三章详细介绍了软件和硬件加速器的实现方法。第四章陈述实验结果，第五章作一个本文的最后总结。第二章 MATLAB的原型图1 Turbo编码的MATLAB原型结构方案Turbo编码/解码器流程如图1所示。编码器采用两个由反馈多项式g1（D）= D2 + D +1和输出多项式g2（D）= D2 +1和g3（D）= D +1构成的递归系统卷积码（RSC）4编码器。为这个原型设计的交织器选择的是二次型，并且输入块长度选择2048位。
5、主要功能模块，如图1中间部分，生成一个随机比特序列用作为源数据。这个序列将被转发到编码器来实现所要求使用交织的编码位串。然而，首先所有位都需要从0/1状态转换到-1 /1状态以兼容解码器，然后需要添加加性白高斯噪声（AWGN）来模拟噪声通道的效果。添加噪声后，比特串被送到一个叫做软输出维特比解码算法（SOVA） 6解码器中，交织器和解交织器在所需的顺序上运行。A.信道仿真原型实现包括一个当用AWGN信道时能测试系统的性能仿真通道。因此，需要产生高斯白噪声，并且需要归一化编码序列面的能量。当信号噪声比（SNR）是在信道仿真以dBs表示信号噪声比率的时候，噪声需要乘以。然后将噪音和编码序列添加到A
6、WGN仿真信道中。B.测试方法测试包括编码长序列串数据，然后以不同的信噪比增加噪声。然后带噪声的数据传递到在输出数据之前多次执行迭代的解码器。解码完成后，将对解码后的数据与原始的数据进行比较，并且计算出误码率。选择从-8到2dB之间以1dB的步进信噪比来测试该原型，以突显在较低的信噪比情况下渐进的趋势和在较高的信噪比情况下仍呈现指数衰减的形状。测试从1到8次的迭代多个方面执行迭代，因为执行更多的迭代的好处可忽略不计。此外每个信噪比重复测试了1000次，计算所产生的一组数据的平均值以增加结果的可靠性。C. Matlab仿真结果吻合的测试结果如图2所示。从结果可以看出，更多的迭代次数减少了BER，
7、这和预期是吻合的。此外可见，如果信噪比低于-5 dB，这时解码器不能提高多少接收到的数据的质量。图2 Matlab仿真结果。每条曲线显示了一个描述中所述的特定迭代次数第三章 FPGA实现本章详细介绍了软件和硬件加速解码器的FPGA实现。选择的平台是在Altera DE2开发板，其中包括Cyclone II系列 EP2C35F672C6 FPGA芯片和软核处理器Nios II。A.软件实现软核处理器被设计成算术运算单元只有整数计算能力。这意味着一个必须使用一个定点表达式，或设计使用一个可执行可用的浮点算术单元。这样的实现可能为TC的实施提供了一个更好的数值稳定性，并且肯定减轻了它的设计。然而，一
8、个浮点实施增加了所需的数值计算，相比简单的操作，因此，该算法的执行时间显著地增加了。因此，选择使用一个定点实施，其中所有的数字都以32位整形表示，放置在216位点。这意味着所有的数字都乘以216 = 65536，并四舍五入至低于由此产生的数值最接近的整数。然而，Nios处理器，是不具有将两个32位数字以全精度和范围相乘或者相除的能力。一个后果是，人们必须在所有的乘法运算中对范围或者精度做出一个选择。其一每个数除以28（或其中之一除以216），然后再将数字相乘，或者先将数字相乘，然后结果除以216。第一种方法是在乘以数字之前扔掉扔掉每个数字的8位精度，而第二种方法可能导致多达32位溢出位由于（2
9、31-1）2 = 262-232+1，这已经不符合一个32位寄存器了。因此嵌入式软件系统也常被设计成使用最佳这两种方法，即一个操作数除以28，结果也除以28。整个系统如图3所示。图3 Turbo解码器（右）的软件实现连接到Turbo编码器的MATLAB实现。在Nios II软核处理器的嵌入式软件由5个功能组成：接收数据的main，放置在正确的数据结构，并调用解码功能。当完成解码功能后，main将解码后的数据传送到PC。它还衡量测试其他功能的执行时间，并把这个信息传送到PC。decode负责解码过程中的迭代一部分，它调用interleave，deinterleave和sova功能模块。Inter
10、leave和deinterleave负责La，SYS或LLR的序列的交织解交织。它被选定为实施二次交织和使用查找表，而不是实施置换比矩阵向量乘法。sova执行实际的解码。软核处理器的配置如下。软核类型：Nios II/f，硬件乘法器：Embedded multipliers，硬件除法器：Yes。外设如下。SRAM：512 KB（实际使用情况是只用了400多KB），RS-232 UART，JTAG UART和定时器。该系统是由Quartus II套件合成和编程的，C程序使用Altera的Nios II IDE软件进行编译并发送到Nios II/ F。在Quartus II中完成编译后，总结报告指
11、出，使用了33216个LE中的3250个，即大约占了可用LES的10。软核实现执行时间的测量在第四章中陈述。B.硬体加速实施下一步是检查软件的实施，通过分析手段找出算法的计算度最密集的部分。在Nios II IDE中，pprofiler被称为niosii-elf-gprof。这个分析器在一定的时间间隔的能够抽样程序计数器并迅速产生抽样结果，但它可能无法提供最精确的结果。分析器输出是由Altera DE2开发板上的工作在50 MHz下的NiosII/ F软核处理器上的Turbo解码器产生的。一个分析器的总结的平面图如表一。表1样本分析概览因为Sova和Jacob_log的功能使用的时间占解码所花
12、费的执行时间97，这就决定了要分析他们，以确定他们是否可以被加速。为了开始研究其过程，需要结合优先级图（PG）和数据流图（DFG）对Sova和Jacob_log功能分析。在图4中结合DFG和PG说明了计算的最佳前向和向后路径成本。图5说明了结合DFG和PG的sova计算输出结果被称为SOVA功能Jacob_log功能在如图6表示。内在的并行性可以在图4-6中的图案中的DFGs/ PGs联合看出。有些意见可以作出的并行说明：在par1cost，par2cost和logprob的计算完成之前，branch0和branch1的计算是不可能的。图6中的算法需要mu best的知识，在计算完branch
13、0和branch1后，要计算一个临时的成本来返回mu best。(a)branch0、branch1，(b)syscost、par1cost、par2cost，和(c) 第一项、第二项的计算顺序是不相关的。Sova功能中重新安排后的向前和向后的路径成本的计算如图7所示执行。图4 PG和DFG的后向和前向的路径成本评价图5 PG和DFG度量的从分支输出计算图8显示了第二个部分，利用图7的mu best和后向mu best计算的外在价值，La，和softoutput，LLR，重新计算分支度量。最后的重组功能，Jacob_log，在图9中描述。图6 称为sova的jacob_log功能的PG和DFG
14、是为了计算分支的成本，branch0和branch1图7 为提取固有的并行性重新编排后的代码顺序结构图8 改进了其中外在价值，La，和软输出，LLR的SOVA算法的第二部分的计算图9 为提取固有的并行性而重新编排的jacob log代码顺序结构选择如图10所示硬件加速器实现结构。它可以计算出所有三环路的分支成本，因此，它可以当作一个通用模块来使用。这是一次性解决使用区域和执行时间的方案，但它可以很容易被缩减为几个可实现的加速器并提供支成本计算。正如在第三章B中软核实施占用了了3,250个LE，在FPGA中，这相当于LES总数的10。当添加了硬件加速器，该区域消耗量增加至5909个LE，这是总面
15、积的16。图10 算法选定的硬件部分实施待添加的隐藏文字内容3第四章 实验结果一个实验测试被用来提供能够比较两个不同的Turbo编码实现（TC）所需的数据，测试执行时间，同时也验证Turbo编码保留原则。本次测试如下：（1）使用MATLAB生成一个长度为2048随机比特序列。（2）添加高斯白噪声，并确保2分贝的信噪比水平。（3）发送比特序列到实现模块，使他们解码迭代次数从1到20不等。（4）对这两种实现解码所用的时间进行测量。测量的时间是在完全相同的方式下消除偏见是测试的。随着迭代的数目，应该注意时间。测试应该包括有无硬件加速两个情形。第一次测试的结果，测试两个实现的执行时间，如图11所示。B
16、ER测试结果如图12所示。图11 有无硬件加速时的软核实现执行时间图12 在不同的信噪比水平下，在MATLAB和两个实现的原型获得的BER。数字旁边的曲线表示为特定的迭代次数曲线第一次测试的结果表明，结合软核和硬件实现的速度比纯软核实现要快。具体来说，例如10迭代，这两种实现相差2.614s，支持硬件加速实施。结果还表明，执行之间的依赖解码迭代的时间和数量有近似线性关系。详细的硬件加速执行速度比软核分别快了34.44和25.13之间，从1到20次迭代次数来看。这个加速成本是温和的，因为所需的FPGA资源仅从10提高到16（cf.III.B）。第二次测试的结果表明，该曲线有两个实现曲线形状类似原
17、型解码器。误码率随提高信噪比和解码迭代的数量增加而降低。这表明，Turbo码功能仍然保存下来了。在任何信噪比，实施版本的BERs大致相等。然而，相对于原型，两个实现信噪比2 dB的要求较高，以达到相同的原型的BER。第五章 结论一个硬件加速的NIOS-II涡轮解码器实施已经陈述完成。在第一阶段，MATLAB原型的模拟表明，解码器每次迭代误码率都下降（下降10-4），但在低信噪比情况下（低于-5dB）。在第二阶段，两个解码器的FPGA实现已被描述和比较。第一个在一个Nios II/ F软核处理器上执行的软件，而第二个则增加了硬件加速器。现已查明解码器计算能力部分的要求，并行执行重组并移动到硬件加速器。两种实现要求信噪比高2 dB来获得MATLAB原型实现相同的BER。解码硬件加速实施过程中结果在大约相同的BER为软件执行，但执行时间减少34和25之间时，解码迭代是增加从1到20分别。加速执行增加所需的资源的数量与软件相比，从10增加到16。参考文献1 Shannon, C. E. (1948). A mathematical theory of communication. Bell System Technical Journal, 27:5064.
