利用Xilinx HLS實現LDPC譯碼器

1. 概述

    採用Xilinx HLS快速實現的部分並行，全流水的LDPC譯碼器。

• 環境：Vivado HLS 2018.2
• 碼字：IEEE 802.16e 2/3A
• 算法：Min-Sum Algorithm
• 代碼：https://github.com/cea-wind/hls_ldpc_dec/
• 器件：xc7k160

  使用方法：

     1. 從GitHub上clone代碼

     2. 在終端運行命令

vivado_hls -f run_hls.tcl

     3. 打開vivado hls GUI，找到生成的工程，打開便可

2. 碼字和算法

    爲簡單起見，採用了IEEE 802.16e標準中的2/3A碼率的碼字，並選擇1536的碼長做爲具體的驗證舉例。該LDPC碼是準循環碼，每一個循環子矩陣的行重爲1。其校驗矩陣能夠用母矩陣表示爲

    譯碼算法原理可參考http://www.javashuo.com/article/p-vejmbxvk-dg.html，或者直接參考其實現http://www.javashuo.com/article/p-qvsvxlzc-dw.html。（寫得均很差，不建議參考）

    譯碼算法採用修正因子爲0.8125的最小和算法，爲了簡便起見，沒有設置知足校驗方程跳出的判斷。具體可參考Git repo中的MATLAB代碼，但該MATLAB代碼並無作量化。

3. 設計思路

    爲了體現FPGA的優點，此處採用了部分並行全流水的設計。其中部分並行指設計同時開始多個行更新和列更新，全流水指行更新和列更新採用的流水線設計能夠作到一個時鐘週期完成一行或一列數據的更新。

    校驗矩陣中有80個不爲0的循環矩陣，將其分別存儲在不一樣的BRAM上，一個週期內可訪問80個循環矩陣中的任意一個數據。所以在進行行更新時，能夠同時更新8行，列更新時，能夠同時更新24列。按此進行並行設計。

    行更新採用了全流水設計，其核心在於求最小值和次小值，能夠參考http://www.javashuo.com/article/p-eegjeepr-ek.html的內容。實現結構相似

    列更新採用了全流水設計，利用加法便可，較爲簡單。

    因爲以前寫過一份FPGA代碼，所以行更新和列更新的HLS代碼Verilog風格較重。

4. 分析

4.1 Simulation

　　經過Run C/RTL cosimulaiton，能夠校驗生成的RTL代碼仿真是否正確。校驗得知RTL simulation結果和C結果一致，在main函數指定的case下仿真經過。仿真過程當中能夠dump信號波形，完成仿真後可打開波形進行進一步查看。

4.2 Perference

    HLS結果以下圖所示，預計頻率在250MHz以上。完一次譯碼（50次迭代）須要10020個週期。

    具體耗時細節以下圖，讀取解調後軟信息須要約1539個週期，輸出結果須要約1026個週期，譯碼迭代須要7450個週期。

    行更新須要的理論時間爲64個clk，列更新也是如此。所以完成一次行列更新須要128個clock（行列不作流水的理論下限），綜合結果表示latency爲149個週期，效率已經極高了。關於數據讀取和寫回，因爲設計中沒有作特別優化，此處不作考慮。

    上述結果代表，HLS綜合結果從效率和頻率上看都極其優異。

4.3 Resource

    （彷佛2018.2的綜合策略發生了變化，利用了大量register且資源評估時未做優化，所以該階段資源評估不許確，採用2016.3結果）

    信息的存儲佔用了大量的資源，共有80塊用於存儲中間信息，24塊存儲輸入的對數似然比，結果和分析一致。而行更新和列更新消耗了大量的邏輯資源。

    行更新和列更新具體資源細節以下圖所示

    以列更新爲例，列更新過程當中，列重爲3的更新有1個4-in的11bit加法，3個2-in的8bit減法，6次比較和3個3-to-1MUX。預計佔用資源爲3×11+3×8+6×3+3×8=97個LUT，加上地址控制等，其綜合結果資源耗費合理。

   所以HLS的綜合結果資源佔用也在合理範圍內。

5. 優化

• 優化輸入輸出設計
• 加入中止條件
• 優化bram的使用，包括輸入信息的存儲和輸出信息的存儲
• 已經有兩年沒有接觸LDPC了，Xilinx HLS也基本沒用過，若有建議還請留言指正