LTE CRC Encoder

Generate checksum and append to input sample stream

expand all in page

Library:
Wireless HDL Toolbox / Error Detection and Correction

Description

TheLTE CRC Encoderblock calculates and appends a cyclic redundancy check (CRC) checksum for each frame of streaming data samples. You can select from the polynomials specified by LTE standard TS 36.212[1]. The block provides a hardware-optimized architecture and interface.

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 theFrame To Samplesblock or thewhdlFramesToSamplesfunction. For a full description of the interface, seeStreaming Sample Interface.

You must not apply another frame before the previous frame has completed. The hardware-friendly algorithm adds(CRCLength+ 3)/InputSizecycles of latency. To account for the additional cycles of the appended checksum samples, and the latency, you must apply a minimum spacing of(2*CRCLength+ 3)/InputSizebetween input frames. Alternatively, you can use the output signalctrl.endto determine when the block is ready for new input. If you apply the next frame too early, thectrl.startsignal resets the checksum calculation and truncates the previous frame.

This waveform shows a 40-sample frame, input two samples at a time to a CRC16 encoder. The gap between the input frames is therefore 8 cycles. Due to the insertion of the checksum, the outputctrl.validsignal stays continuously high with no gaps between frames. The input and outputctrlbuses are expanded to show the control signals.startandendshow the frame boundaries, andvalidqualifies the data samples.

Ports

Input

expand all

`data`— Input sample
binary scalar | unsigned integer scalar | binary vector

Input sample, specified as a binary scalar, unsigned integer scalar, or binary vector. The vector size,InputSize, must be less than or equal to the length of the polynomial. The CRC length also must be divisible by the vector size. For example, for polynomial typeCRC24A, the valid vector sizes are 24, 12, 8, 6, 4, 3, 2, and 1. An integer input is interpreted as a binary word. For example, vector input[0 0 0 1 0 0 1 1]相当于uint8input19.

doubleandsingleare supported for simulation but not for HDL code generation.

`ctrl`— Control signals accompanying sample stream
`samplecontrol`bus

Control signals accompanying the sample stream, specified as asamplecontrolbus. The bus includes thestart,end, andvalidcontrol 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 inputdataport is valid

For more details, seeSample Control Bus.

Data Types:bus

Output

expand all

`data`— Output sample
binary scalar | integer scalar | binary vector

Output sample, returned as a binary scalar, integer scalar, or binary vector of the same data type and size as the input sample. The block appends the calculated and masked checksum at the end of each frame.

doubleandsinglebinary values are supported for simulation but not for HDL code generation.

`ctrl`— Control signals accompanying sample stream
`samplecontrol`bus

Control signals accompanying the sample stream, returned as asamplecontrolbus. The bus includes thestart,end, andvalidcontrol 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 outputdataport is valid

For more details, seeSample Control Bus.

Data Types:bus

Parameters

expand all

`CRC Type`— Encode polynomial
`CRC16`(default) |`CRC8`|`CRC24A`|`CRC24B`

The encode polynomial options are the four CRC types described in the LTE standard TS 36.212[1], Section 5.1.1.

`CRC Mask`— Mask applied to checksum
`0`(default) | integer from 0 to 2^CRCLength– 1

Mask applied to checksum, specified as an integer representing a binary word from 0 to 2^CRCLength– 1. This mask is typically a Radio Network Temporary Identifier (RNTI).

Model Examples

Append CRC Checksum to Streaming Data

Use the LTE CRC Encoder block to encode data, and how to compare the hardware-friendly design with the results from LTE Toolbox™. The workflow follows these steps:

Open Script

Algorithms

expand all

When you use vector or integer input, the block implements a parallel CRC algorithm[2]. The implementation is the same as the algorithm used by the Communications Toolbox™ blocksGeneral CRC Generator HDL OptimizedandGeneral CRC Syndrome Detector HDL Optimized.

To provide high throughput for modern communications systems, the block implements the CRC algorithm with a parallel architecture. This architecture recursively calculatesMbits of a CRC checksum for eachWinput bits. At the end of the frame, the final checksum result is appended to the message. For a polynomial length ofM, the recursive checksum calculation forWbits in parallel is

$X^{'} = F_{W} (\times) X (+) D .$

F_Wis anM-by-Mmatrix that selects elements of the current state for the polynomial calculation with the new input bits.Dis anM-element vector that provides the new input bits, ordered in relation to the generator polynomial and padded with zeros. The block implements the (×) with logical AND and (+) with logical XOR.

Latency

The latency from start of input frame to start of output frame is(CRCLength+ 3)/InputSizecycles. The latency from end of input frame to end of output frame is (2*CRCLength+ 3)/InputSizeto account for appending the checksum.

Performance

These resource and performance data are the synthesis results from the generated HDL targeted to a Xilinx^®Zynq^®-7000 ZC706 board. The implementation is for aCRC24polynomial and scalar input. The design achieves 588.3 MHz clock frequency.

Resource	Uses
LUT	121
LUTRAM	3
FFS	132
Block RAM (16K)	0

A larger input vector size increases throughput and increases resource use.

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] Campobello, Giuseppe, Giuseppe Patane, and Marco Russo. "Parallel CRC Realization."IEEE交易有限公司mputers. Vol. 52, No. 10, October 2003, pp. 1312–1319.

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 Verilog and VHDL 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 a single, 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, seeConstrainedOutputPipeline(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, seeInputPipeline(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, seeOutputPipeline(HDL Coder).

Version History

Introduced in R2017b

LTE CRC Encoder

Description