Throughput and Latency for Soft-Decision FEC v1.1

Vivado Design Suite Release 2024.1

Table of Contents

• LDPC Throughput and Latency
• 5G New Radio - Decode
• 5G New Radio - Encode
• WiFi 802.11ac - Decode
• WiFi 802.11ac - Encode
• DOCSIS 3.1 - Decode
• DOCSIS 3.1 - Encode
• Turbo Decode Throughput

LDPC Throughput and Latency

Throughput is measured in terms of information bits per second, including any punctured bits. In the following sections, the throughput has been measured by inputting the data as quickly as possible. The tables provide the time of the start and end of the first input block and the start and end of the output data of the first, 84^th, 96^th and 100^th blocks, relative to the start of the first block that was input. Initial Latency is the time between the last transfer of the first input block and the last output of the first output block. The assumption here is that the LDPC code parameters and shared LDPC code parameters in the SD-FEC hard block are already configured for the particular code. Final throughput is the throughput from blocks 84 to 96. Note that the number 12 has been used, as this is a multiple of 1, 2, 3 and 4, which is the number of blocks that can be decoded simultaneously. The assumptions are that the output is not held up and that the decoder measurement is performed with hard output that does not include parity.

Note that the latency of later blocks is likely to be greater than the initial latency due to input buffering holding additional blocks, and can often be reduced by feeding in the blocks at a steady rate, commensurate with the throughput, to avoid them building up in the input buffer. It is also possible, for some codes, to have a reduced latency with a small reduction in throughput, because of the way the core schedules multiple blocks, and lower throughput can mean fewer blocks interleaved and lower latency as a result.

In the following tables, clock frequencies of 667 MHz on core_clk and 400 MHz on other clocks are assumed, and the decoder uses eight iterations. However, for details on the clock frequency supported by a device and resource utilization, visit the Performance and Resource Utilization web page. Packing is assumed to be enabled; if disabled, then for codes with PSIZE ≤ 64 there is likely to be a significant throughput reduction.

5G New Radio - Decode

5G New Radio - Encode

In 5G NR mode, the 5G support logic generates and downloads LDPC Code and Shared LDPC Code Parameters for the code definition applied through the CTRL interface. The download latency in each case is provided in the table below. For throughput enhancement, write the code definitions through the CTRL interface as early as possible compared to the input data to minimize the impact of code latency and enhance throughput. However, care must be taken not to apply more CTRL words than the corresponding code blocks in a given transmission time interval.

The 5G support logic also keeps log of, at most, 14 codes downloaded to the SD-FEC core at any given time to avoid the need to regenerate and re-download the same code.

WiFi 802.11ac - Decode

WiFi 802.11ac - Encode

DOCSIS 3.1 - Decode

DOCSIS 3.1 - Encode

Turbo Decode Throughput

The figure below illustrates the maximum achievable Turbo Decode throughput for a given block size.

COPYRIGHT

Copyright 2024 Xilinx, Inc. Xilinx, the Xilinx logo, Alveo, Artix, ISE, Kintex, Spartan, Versal, Virtex, Vivado, Zynq, and other designated brands included herein are trademarks of Xilinx in the United States and other countries. Arm is a registered trademark of Arm Limited in the EU and other countries. All other trademarks are the property of their respective owners.

LEGAL INFORMATION: PLEASE READ

The information disclosed to you hereunder (the "Materials") is provided solely for the selection and use of Xilinx products. To the maximum extent permitted by applicable law: (1) Materials are made available "AS IS" and with all faults, Xilinx hereby DISCLAIMS ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether in contract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to, arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect, special, incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of the possibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of updates to the Materials or to product specifications. You may not reproduce, modify, distribute, or publicly display the Materials without prior written consent. Certain products are subject to the terms and conditions of Xilinx's limited warranty, please refer to Xilinx's Terms of Sale which can be viewed at https://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms contained in a license issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe performance; you assume sole risk and liability for use of Xilinx products in such critical applications, please refer to Xilinx's Terms of Sale which can be viewed at https://www.xilinx.com/legal.htm#tos.