In this paper, we follow a cross-layer approach to increase the FER performance for a fully LTE-A Pro compatible Turbo-Code decoder hardware architecture without the need to trade off throughput against FER performance. We employ a combination of new techniques developed in our group and use synergies accross different layers of the decoding to improve the FER performance significantly accross a wide range of code block sizes and code rates. Starting from a fully LTE-A Pro Turbo-Code decoder architecture optimized for high throughput, we demonstrate the negligible hardware overhead of the improved algorithms. To the best of our knowledge, a most advanced hardware implementation of a complete Turbo-Code decoder with the new techniques, which enable coding gains up to 1.8 dB compared to state-of the-art with negligible overhead, is demonstrated for the first time. The rest of this paper is structured as follows: Sect.  will give background information on state-of-the-art Turbo-Code decoder architectures and the LTE Turbo-Coding scheme. Section  then describes our Cross-Layer approach and the employed techniques before Sect.  discusses the proposed Turbo-Code decoder architecture with a focus on the architectural changes for the implemented techniques compared to state-of-the-art.

Post place and route implementation results will be discussed in Sects.  and concludes the paper.

State-of-the-art Turbo-Code decoder hardware architectures can be classified based on their approach on how to parallelize the inherrently serial max-Log-Map algorithm:

Parallel Map. (PMAP) – decoders use spacial parallelism by splitting the code block trellis into sub-trellises (or sub-blocks) that are decoded on p parallel sub-decoder cores (see Fig. a) and parallel windowed processing of forward and backward recursions within the cores. Implementations which use the PMAP architecture are reported, for example by , , and .

Fully Pipelined Map. (FPMAP) – decoders implement a fully parallel processing of both component codes , (see Fig. b). The recently published architecture promises very high throughput and can be seen as an extreme case of the PMAP architecture where each sub-trellis essentially consists of one step of the original trellis.

Pipelined Map. (XMAP) – decoders, as reported by or , unroll and pipeline the recursions, a functional parallelization. Each clock cycle, one continuous sub-trellis (window) is fed into the “X”-shaped pipeline structure (see Fig. c) which gives the decoder its name.

Spliting up the code block trellis into sub-blocks or windows, however, weakens the protection of the bits at the sub-block/window borders, because state metric information is lost. Since the FPMAP architecture leads to sub-trellises consisting of only one step, this effect is more pronounced for the FPMAP and is the reason why it needs more iterations than the other decoder types, even at rate 1/3. For the other decoder types, the state metrics at the sub-block borders can to be estimated.

The estimation for the state metrics at the sub-block borders can be taken from a warm-up recursion phase (acquisition – ACQ) or from the state metric calculations of the previous iteration (Next Iteration Initialization – NII) as proposed by . For very small windows and/or high code rates, a combination of ACQ and NII can be used to mitigate very long acquisition lengths (see ). Note, that state-of-the-art Turbo-Code decoders expect their input depunctured to rate 1/3 and thus do not take into account the puncturing pattern that is used to adapt the rate.

For small code block sizes K and large degrees of parallelism p, the sub-block sizes S=K/p become very small. Thus, the achievable level of parallelism for a desired Quality of Service (QoS) is limited, especially for high code rates. Therefore, in state-of-the-art PMAP decoders, smaller code words are only decoded on a fraction of the available sub-decoder cores and the smallest code block sizes (i.e. 40≤K≤248) are decoded only using a single sub-decoder core while the others remain idle.

The LTE standard organizes the data to be transmitted over the Downlink Shared Channel (DL-SCH) in each transmission time interval (TTI) in transport blocks (TB) which have sizes ranging from 16 to 97896 bit (see ). The DL-SCH channel coding scheme is depicted in Fig. b. The uncoded transport block is first attached with a 24 bit CRC for the hybrid automatic repeat request (HARQ) protocol. Then, the transport block is divided into smaller code blocks if its size (with attached CRC) is larger than 6144 bit. This process is called code block segmentation. After segmentation, the code blocks contain a maximum of 6120 bits and are each attached with another 24 bit CRC (the code block CRC) before being encoded with a rate 1/3 Turbo-Code. The code block segmentation step is followed by a circular buffer rate matching to adapt the code rate by puncturing or repetition. Last step is the code block concatenation.

With a CRC based iteration control, the decoding process is terminated early, as soon as the CRC on the decoded code word evaluates to zero. Otherwise, the decoding is continued until a maximum number of half-iterations (nHImax) is reached. This is depicted in Fig. b, whereas Fig. a illustrates the case without early stopping.

For iteration balancing, the CRC based iteration control, which is used to terminate the decoding process early in the event of successful decoding, is extended to account for the TB structure on system level. Iteration balancing makes use of the fact, that most code blocks are decoded in less than nHImax half-iterations and that large code block buffers are available in the rate matching unit for the incremental redundancy of the HARQ (see ). Instead of stopping the decoder after nHImax half-iterations and signaling a failed decoding if the CRC does not evaluate to zero, with iteration balancing a budged B=nCB⋅nHImax is considered, where nCB is the number of code blocks within a TB (see Fig. c). By keeping track of the iterations that have been spent on previous code blocks belonging to the same TB, the Turbo-Code decoder is able to spent more decoding iterations on blocks that contain more errors, thereby using the iterations saved by the early stopping. To avoid the case where a single undecodable code block at the beginning of a TB consumes the complete iteration budget, the decoding for each code block is allowed to run for 4⋅nHImax half-iterations. Our investigations have shown that this value is a very good trade-off. As can be seen in Fig. c and as was shown in , iteration balancing can not only be used to improve the communications performance, but can also be used to guarantee a higher throughput on system level. For this work, however, we focus on the improvement in communications performance.

