LTE Turbo Decoder

Decode turbo-encoded samples

Libraries:
Wireless HDL Toolbox / Error Detection and Correction

Description

The LTE Turbo Decoder block implements the turbo decoder required by LTE standard TS 36.212 [1] and provides an interface and architecture optimized for HDL code generation and hardware deployment. The block iterates over two MAX decoders. You can specify the number of iterations. The coding rate is 1/3. The block accepts encoded bits as a 3-by-1 vector of soft-coded values, [S P1 P2]. In this vector, S is the systematic bit, and P1 and P2 are the parity bits from the two encoders.

This block uses a streaming sample interface with a bus for related control signals. This interface enables the block to operate independently of frame size, and to connect easily with other Wireless HDL Toolbox™ blocks. The block accepts and returns a value representing a single sample, and a bus containing three control signals. These signals indicate the validity of each sample and the boundaries of the frame. To convert a matrix into a sample stream and these control signals, use the Frame To Samples block or the whdlFramesToSamples function. For a full description of the interface, see Streaming Sample Interface.

The block can accept the next frame only after it has completed decoding the previous frame. You must leave Iterations*2*HalfIterationLatency+BlockSize+4 idle cycles between input frames. The half-iteration latency is described in the Algorithms section. Alternatively, you can use the output signal ctrl.end to determine when the block is ready for new input.

This waveform shows an input frame of 120 samples (+ 4 tail bits), and 2632 idle cycles between frames. Each input sample is a vector of three fixed-point soft-decision values. The input and output ctrl buses are expanded to show the control signals. start and end show the frame boundaries, and valid qualifies the data samples.

Logic Analyzer waveform of LTE Turbo Decoder block input and output signals

Examples

Turbo Decode Streaming Samples

Use LTE Turbo Decoder block to decode data, and how to compare hardware-friendly design with results from LTE Toolbox™.

Open Script

Ports

Input

expand all

data — Input sample
three-element vector

Input sample, specified as a three-element integer vector. The values represent soft-coded probabilities. If the value is negative, the bit is more likely to be 0. If the value is positive, the bit is more likely to be 1. The first element is the sequential bit, and the other two elements are parity bits. The block expects input frames of BlockSize + 12 samples. This frame size includes the tail bits, in the order specified by LTE standard TS 36.212 [1].

For a hardware implementation, use a fixed-point type with two or three integer bits and one to four fractional bits. Internal data types are derived from this data type, and lower precision types can result in loss of decoding precision. If the input data type has zero fractional bits or less than two integer bits, the block returns a warning. double and single are supported for simulation but not for HDL code generation.

Data Types: fixdt(1,WL,FL) | single | double

ctrl — Control signals accompanying sample stream
`samplecontrol` bus

Control signals accompanying the sample stream, specified as a samplecontrol bus. The bus includes the start, end, and valid control signals, which indicate the boundaries of the frame and the validity of the samples.

start — Indicates the start of the input frame
end — Indicates the end of the input frame
valid — Indicates that the data on the input data port is valid

For more details, see Sample Control Bus.

Data Types: bus

blockSize — Turbo code block size
integer

Turbo code block size, specified as an integer. This value must be one of the 188 values specified in the LTE standard, from 40 to 6144 in these intervals: [40:8:512 528:16:1024 1056:32:2048 2112:64:6144].

Dependencies

This port appears when you set Block size source to Input port.

Data Types: single | double | uint16 | fixdt(0,13,0)

Output

expand all

data — Output sample
scalar

Output sample, returned as a binary scalar. double and single are supported for simulation but not for HDL code generation.

Data Types: single | double | Boolean | ufix1

ctrl — Control signals accompanying sample stream
`samplecontrol` bus

Control signals accompanying the sample stream, returned as a samplecontrol bus. The bus includes the start, end, and valid control signals, which indicate the boundaries of the frame and the validity of the samples.

start — Indicates the start of the output frame
end — Indicates the end of the output frame
valid — Indicates that the data on the output data port is valid

For more details, see Sample Control Bus.

Data Types: bus

Parameters

expand all

Block size source — How to specify the block size
`Input port` (default) | `Property`

Select whether you specify the block size with an input port or enter a fixed value as a parameter. If you select Property, the Block size parameter appears. If you select Input port, the blockSize port appears.

Block size — Turbo code block size
`6144` (default)

Turbo code block size, specified as an integer. This value must be one of the 188 values specified in the LTE standard, from 40 through 6144 in these intervals: [40:8:512 528:16:1024 1056:32:2048 2112:64:6144]. This value is registered for each frame, when ctrl.start = 1 (true).

Dependencies

This parameter appears when you set Block size source to Property.

Number of decoding iterations — How many MAX decoding iterations to perform
`6` (default) | positive integer

How many MAX decoding iterations to perform, specified as a positive integer. The decoder implementation uses a single MAX decoder, with the output data of each half-iteration routed back to the input. A higher iteration count increases accuracy and adds latency. After about 15 iterations, the algorithm does not provide further accuracy.

Algorithms

expand all

The block implements an iterative decode algorithm using a single decoder and single interleaver. This diagram shows the conceptual algorithm for one iteration.

