5G LDPC Intel FPGA IP User Guide
About the 5G LDPC Intel FPGA IP
LDPC codes replace Turbo codes, popular in 3G and 4G wireless cellular communications. LDPC codes offer better spectral efficiency and support the high throughput for 5G new radio (NR).
5G LDPC Intel FPGA IP Features
The 5G LDPC IP offers the following features:
- 3GPP 5G LDPC specification compliant
- For
the decoder:
- Per-block modifiable code block length, code rate, base graph, and maximum number of iterations
- Configurable input precision
- Layered decoder scheduling architecture to double the speed of convergence compared to non-layered architecture
- Early termination based on the syndrome check after each iteration
- For the encoder: per-block modifiable code block length and code rate
- No external memory requirement
- MATLAB and C++ models for performance simulation and RTL test vector generation
- Verilog HDL testbench option
- Avalon® -Streaming (Avalon-ST) input and output interfaces
5G LDPC Intel FPGA IP Device Family Support
Intel offers the following device support levels for Intel FPGA IP:
- Advance support—the IP is available for simulation and compilation for this device family. FPGA programming file (.pof) support is not available for Quartus Prime Pro Stratix 10 Edition Beta software and as such IP timing closure cannot be guaranteed. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
- Preliminary support—Intel verifies the IP core with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. You can use it in production designs with caution.
- Final support—Intel verifies the IP with final timing models for this device family. The IP meets all functional and timing requirements for the device family. You can use it in production designs.
Device Family | Support |
---|---|
Intel® Stratix® 10 | Advance |
Intel® Arria® 10 | Final |
Other device families | No support |
5G LDPC IP Release Information
Item | Description |
---|---|
Release Date | 2018.10.24 |
Ordering Code | IP-5G-LDPC |
Intel verifies that the current version of the Intel® Quartus® Prime software compiles the previous public version of each IP. Intel does not verify that the Intel® Quartus® Prime software compiles IP versions older than the previous version. The Intel FPGA IP Release Notes lists any exceptions.
5G LDPC IP Resource Utilization and Performance
Product | FMAX (MHz) | ALMs | M20K Memory Blocks | ||
---|---|---|---|---|---|
Speed Grade | |||||
-1 | -2 | -3 | |||
LDPC Encoder | 474 | 454 | 418 | 16,952 | 22 |
LDPC Decoder, 5-bit LLRs | 367 | 345 | 322 | 46,713 | 282 |
LDPC Decoder, 6-bit LLRs | 346 | 330 | 302 | 55,448 | 321 |
Product | FMAX (MHz) | ALMs | M20K Memory Blocks | ||
---|---|---|---|---|---|
Speed Grade | |||||
- 1 | - 2 | - 3 | |||
LDPC Encoder | 498 | 467 | 422 | 17,945 | 23 |
LDPC Decoder, 5-bit LLRs | 503 | 438 | 413 | 55,226 | 282 |
LDPC Decoder, 6-bit LLRs | 481 | 428 | 399 | 61,937 | 321 |
Getting Started with the 5G LDPC Intel FPGA IP
Installing and Licensing Intel FPGA IP Cores
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
Location | Software | Platform |
---|---|---|
<drive>:\intelFPGA_pro\quartus\ip\altera | Intel® Quartus® Prime Pro Edition | Windows* |
<drive>:\intelFPGA\quartus\ip\altera | Intel® Quartus® Prime Standard Edition | Windows |
<home directory>:/intelFPGA_pro/quartus/ip/altera | Intel® Quartus® Prime Pro Edition | Linux* |
<home directory>:/intelFPGA/quartus/ip/altera | Intel® Quartus® Prime Standard Edition | Linux |
Intel FPGA IP Evaluation Mode
- Simulate the behavior of a licensed Intel® FPGA IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Intel® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center or contact your local Intel FPGA representative.
The Intel® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
5G LDPC IP Timeout Behavior
For IP, the untethered time-out is 1 hour; the tethered time-out value is indefinite. Your design stops working after the hardware evaluation time expires. The Quartus Prime software uses Intel® FPGA IP Evaluation Mode Files (.ocp) in your project directory to identify your use of the Intel® FPGA IP Evaluation Mode evaluation program. After you activate the feature, do not delete these files.
When the evaluation time expires, for the 5G LDPC IP core encoders cw goes low and rst_n goes low; for decoders source_data goes low, reset_n goes low.
Designing with the 5G LDPC Intel FPGA IP
Generating an 5G LDPC Intel FPGA IP
- Create a New Intel® Quartus® Prime project
- Open IP Catalog.
- Select DSP > Error Detection and Correction > 5G LDPC and click Add
-
Enter a name for your IP variant and click
Create.
Figure 3. IP Variant File NameThe name is for both the top-level RTL module and the corresponding .ip file.The parameter editor for this IP appears.
-
Choose your parameters.
You can choose Encoder or Decoder and 5 or 6 for IN_WIDTH (decoder only).Figure 4. 5G LDPC Parameter Editor
-
For an
optional design example, click Generate Example
Design
The software creates a design example of the encoder or decoder in <project directory>\intel_FPGA_ldpc_5g_0_example_designFigure 5. Design Example Directory Structure
- Click Generate HDL.
Simulating the 5G LDPC Intel FPGA IP
Refer to Simulator Support in the Intel® Quartus® Prime Pro Edition User Guide: Third-Party Simulation for the Intel® -specific EDA simulator versions for RTL.
- Change to the intel_FPGA_ldpc_5g_0_example_design\simulation_scripts directory.
- Change to the directory of your preferred simulator.
- Run the simulation script <simulator>_setup.tcl or <simulator>.sh .
- Analyze the result signals in a waveform viewer.
5G LDPC Simulation Results
Encoder Simulation Results