For LTE, code rates r>1/3 are achieved by puncturing the rate 1/3 mother Turbo-Code (see Sect. ). To limit the degradation of the Turbo-Code performance at code rates as high as 0.94, not only the parity information but also the systematic information is punctured. In recent work, we identified the positions where the systematic bit is punctured away as critical bit positions (see ). We could show, that, if these positions are not correctly decoded by the decoder in the first few half-iterations, the decoding process is likely to fail, since the decoder has trouble recovering the correct hard decision bit for these positions in the later half-iterations. In LTE, the critical bit positons are at the bit indices i=5+16⋅jforKmod16=0,j∈N13+16⋅jforKmod16=8,j∈N, assuming the bit indices start at i=1. At high code rates, these critical positions exhibit the majority of residual errors after Turbo-Code decoding.

The remainder of this section describes new approaches to improve the decoding performance for small code blocks at high code rates on system level. In Sect. , we show, for the first time, the application of these system level techniques onto a fully LTE compatible hardware architecture on bit level.

The new LTE-A Turbo-Code decoder architecture, which will be presented in Sect. , incorporates for the first time enhanced event-flipping and forced symbol decoding on-the-fly to improve the communications performance for small code blocks at high code rates, as well as an iteration control with iteration balancing to improve communications performance on transport block level for high code rates. To put the communications performance into context, we performed detailed simulations to compare our new approach to other state-of-the-art Turbo-Code decoders achieving a similar throughput.

Table  gives the algorithm parameters of the compared decoder architectures, while Table  lists the implementation related data. Our investigatons have shown N=4 and M=1 to be a good match for the LTE configuration, while still allowing an integration of the new on-the-fly flip-and-check CRC calculation scheme with negligible hardware overhead. The parameter o=4 results from the usable 16=24 sub-decoder cores.

For the smallest LTE code block sizes, i.e. 40≤K≤248, the decoder uses improved parallel symbol forcing to improve the communications performance. At design time, the available p=16 sub-decoder cores are assigned a sub-decoder index from 0–15.

While decoding, the extrinsic values at the critical positions are saturated after the first two half-iterations before being written to RAM. Saturation is performed according to a pattern that corresponds to their sub-decoder index. The extrinsic values for sub-decoder Map0, for example, will be saturated to the maximum value for all four critcal positions. Figure  also illustrates the symbol forcing unit.

Figure  shows the structure of the FC extended CRC unit which is based on the on-the-fly architecture we presented in 2015. This section will describe the structure of the FC extended CRC unit and give the underlying equations where appropriate. For an in-depth derivation of the on-the-fly CRC calculation scheme, the reader is referred to the original publication (see ).

The CRC unit calculates the CRC over the decoded code word A(x) based on the following equation: CRC[A(x)]=∑k=0p-1CRC[xS-M]k︸=Ck⋅PkmodG(x). There, G(x) is the CRC generator polynomial of degree M, p is the parallelism , S=K/p is the sub-block size, Ck is the sub-block offset and Pk is the partial sub-block CRC. In our case, it is G(x)=CRC24B for which M=24 (see also ), p=16. A table lookup is used to realize the Ck=(CRC[xS-M])k from Eq. () and this lookup table is initialized at the beginning of the decoding (Ck LUT in Fig. ).

The sub-block CRCs Pk for the sub-blocks are calculated according to Pk=∑l=0S/2-1akS+δ(2l)CRCeven+akS+δ(2l+1)CRCodd. Dedicated blocks are used to calculate the partial CRCs CRCeven and CRCodd for the hard decision bits akS+δ(2l) and akS+δ(2l+1) respectively. The bit index offset for the kth sub-block is given by k⋅S and the function δ(l) describes the bit index offset within the sub-blocks according to δ(l)=l,for non-interleaved hiΠ(l)modS,for interleaved hi. For efficient implementation, the sub-block internal bit index offset is broken down into δ=addr/24+addrmod24 (Divide by M in Fig. ). Using these, CRCeven and CRCodd are calculated with a combination of table lookup and dedicated block.

The FC extensions, which are used for the code blocks with 40≤K≤248, consist of three parts:

Selectively storing the partial CRCs for the critical positions,

The most unreliable bit position is selected and stored in parallel to the decoding, and individually for each sub-decoder core. If the current LLR-input to the CRC unit is of smaller magnitude than the previously stored one and the bit position is not included in the set of critical positions, the bit position (calculated from the address), its magnitude and its partial CRC are stored in registers. The same happens, when the magnitude is identical, but the bit index is smaller. Lastly, after decoding, the list of the 2n+m=24=16 different combined sums of partial CRCs for the critical positions and the position with the minimum LLR is compiled and sent to the iteration control.

The iteration control uses iteration balancing with a configurable budget of B≤192 half-iterations (see Sect. ). For transport blocks with more than one code block, the budget is reset at the start of the transport block. Transport blocks consisting of one code block use a budget of 12 half-iterations.

For all code block sizes, a CRC based early stopping is used. If the output from the CRC unit evaluates to 0 after the decoding of a half-iteration has finished, i.e. the CRC check is passed successfully, the decoding process is terminated early.

For code blocks with size 40≤K≤248, however, a list of 32 CRC results is passed from each sub-decoder core. The decoding process is then terminated early if (at least) one decoder core has (at least) one succeeding CRC in the according list. If there are more than one successful CRCs whithin a list, the successful CRC with the smallest list index is chosen as the valid solution. Similarly, if there are more than one sub-decoder cores with a successful CRC in the same half-iteration, the result of the sub-decoder with the lower index is chosen as the correct result.

From the selected result, a correction pattern is generated and the address of the weakest LLR position is send to the output of the Turbo-Code decoder. Thereby, the hard decision bits can be corrected on-the-fly when they are read from the hard decision memory.