Although the diagram shows two decoders and three interleavers, the block actually implements the algorithm using only one decoder and one interleaver. The decoder performs one half-iteration and interleaves the results. Then the output is routed back to the input for the next half-iteration. The interleaver computes the interleave indexes from the block size. For details of the interleaver implementation, see LTE Turbo Encoder.

The odd half-iterations compute the likelihood ratio from uninterleaved bits (P1, S, and deinterleaved results of P2 decoding). The even half-iterations compute the likelihood ratio from the interleaved bits (P2 and interleaved results of P1 and S decoding).

The decoder block uses the BCJR algorithm to find the likelihood ratio of a particular bit [2].

$\begin{array}{l} L (u_{k}) ≜ \log (\frac{P (u_{k} = + 1 | y)}{P (u_{k} = + 1 | y)}) \\ = \log (\frac{\sum_{s^{+}} p (s_{k - 1} = s', s_{k} = s, y) / p (y)}{\sum_{s^{-}} p (s_{k - 1} = s', s_{k} = s, y) / p (y)}) \end{array}$

The probabilities can also be represented in terms of current and future states:

$\begin{array}{l} p (s', s, y) = α_{k - 1} (s') \cdot γ_{k} (s', s) \cdot β_{k} (s) \\ α_{k - 1} (s') = P (s', y_{< k}) \\ γ_{k} (s', s) = P (y_{k}, s | s') \\ β_{k} (s) = P (y_{< k} | s) \end{array}$

The α probability represents the previous state, β represents the current state probability, and ɣ represents the next state. The algorithm calculates ɣ from the input values. The α and β probabilities are calculated using forward and backward recursion over the possible states of the trellis, and also depend on ɣ. All calculations are done in the log domain.

$\begin{array}{l} α_{k} = α_{k - 1} (s') \cdot γ_{k} (s', s) \\ β_{k - 1} (s') = β_{k} (s) \cdot γ_{k} (s', s) \end{array}$

The initial conditions for α and β are:

$\begin{array}{l} α_{0} (s) = {\begin{matrix} 1, s = 0 \\ 0, s \neq 0 \end{matrix} \\ β_{0} (s) = {\begin{matrix} 1, s = 0 \\ 0, s \neq 0 \end{matrix} \end{array}$

This diagram shows the half-iteration decoder and interleaver architecture. The initial likelihood is set to zero.

In a normal BCJR architecture, the algorithm cannot compute β until the entire frame is in memory. It must perform a full-frame forward trace and then a full-frame backward trace, which means the latency of one half-iteration is two frame lengths. The required memory is BlockSize*NumStates*DataWidth. In this case, NumStates is eight, from LTE standard TS 36.212 [1].

However, this decoder implementation uses a sliding window to reduce the required memory and the latency of the algorithm [3]. The window size is 32 samples, which is five times the trellis constraint length of 7. The latency of one half-iteration is:

$(c e i l (\frac{B l o c k S i z e}{W i n S i z e}) + 2) \times W i n S i z e + P i p e D e l a y$

The required memory with sliding window is 2*32*NumStates*DataWidth. This figure shows how the β calculation traces and decodes one window at a time, alternating input between the A and B calculation blocks.

Performance

These resource and performance data are the synthesis results from the generated HDL targeted to an AMD^® Zynq^®-7000 ZC706 board. This implementation is for a fixed block size of 6144, six decode iterations, and sfix5_en2 input data samples. The design achieves 306.6 MHz clock frequency.

Resource	Uses
LUT	4771
LUTRAM	212
FFS	4691
Block RAM (16K)	7

The RAM size grows with block size. When you enable the block size port, RAM sufficient for the largest block size is used.

References

[1] 3GPP TS 36.212. "Multiplexing and channel coding." 3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Evolved Universal Terrestrial Radio Access (E-UTRA). URL: https://www.3gpp.org.

[2] Bahl, L. R., J. Cocke, F. Jelinek, and J. Raviv. "Optimal Decoding of Linear Codes for Minimizing Symbol Error Rate." IEEE Transactions on Information Theory. Vol 1T-20, March 1974, pp. 284–287.

[3] Viterbi, Andrew J. "An Intuitive Justification and a Simplified Implementation of the MAP Decoder for Convolutional Codes." IEEE Journal on Selected Areas in Communications. Vol. 16, No. 2, February 1998.

Extended Capabilities

C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.

This block supports C/C++ code generation for Simulink^® accelerator and rapid accelerator modes and for DPI component generation.

HDL Code Generation
Generate VHDL, Verilog and SystemVerilog code for FPGA and ASIC designs using HDL Coder™.

HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic.

HDL Architecture

This block has one default HDL architecture.

HDL Block Properties

ConstrainedOutputPipeline	Number of registers to place at the outputs by moving existing delays within your design. Distributed pipelining does not redistribute these registers. The default is `0`. For more details, see ConstrainedOutputPipeline (HDL Coder).
InputPipeline	Number of input pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is `0`. For more details, see InputPipeline (HDL Coder).
OutputPipeline	Number of output pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is `0`. For more details, see OutputPipeline (HDL Coder).

Restrictions

You cannot generate HDL for this block inside a Resettable Synchronous Subsystem (HDL Coder) or an Enabled Synchronous Subsystem (HDL Coder).

Version History

Introduced in R2017b

LTE Turbo Decoder

Description