我發現沒有指導是否有用。
Turbo卷積碼(TCC)是3G無線系統中采用的前向糾錯(FEC)機制的組成部分。但是Turbo譯碼器帶來的計算負擔很重，不適合傳統的DSP或RISC處理器。由於現場可編程邏輯陣列(FPGA)固有的並行結構，FPGA提供了高性能的信號處理平臺，用於解決3G基站收發器中所需的符號速率FEC和其他計算密集型任務。
Turbo編碼
級聯編碼方案被設計成通過組合兩個或更多相對簡單的分量或構造模塊碼來獲得更高的編碼增益。Turbo碼被認為是級聯碼結構的壹種改進，它采用叠代算法對相關的碼序列進行解碼。Turbo碼是通過將兩個或多個分量碼應用於同壹數據序列的不同交織版本而形成的。對於任何傳統的單分量編碼，解碼器的最後壹級產生硬判決解碼數據位。為了使類似Turbo碼的級聯碼方案更好地工作，解碼算法不應局限於在解碼器之間傳輸硬判決。為了充分利用每個解碼器獲得的信息，解碼算法必須能夠實現軟判決交換，而不是硬判決。對於具有兩個分量碼的系統，譯碼的概念是指將軟判決從壹個譯碼器輸入到另壹個譯碼器的輸入，並重復這個過程幾次以獲得更好的判決，如圖1所示。
3GPP Turbo編碼器
圖2是3GPP編碼器。
輸入數據流輸入到RSC1，RSC 1為每個輸入位生成壹個奇偶校驗位。RSC2還對輸入數據進行交織和處理，以產生第二個對等比特流。
3GPP標準定義輸入塊的長度在40和5114比特之間。編碼器以1/3的速率生成系統碼，包括原始輸入比特和兩個對等比特。打孔可以得到1/2的編碼速度。遞歸系統編碼器的實現相對簡單，但是交織器沒有標準卷積或塊交織器簡單和復雜。
壹旦輸入數據塊長度k被提供給編碼器，編碼器將計算交織矩陣的行數R和列數C，並創建相應的交織數據結構。r和c是塊長k的函數，輸入符號加載到交織矩陣後，然後會按照壹定的順序進行行間交換和列間交換。根據塊長度k(即取決於k)選擇切換模式。行列交換完成後，逐列讀取交織矩陣數據即可得到最終的交織序列。在讀取數據時，需要進行剪枝，以確保輸出中只有正確的輸入符號。請註意，交錯陣列通常包含比K個原始輸入符號更多的數據比特，因為R C >: K .然後，新序列由RSC2編碼以生成第二對等比特流。
實現交織器的壹種方式是將完整的切換序列存儲在存儲器中。也就是說，壹旦給定了k，就調用初始化例程(在處理器或FPGA中的功能單元上運行的軟件例程)來生成相應的交換序列，然後將該信息存儲在存儲器中。然而，這種方法需要大量的內存。Virtex -E FPGA技術提供的4096位片內存儲器將需要[511413/4096]= 17個存儲塊。
在我們的方法中，預處理引擎用於生成序列值(存儲)，該序列值被存儲並將被交織器地址生成器使用。這個硬件單元使用幾個小的數據結構(素數表)來計算所需的序列。這個準備過程所需的時鐘周期數與信息塊的長度成正比。例如，對於K=40的塊，需要280個時鐘周期，對於最大塊長度K=5114，需要5290個時鐘周期。這個過程只需要在塊長度改變時執行。地址生成器使用這些更緊湊的數據結構來實時生成交錯地址。
3GPP Turbo解碼器
解碼器包括兩個MAP解碼器和幾個交織器。Turbo算法的優異性能來自於可靠性信息(外部數據或先驗數據)可以在兩個MAP解碼器之間共享的事實。
在我們的設計中，MAP解碼器采用了Bahl、Cocke、Jelinek和Rajiv (BCJR)算法。BCJR算法計算每個符號的最大後驗對數似然，是壹種真正的軟判決算法。考慮到數據以塊的形式傳輸，可以在時間維度上向前或向後搜索符號序列。對於任何序列，它的出現概率都是單個符號出現概率的乘積。因為問題是線性的，序列匯總可以用概率的對數和來代替。
為了與壹般文獻中的約定壹致，我們分別用和來表示解碼叠代的正向和反向狀態概率。通常，BCJR算法要求直到接收到全部信息才開始解碼。對於實時應用，這個限制可能太嚴格了。例如，3GPP Turbo解碼器將需要大量存儲器來存儲5114個符號信息塊的完整狀態網格。對於單片FPGA設計，這需要太多的存儲資源。類似於Vitebi算法，我們可以從全零向量o和數據{yk}(k從n到n-L)開始反向叠代。L次逆叠代可以獲得非常好的n-L近似。只要l選擇得當，最終的狀態度量就是正確的。該屬性可用於在信息結束前開始有效的位解碼。
l稱為收斂長度。其典型值約為解碼器約束長度的幾倍(通常為5到10倍)，隨信噪比的降低而增大。
通常，Turbo解碼算法將計算所有(對於整個信息塊)，存儲這些值，然後將它們與反向狀態概率壹起用於在反向叠代中計算新的外部信息(或先驗信息)。我們在設計中采用了開窗法。
解碼過程從正向叠代開始，計算包含L個接收符號的塊I的值。同時反向叠代未來(i+1)塊(標註)。在塊i+1的逆叠代結束時，獲得開始塊I的逆叠代所需的正確初始向量。同時，對數似然函數(Lall)也在進行中。每個求和過程需要八次max*運算tellis中八個節點各壹次。最終的對數似然計算需要14個並行max*運算符。為了提供可接受的解碼速率，設計中使用了38個max*功能單元。
從c語言描述到FPGA設計
FPGA Turbo編譯碼器的設計基於C設計和驗證方法，如圖3所示。
在算法開發階段，采用定點C類型的Art庫對定點計算的位真效果進行精確建模。在這壹階段，研究了幾種可能算法的定點性能。壹旦選擇了正確的量化算法，就可以使用|rtDesignerPro創建特殊的DSP架構。|rtDesignerPro最強大的功能之壹就是可以插入和利用專用的數據通道內核(稱為ASU)。使用這些ASU加速器核心，我們可以處理Turbo解碼器算法固有的計算復雜性。
壹個|rtDesignerPro可以自動完成寄存器分配、調度和控制器生成。在Turbo編解碼器的設計中，A|rtDesignerr的自動循環合並可以得到最好的效果；任務調度和MAP解碼步驟的內部循環只有壹個周期長。
由|rtDesignerPro生成的最終結果是全面的RT級)VHDL或Verilog描述。基於c的工具流支持FPGA的特殊功能。比如可以用BlockRAM自動構造RAM，也可以用分布式內存代替觸發器實現寄存器文件。
最後，邏輯綜合和Xilinx實現工具套件將RTL HDL轉換成FPGA配置比特流。
FPGA Turbo編譯碼器的實現
由A|rtDesigner創建的Turbo編碼器和解碼器的核心硬件結構包含許多特殊的ASU加速器。最重要的加速器之壹，完成max*運算。max*運算符根據以下公式計算兩個冪值a和b:
max* (a，b)=ln(expc(a)+expc(b))。
如圖4所示，通過選擇(a，b)的最大值並應用存儲在查找表(LUT)中的校正因子來近似執行max*運算。這種近似算法非常適合用Xilinx FPGA實現，其中LUT是其最終的基本構建模塊。
結果
Turbo譯碼算法硬件字長的選擇極大地影響了整體性能。利用C-to-FPGA設計流程，這種定點分析完全在C環境下完成。結果如圖5所示。
上圖顯示了我們的浮點Turbo解碼器算法和相應的定點算法之間的性能差異。仿真是在5114塊長、5次譯碼叠代和AWGN信道模型的條件下進行的。結果清晰明顯，性能損失很小。
我們的Turbo解碼器的定點性能是解碼器叠代次數的函數，對於1.5 dB SNR，錯位率為10-6。
解碼器功能的實現非常具有挑戰性，我們已經適應了Virtex-E和Virtex-II設備。Virtex-II設備的實現是利用運行在1.85 speedfile數據庫上的Xilinx 4.1i實現工具集完成的。基於XC2V1000BG575-5 FPGA的最終設計實現了66 MHz的時鐘性能，消耗了3060個邏輯芯片和16塊RAM。對於符號長度從40到5114的塊，解碼器在5個解碼叠代周期內實現每秒200萬到650萬符號(Msym/s)的吞吐量。該編碼器占用903個邏輯芯片，3塊RAM，支持83 MHz時鐘頻率。對於40到5114比特的塊長度，速率可以達到9到20 msym/s。
我希望我能使用它。如果我沒有，不要責備我。對不起~祝福妳~