msg_mode | msg_vld | msg | msg_sop | msg_eop |
---|---|---|---|---|
72 | HIGH | 686 | HIGH | LOW |
72 | HIGH | 633 | LOW | LOW |
72 | HIGH | 481 | LOW | LOW |
72 | HIGH | 724 | LOW | LOW |
72 | HIGH | 32 | LOW | LOW |
72 | HIGH | 999 | LOW | LOW |
72 | HIGH | 925 | LOW | LOW |
72 | HIGH | 11 | LOW | LOW |
72 | HIGH | 899 | LOW | LOW |
72 | HIGH | 956 | LOW | LOW |
72 | HIGH | 146 | LOW | LOW |
72 | HIGH | 463 | LOW | LOW |
72 | HIGH | 382 | LOW | LOW |
72 | HIGH | 447 | LOW | LOW |
72 | HIGH | 623 | LOW | LOW |
72 | HIGH | 285 | LOW | LOW |
72 | HIGH | 474 | LOW | LOW |
72 | HIGH | 102 | LOW | LOW |
72 | HIGH | 126 | LOW | LOW |
72 | HIGH | 951 | LOW | LOW |
72 | HIGH | 107 | LOW | LOW |
72 | HIGH | 237 | LOW | HIGH |
67 | LOW | LOW |

cw_vld | cw_mode | cw | parity bits | cw_sop | cw_eop |
---|---|---|---|---|---|
LOW | 72 | 686 | LOW | LOW | |
LOW | 72 | 633 | LOW | LOW | |
HIGH | 72 | 481 | HIGH | LOW | |
HIGH | 72 | 724 | LOW | LOW | |
HIGH | 72 | 32 | LOW | LOW | |
HIGH | 72 | 999 | LOW | LOW | |
HIGH | 72 | 925 | LOW | LOW | |
HIGH | 72 | 11 | LOW | LOW | |
HIGH | 72 | 899 | LOW | LOW | |
HIGH | 72 | 956 | LOW | LOW | |
HIGH | 72 | 146 | LOW | LOW |

cw_vld | cw_mode | cw | parity bits | cw_sop | cw_eop |
---|---|---|---|---|---|
HIGH | 72 | 742 | parity | LOW | LOW |
HIGH | 72 | 738 | Parity | LOW | LOW |
HIGH | 72 | 9 | parity | LOW | LOW |
HIGH | 72 | 952 | parity | LOW | LOW |
HIGH | 72 | 805 | parity | LOW | LOW |
HIGH | 72 | 769 | parity | LOW | LOW |
HIGH | 72 | 105 | parity | LOW | HIGH |
LOW | Don’t care | Don’t care | Don’t care | LOW | LOW |
Decoder Simulation Results
- sink_valid remains asserted for the duration of the LLR codeword while input data is valid. The upstream component can deassert it as needed.
- sink_sop is asserted only for the first data block in. It gets stretched for more than one clock cycle by the backpressure from the decoder, i.e. because the decoder deasserts sink_ready
- sink_eop pulses high for one clock cycle on the last valid input data block. It also can be stretched by the backpressure from the decoder’s sink.

