## 4 Hardware Implementation and Result Discussion
### Hardware Implementation  
The implementation results of our decoders and previous works are shown in Table 1 in detail. In this table, we use \(\{LLR^{init}_{v_{i}},\ LLR^{it}_{v_{i}},\ R^{it}_{j,l}\}\) to define the quantization as [12] did. For a fair comparison, numbers of pipeline stages for 5G NR and WiMAX decoders were set to 13 and 10 as [15] did. During the calculation, all LLRs and messages were subject to overflow processing. In the decoder, OMSA was used to calculate the check-to-variable messages and offset factor was set to 0.125. The normalized throughput \(T_{norm}\) represents the throughput for one decoding iteration. From Table 1, it is obvious to see that \(T_{norm}\) of decoder we designed is as high as previous works. The double update queues bring a little complexity in routing. As a result, the maximum frequency the decoders can operate at is a little lower than [15] but still high enough to provide a high throughput. Our decoders consume a bit more logic resources than [12; 15]. The consumed look-up tables (LUTs), flip-flops (FFs), and BRAMs account for only 24%, 10%, and 7% of the xc7 vx690t, respectively.  
Figure 9 exhibits the resource usage of every module in the hardware implementation of the priority-based decoder with double update queues. In our decoders, only the LLR RAM, gain RAM, and check-to-variable FIFO are built with 36k BRAMs. Other FIFOs and buffers are built with Distributed RAMs (DRAMs). Thus, the 36k BRAMs used in our decoders are much less than other decoders. Although the design of double update queues  
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline  & **This Work** & [15] & [12] & **This Work** & [15] & [14] \\ \hline Length & \multicolumn{3}{c}{10,368 (code rate = 22/27)} & \multicolumn{3}{c}{2304 (code rate = 3/4)} \\ \hline Standard & \multicolumn{3}{c}{5G NR} & \multicolumn{3}{c}{WiMAX} \\ \hline Device & xc7 vx690t & xc7 vx690t & xc7 Kh160t & xc7 vx690t & xc7 vx690t & xc7 vx485t \\ \hline Quant & [8,8,6] & [8,8,6] & [5,8,6] & [8,8,6] & [8,8,6] & [4,4,4] \\ \hline Algorithm & OMSA & OMSA & OMSA & OMSA & OMSA & / \\ \hline Slice & 29,521 & 30,824 & / & 7477 & 7906 & 12,496 \\ \hline LUT & 103,674 & 100,929 & 74,373 & 26,744 & 24,228 & 40,700 \\ \hline FF & 89,615 & 85,431 & 46,517 & 19,594 & 23,290 & 26,925 \\ \hline
36k BRAM & 108 & 136.5 & 198.5 & 27 & 33.5 & 40.5 \\ \hline \(f_{max}\) & \multirow{2}{*}{255.0} & \multirow{2}{*}{261.0} & \multirow{2}{*}{160.0} & \multirow{2}{*}{310.0} & \multirow{2}{*}{314.6} & \multirow{2}{*}{142.8} \\ \([\text{MHz}]\) & & & & & & \\ \hline \(T_{norm}\) & \multirow{2}{*}{31.4} & \multirow{2}{*}{31.7} & \multirow{2}{*}{11.96} & \multirow{2}{*}{8.2} & \multirow{2}{*}{8.5} & \multirow{2}{*}{10.8} \\ \([\text{Gbps}]\) & & & & & & \\ \hline \hline \end{tabular}
\end{table}
Table 1: Implementation results for 5G NR and WiMAX decoders in comparison with previous works.  
Figure 8: Average iteration number necessary for successful decoding for 5G NR (code rate = 22/27) compared with the result of the hybrid schedule.  
seems to consume a lot of resources, the LUTs used for double update queues account for only 15.5% of the LUTs in the decoder. The FFs used for double update queues account for only 15.4% of the FFs in the decoder.