- source_valid and source_sop are asserted about the same time. source_sop is asserted only for the first message block out
- The decoder may assert source_sop earlier and keep it high for a number of clock cycles – only the data block output during the last clock cycle just before source_sop is deasserted (and with source_valid asserted) is the actual beginning of the message
- source_valid remains asserted for the duration of the output message
- source_sop may get stretched for more than one clock cycle by the backpressure from the decoder, i.e. because the testbench deasserts source_ready downstream
- sink_eop is asserted for the last valid message block output. It also can be stretched by the backpressure from the sink downstream.

5G LDPC Intel FPGA IP Functional Description
- 5G LDPC Decoder
The 5G LDPC Decoder supports all modes specified in the 3GPP New Radio specification. - 5G LDPC Encoder
- Avalon-ST Interfaces in DSP IP Cores
Avalon-ST interfaces define a standard, flexible, and modular protocol for data transfers from a source interface to a sink interface.
5G LDPC Decoder
5G LDPC Decoder Signals
Name | Direction | Description |
---|---|---|
clk | Input | Clocks the 5G LDPC decoder IP signals and internal transitions. |
reset_n | Input | Active low, synchronous reset signal for 5G LDPC decoder. Asserting this signal for one clock cycle is sufficient to ensure the reset process initiates. |
Name | Direction | Description |
sink_valid | Input | Qualifies the sink_data signal. When sink_valid is not asserted, the IP stops processing input until you reassert the sink_valid signal. |
sink_sop | Input | Marks the start of an incoming packet. |
sink_eop | Input | Marks the end of an incoming packet. |
sink_ready | Output | Indicates that the decoder
is
ready to receive data on the current clock cycle. The IP
can
backpressure incoming data by deasserting this signal. The readyLatency for this signal is 0: the IP can read valid input data in the same clock cycle in which it raises this signal. Refer to the Avalon Interface Specifications for the description of this Avalon-ST interface property. |
sink_data[(64*IN_WIDTH)-1:0] | Input | Data input. The IP
processes
this input only while it asserts sink_ready and you assert the sink_valid signal. The default value of IN_WIDTH is 6. |
sink_mode[11:0] | Input | Input block mode. The value specifies the
lifting
size, base graph, and code rate. Refer to Input and Output Block
Mode Meaning in 5G LDPC Decoder Data Formats. This signal must be valid for the current information block when the upstream source asserts sink_sop and sink_valid. |
sink_tag[7:0] | Input |
Block tag. An optional tag that accompanies the block from input to output. You can use this tag to identify the correspondence of the input and output block. This signal must be valid for the current information block when the upstream source asserts sink_sop and sink_valid. |
sink_max_iter[5:0] | Input | Specifies the maximum number of decoding iterations.
The
maximum value is 63. This signal must be valid for the current information block when the upstream source asserts sink_sop and sink_valid. |
Name | Direction | Description |
source_valid | Output | The IP asserts this signal when source_data holds valid data. |
source_sop | Output | The IP asserts this signal to mark the start of a packet. |
source_eop | Output | The IP asserts this signal to mark the end of a packet. |
source_ready | Input | Indicates that the design downstream of the IP
is
ready to receive data. The design can backpressure the IP
by
deasserting this signal. The readyLatency for this signal is 0: the downstream design receives data the IP core drives on source_data in the same clock cycle in which the design asserts this signal. Refer to the Avalon Interface Specifications for the description of this Avalon-ST interface property. |
source_data[(383:0] | Output | Data output. When the IP sends valid data on this bus, it asserts the source_valid signal. If source_ready is deasserted, the decoder holds the data constant until source_ready is asserted. |
source_mode[11:0] | Output | The value specifies the
lifting
size, base graph, and code rate. Refer to
Input and Output Block Mode
Meaning in 5G LDPC Decoder Data Formats. This signal is valid when source_sop and source_valid are both asserted. |
source_tag[7:0] | Output | Block tag. An optional tag that goes with the block from input to output. You can use this tag to establish the correspondence of the input and output block. This signal is valid when source_sop and source_valid are both asserted. |
source_blk_K[13:0] | Output | Transmission
block size K, in bits. K is the size of the output block from the
decoder IP. This signal is valid when source_sop and source_valid are both asserted. |
source_blk_Z[8:0] | Output | The lifting
size
of the output block. For the output block, only the source_blk_Z least significant bits
of source_data[383:0] are valid.
This signal is valid when source_sop and source_valid are both asserted. |
source_iter[5:0] | Output | Actual number of decode iterations by the IP to process the current
output block. The count starts at 0 and might not be an accurate
count of full iterations, because the decoding process might stop at
any point
if
the decoder meets early termination
criteria.
The count cannot exceed the value communicated for the current
transmission block via sink_max_iter minus one.
This signal is valid when source_sop and source_valid are both asserted. |
source_et_pass | Output | Indicates
whether the current information block meets early termination
criteria. 0 indicates that the block does not meet early termination
criteria; 1 indicates that the block meets early termination
criteria. The decoder can also assert the signal on the last iteration. This signal is valid when source_sop and source_valid are both asserted. |
5G LDPC Decoder Data Formats
Input Data Format
An input code block of length N consists of N log-likelihood ratio codes (LLRs): L0,L1,L2,...,LN-1. Each LLR is IN_WIDTH bits wide.
IN_WIDTH is 5 or 6. The decoder input on a single active edge of the clock is 64 LLRs. The resulting width of the input data bus to the decoder is 64*IN_WIDTH.
The decoder IP accepts punctured LLRs. You can assume that the IP punctures the first 2*Z bits of the original information block during encoding, where Z is the lifting size. The IP functionally prepends 2*Z implicit LLRs with value IN_WIDTH'b0 to the input stream of LLRs.
The number of clock cycles that the IP requires to receive the LLR values is (nb - 2) * ceil(Z / 64), where nb is the number of columns in the parity check matrix. The value of nb depends on the base graph, the information block size K, and the code rate.
sink_data[64*IN_WIDTH-1:0] = sink_data[383:0] |
clock cycle | ||||
---|---|---|---|---|---|
0 | 1 | ... | 148 | 149 | |
sink_data[5:0] | L0 | L64 | ... | L9472 | L9536 |
sink_data[11:6] | L1 | L65 | ... | L9473 | L9537 |
... | ... | ... | ... | ... | ... |
sink_data[383:378] | L63 | L127 | ... | L9535 | L9599 |
sink_data[64*IN_WIDTH-1:0] | clock cycle | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | … | 78 | 79 | |
sink_data[1*IN_WIDTH-1:0*IN_WIDTH] | L0 | L64 | L128 | L192 | L208 | L272 | L336 | L400 | … | L4080 | L4144 |
… | … | … | … | … | … | … | … | … | … | … | … |
sink_data[16*IN_WIDTH-1:15*IN_WIDTH] | L15 | L79 | L143 | L207 | L223 | L287 | L351 | L415 | … | L4095 | L4159 |
sink_data[17*IN_WIDTH-1:16*IN_WIDTH] | L16 | L80 | L144 | X | L224 | L288 | L352 | X | … | L4096 | X |
… | … | … | … | X | … | … | … | X | … | … | X |
sink_data[64*IN_WIDTH-1:63*IN_WIDTH] | L63 | L127 | L191 | X | L271 | L335 | L399 | X | … | L4143 | X |
Decoder Input LLR Symbol Format
The log-likelihood value is the logarithm of the probability that the received bit is a 0, divided by the probability that this bit is a 1. It is represented as a two’s complement number. A value of zero indicates equal probability of a 1 and a 0, which you should use for depuncturing. The decoder uses asymmetrical numeric range for LLRs including the most negative two's complement value for the chosen number of bits.
LLR (IN_WIDTH=6) | Meaning |
Resulting Hard Decision |
---|---|---|
011111 | Most likelihood of a 0 | 0 |
... | ... | ... |
000001 | Lowest likelihood of a 0 | 0 |
000000 | Equal probability of a 0 or 1 | 1 (the convention implemented by the decoder) |
111111 | Lowest likelihood of a 1 | 1 |
... | ... | ... |
100000 | Most likelihood of a 1 | 1 |
Decoder Input Control and Output Status Signal Formats
The input mode signal, sink_mode[11:0], and the output mode signal, source_mode[11:0], have the same fields. The required input values on sink_mode are the expected output values on source_mode.
- sink_mode[11] encodes the base graph selection. The value of 0 indicates base graph 1 (BG1), and the value of 1 indicates base graph 2 (BG2).
- sink_mode[10:8] is code rate selection. Refer to Table 14.
- sink_mode[7:6] is reserved. Tie to 2’b00.
- sink_mode[5:0] is Z selection. Refer to Table 13.
sink_mode[5:0] | Z | sink_mode[5:0] | Z |
---|---|---|---|
0 | 2 | 26 | 48 |
1 | 3 | 27 | 52 |
2 | 4 | 28 | 56 |
3 | 5 | 29 | 60 |
4 | 6 | 30 | 64 |
5 | 7 | 31 | 72 |
6 | 8 | 32 | 80 |
7 | 9 | 33 | 88 |
8 | 10 | 34 | 96 |
9 | 11 | 35 | 104 |
10 | 12 | 36 | 112 |
11 | 13 | 37 | 120 |
12 | 14 | 38 | 128 |
13 | 15 | 39 | 144 |
14 | 16 | 40 | 160 |
15 | 18 | 41 | 176 |
16 | 20 | 42 | 192 |
17 | 22 | 43 | 208 |
18 | 24 | 44 | 224 |
19 | 26 | 45 | 240 |
20 | 28 | 46 | 256 |
21 | 30 | 47 | 288 |
22 | 32 | 48 | 320 |
23 | 36 | 49 | 352 |
24 | 40 | 50 | 384 |
25 | 44 | X | X |
sink_mode[10:8]
|
Code Rate | Base Graph 1 | Base Graph 2 | ||
---|---|---|---|---|---|
Number of Rows in Parity Check Matrix (mb) | Number of Columns in Parity Check Matrix (nb) | Number of Rows in Parity Check Matrix (mb) | Number of Columns in Parity Check matrix (nb) | ||
000 | 1/5 | X | X | 42 | 52 |
001 | 1/3 | 46 | 68 | 22 | 32 |
010 | 2/5 | 35 | 57 | 17 | 27 |
011 | 1/2 | 24 | 46 | 12 | 22 |
100 | 2/3 | 13 | 35 | 7 | 17 |
101 | 22/30 (~3/4) | 10 | 32 | X | X |
110 | 22/27 (~5/6) | 7 | 29 | X | X |
111 | 22/25 (~8/9) | 5 | 27 | X | X |
Decoder Output Data Format
The width of the source_data[383:0] signal is 384 bits, where only the Z LSBs are valid. You can ignore the rest of the MSBs.The number of output block bits is 22*Z for BG1 and 10*Z for BG2. Hence, the IP requires 22 clock cycles for BG1 and 10 clock cycles for BG2 to output the data.
source_data[383:0] |
Clock Cycle | ||||
---|---|---|---|---|---|
0 | 1 | ... | 20 | 21 | |
source_data[0] | b0 | b384 | ... | b7680 | b8064 |
source_data[1] | b1 | b385 | ... | b7681 | b8065 |
... | ... | ... | ... | ... | ... |
source_data[383] | b383 | b767 | ... | b8063 | b8447 |
source_data[383:0] | Clock Cycle | ||||
---|---|---|---|---|---|
0 | 1 | ... | 8 | 9 | |
source_data[0] | b0 | b208 | ... | b1664 | b1872 |
... | ... | ... | ... | ... | ... |
source_data[207] | b207 | b415 | ... | b1871 | b2079 |
source_data[208] | Ignored | ||||
... | |||||
source_data[383] |
LDPC FEC 5G Decoder Parameters
Parameter | Range | Description |
---|---|---|
IN_WIDTH | 5 or 6 (default value is 6) | The number of bits per input LLR. The width of sink_data is (64 * IN_WIDTH). |
5G LDPC Encoder
5G LDPC Encoder Signals
Name | Direction | Description |
---|---|---|
clk | Input | Clocks the 5G LDPC encoder IP signals and internal transitions. |
rst_n | Input | Active low, asynchronous reset signal for 5G LDPC encoder IP. Asserting this signal for one full clock cycle is sufficient to ensure the reset process initiates. |
Name | Direction | Description |
msg_vld | Input | Qualifies the msg data signal. When
msg_vld is not asserted, the
encoder
stops processing input until you reassert the msg_vld signal. If the encoder deasserts the msg_enc_rdy signal, the upstream source must maintain the current value on msg_vld. |
msg_sop | Input | Marks the start of an incoming packet. |
msg_eop | Input | Marks the end of an incoming packet. |
msg_enc_rdy | Output | Indicates that the
encoder
is ready to receive data on the current clock cycle. The
encoder
can backpressure incoming data by deasserting this signal. The readyLatency for this signal is 0: the IP can read valid input data in the same clock cycle in which it raises this signal. Refer to the Avalon Interface Specifications for the description of this Avalon-ST interface property. |
msg[383:0] | Input | Data input. The encoder processes this input only when the upstream source asserts the msg_vld signal and the IP asserts the msg_enc_rdy signal. If the encoder deasserts the msg_enc_rdy signal, the upstream source must maintain the current value on msg. |
msg_mode[11:0] | Input |
This signal must be valid for the current information block when the upstream source asserts msg_sop.
|
Name | Direction | Description |
cw_vld | Output | The encoder asserts this signal when cw holds valid data. |
cw_sop | Output | The encoder asserts this signal to mark the start of a packet. |
cw_eop | Output | The encoder asserts this signal to mark the end of a packet. |
cw[383:0] | Output | Data output. When the encoder sends valid data on this bus, it asserts the cw_vld signal. |
cw_mode[11:0] | Output | The lifting
size
of the
transmission
block. The
encoder
drives this bus with the value it receives on the input bus msg_mode for the same information
block. This signal is valid when cw_sop is asserted. |
The 5G LDPC encoder does not support backpressure on the output interface.
5G LDPC Encoder Data Formats
Encoder Input Data Format
The 5G LDPC Encoder IP incoming data on a 384-bit bus (msg). The IP clocks in data with K b clocks, where K b = 22 for BG1 and K b = 6, 8, 9, or 10 for BG2. The IP accepts mode information on the clock with msg_sop and msg_vld both asserted.
The width of the input message bus, msg[383:0], is 384 bits. In each clock cycle, only Z LSBs. are valid, you must set the rest of the MSBs to zeros.
msg[383:0] | clock cycle | ||||
---|---|---|---|---|---|
0 | 1 | ... | 20 | 21 | |
msg[0] | M0 | M64 | ... | M1280 | M1344 |
msg[1] | M1 | M65 | ... | M1281 | M1345 |
... | ... | ... | ... | ... | ... |
msg[63] | M63 | M127 | ... | M1343 | M1407 |
msg[64] | 0 | 0 | ... | 0 | 0 |
... | ... | ... | ... | ... | ... |
msg[383] | 0 | 0 | 0 | 0 | 0 |
Encoder Input Control Formats (msg_mode[11:0])
msg_mode[5:0] | Z | msg_mode[5:0] | Z |
---|---|---|---|
0 | 2 | 26 | 48 |
1 | 3 | 27 | 52 |
2 | 4 | 28 | 56 |
3 | 5 | 29 | 60 |
4 | 6 | 30 | 64 |
5 | 7 | 31 | 72 |
6 | 8 | 32 | 80 |
7 | 9 | 33 | 88 |
8 | 10 | 34 | 96 |
9 | 11 | 35 | 104 |
10 | 12 | 36 | 112 |
11 | 13 | 37 | 120 |
12 | 14 | 38 | 128 |
13 | 15 | 39 | 144 |
14 | 16 | 40 | 160 |
15 | 18 | 41 | 176 |
16 | 20 | 42 | 192 |
17 | 22 | 43 | 208 |
18 | 24 | 44 | 224 |
19 | 26 | 45 | 240 |
20 | 28 | 46 | 256 |
21 | 30 | 47 | 288 |
22 | 32 | 48 | 320 |
23 | 36 | 49 | 352 |
24 | 40 | 50 | 384 |
25 | 44 | X | X |
Code Rate |
Base Graph 1 Kb = 22 msg_mode [11:9]=000 |
Base Graph 2 Kb = 6 msg_mode [11:9]=001 |
Base Graph 2 Kb = 8 msg_mode [11:9]=011 |
Base Graph 2 Kb = 9 msg_mode [11:9]=101 |
Base Graph 2 Kb = 10 msg_mode [11:9]=111 |
---|---|---|---|---|---|
1/5 msg_mode[8:6]=000 |
X | 001000 | 011000 | 101000 | 111000 |
1/3 msg_mode[8:6]=001 |
000001 | 001001 | 011001 | 101001 | 111001 |
2/5 msg_mode[8:6]=010 |
000010 | 001010 | 011010 | 101010 | 111010 |
1/2 msg_mode[8:6]=011 |
000011 | 001011 | 011011 | 101011 | 111011 |
2/3 msg_mode[8:6]=100 |
000100 | 001100 | 011100 | 101100 | 111100 |
22/30 (~3/4) msg_mode[8:6]=101 |
000101 | X | X | X | X |
22/27 (~5/6) msg_mode[8:6]=110 |
000110 | X | X | X | X |
22/25 (~8/9) msg_mode[8:6]=111 |
000111 | X | X | X | X |
Encoder Output Data Format
The width of the output codeword bus, cw[383:0], is 384 bits. It takes (nb - 2) clock cycles to output the codeword. Each clock cycle, only Z LSBs are valid, the rest of the MSBs are 0s.
cw[383:0] | clock cycle | ||||
---|---|---|---|---|---|
0 | 1 | ... | 64 | 65 | |
cw[0] | CW0 | CW64 | ... | CW4096 | CW4160 |
cw[1] | CW1 | CW65 | ... | CW4097 | CW4161 |
... | ... | ... | ... | ... | ... |
cw[63] | CW63 | CW127 | ... | CW4159 | CW4223 |
cw[64] | 0 | 0 | ... | 0 | 0 |
... | ... | ... | ... | ... | ... |
cw[383] | 0 | 0 | 0 | 0 | 0 |
Avalon-ST Interfaces in DSP IP Cores
The input interface is an Avalon-ST sink and the output interface is an Avalon-ST source. The Avalon-ST interface supports packet transfers with packets interleaved across multiple channels.
Avalon-ST interface signals can describe traditional streaming interfaces supporting a single stream of data without knowledge of channels or packet boundaries. Such interfaces typically contain data, ready, and valid signals. Avalon-ST interfaces can also support more complex protocols for burst and packet transfers with packets interleaved across multiple channels. The Avalon-ST interface inherently synchronizes multichannel designs, which allows you to achieve efficient, time-multiplexed implementations without having to implement complex control logic.
Avalon-ST interfaces support backpressure, which is a flow control mechanism where a sink can signal to a source to stop sending data. The sink typically uses backpressure to stop the flow of data when its FIFO buffers are full or when it has congestion on its output.
Parameter Optimization for the 5G LDPC IP
For throughput vs BLER performance, you can limit the maximum number of iterations that the LDPC decoder uses before giving up on decoding the block. BLER improves with increasing the maximum number of iterations. However, you can potentially reduce the throughput if you raise this number too high. At some point, it is better to give up and request retransmission of a packet or to have the network reassign your LDPC parameters for the shared data channel. You can use the C++ or MATLAB software models, to perform this assessment and to determine which set of parameters suits the network best.



The vertical axis in both figures shows the block rate on the linear scale from 0 (no errors; that BLER is not theoretically attainable) to 1 (the error rate is 100%; the decoder fails to decode every dataword transmitted). The horizontal axis is in logarithmic units (dB) of the ratio between the power of the normalized modulated carrier and the effective power of the additive Gaussian noise in the channel, i.e. its variance.
A transmitted codeword can morph into another valid one, if it is sampled from a noisy channel and translated to LLR values. The LDPC decoder might assert source_et_pass and even close before it reaches the maximum number of iterations indicating a successful operation in those cases. However, the decoded dataword does not match the original transmission block. These occurrences are expected. The network should cure such situations by changing the LDPC parameters it is currently using to a set of more robust ones and using the hybrid automatic repeat request (HARQ) mechanism.
C++ and MATLAB Software Models
The models allow you to:
- Optimize the network performance.
- Shorten the time to determine the channel coding parameters for 5G LDPC such as the base graph, the lifting size, and the code rate.
- Tune the network for better throughput by allowing estimation of the maximum number of iterations needed to decode the majority of codewords under certain channel conditions.
Decoder C++ Model
The file is: LdpcDecoder_fxp.cpp.
Function signature:
int LdpcDecoder_fxp ( // Outputs vector<int> &BitErrors, // comparison result of input: data vs output: DecodedBits vector<int> &DecodedBits, // decoded bits int &DecodedIters, // number of iterations used to decoded int &et_pass, // 1: decode success; 0: decode fail // Inputs vector<int> &input, // LLRs int ExpFactor, // Z (lifting factor): 2,3,4,5,...,320,352,384 int max_iter, // number of iterations allowed vector<int> &data, // expected data, to be used to compare with DecodedBits int BaseGraph, // 0: BG#1, 1: BG#2 int CodeRate, // BG#1: 1: 1/3, 2: 2/5, 3: 1/2, 4: 2/3, 5: 3/4, 6: 5/6, 7: 8/9 // BG#2: 0: 1/5, 1: 1/3, 2: 2/5, 3: 1/2, 4: 2/3 int in_width = 6, // bit width of input LLRs (2 of that are fractional bits) int llr_eq_0_as_negative = 0 // 1: treat LLR == 0 as negative-signed // 0: treat LLR == 0 as positive-signed );
-
BitErrors
- size = max_iter
- each element is the number of error comparing input data vs output DecodedBits after each iteration, e.g. BitErrors[1] is the number of errors after iteration 1
-
DecodedBits
- size = max_iter * message length
- DecodedBits[iter + i * max_iter] is the decoded bits after iteration iter at bit position i, e.g. DecodedBits[DecodedIters + i * max_iter] is the final decoded bits at bit position i
Encoder C++ Model
The file is: LdpcEncoder.c
Function signature:
void LdpcEncoder ( // Inputs int z, // Lifting factor: 2,3,4,5,...,320,352,384 int base_graph, // 0: BG#1, 1: BG#2 int code_rate, // BG#1: 1: 1/3, 2: 2/5, 3: 1/2, 4: 2/3, 5: 3/4, 6: 5/6, 7: 8/9 // BG#2: 0: 1/5, 1: 1/3, 2: 2/5, 3: 1/2, 4: 2/3 int kb, // BG#1: 22, BG#2: 10, 9, 8, 6 int *msg, // msg array, each element is a symbol (0 or 1) in message // Outputs int *cw,// codeword array, each element is a symbol (0 or 1) in codeword int *cw_size // no. of valid elements in cw_int[] );
Running the 5G LDPC IP C++ Models
-
For the decoder, run:
prompt> g++ LdpcDecoder_fxp_cppTB.cpp prompt> ./a.out snr = 1.60 DecodedIters = 7 BitErrors[7] = 0 et_pass = 1
-
For the encoder, run:
prompt> g++ LdpcEncoder_cTB.c prompt> ./a.out <testcase> <testcase> = 0: z = 8; base_graph = 1; // BG#2 code_rate = 0; // 1/5 kb = 6; break; <testcase> = 1: z = 36; base_graph = 1; // BG#2 code_rate = 2; // 2/5 kb = 8; break; <testcase> = 2: z = 104; base_graph = 0; // BG#1 code_rate = 7; // 8/9 kb = 22; break; <testcase> = 3: z = 384; base_graph = 0; // BG#1 code_rate = 1; // 1/3 kb = 22; Prompt e.g. ./a.out 0, then you see: prompt> tc=0 prompt> output file: cw.z=8.bg=1.cr=0.kb=6.txt prompt> diff ./cw.z=8.bg=1.cr=0.kb=6.txt ./txt
Running the 5G LDPC Decoder and Encoder MATLAB Model in the Design Example
- Change working directory in MATLAB to <desgin example root>/matlab
- Run MATLAB command mex -setup to point to the C++ compiler of choice.
-
Run
script make: >> make
Note: Tested on gcc/7.2.0 and matlab/2017a.
- Run an example of encoder output feeds to decoder input: >> LDPC_example
Document Revision History for the 5G LDPC Intel FPGA IP User Guide
Date | Version | Changes |
---|---|---|
2018.12.21 | 18.1 | Initial release. |