A GPU parallel implementation method for multi-frame multi-code rate LDPC decoding

Abstract

The application provides a GPU parallel implementation method for multi-frame multi-code rate LDPC decoding, and belongs to the technical field of satellite communication channel coding. The method comprises the following steps: obtaining check matrix compression parameters and frame offset parameters by processing a check matrix in a CPU according to input LLR information and code rate information of multi-frame LDPC codes in signaling frame information; allocating memory in the CPU and the GPU, and respectively storing log-likelihood ratio information LLR transmitted by a front end and initializing check parameter transmission nodes C2V, variable parameter transmission nodes V2C, variable node log-likelihood ratio LOV and decoding results Out_Dec; dynamically adjusting the check matrix compression parameters according to the frame offset parameters, and updating nodes in the GPU through kernel functions by using the check parameter transmission nodes C2V, the variable parameter transmission nodes V2C and the variable node log-likelihood ratio LOV; and copying the decoding results back to the Host end. The application eliminates memory access conflicts caused by dynamic code rates by preprocessing input LLR data and analyzing multi-frame check matrix parameters, so that the utilization rate of GPU computing cores is improved.

Description

Technical Field

[0001] This invention belongs to the field of satellite communication channel coding technology, and particularly relates to a GPU parallel implementation method for multi-frame, multi-rate LDPC decoding. It is suitable for parallel processing of multi-frame, multi-rate data transmission in high-speed satellite-to-ground scenarios. By constructing a rate-adaptive GPU-CPU collaborative computing architecture, it achieves joint optimization of dynamic mapping of parity-check matrix parameters, elastic allocation of thread resources, and early termination of the iteration process, effectively improving the throughput performance of multi-beam satellite terminals. Background Technology

[0002] As a core enabling technology for building global information infrastructure, satellite communication has seen its technical standards competition escalate to the level of international discourse power. Due to the inherent characteristics of satellite communication—long links and high latency—coupled with the exponential growth in demand for high-speed broadband, these challenges necessitate superior channel coding schemes to meet real-time and high-throughput requirements. Low-density parity-check (LDPC) codes, with their superior performance approaching the Shannon limit, have become a key technology for improving the spectral efficiency of satellite links and have been adopted as the core channel coding scheme for the DVB-S2X (Digital Video Broadcasting Satellite second generation Extension) standard. Graphics Processing Units (GPUs), with their efficient parallel computing capabilities, can accelerate and optimize computationally intensive tasks such as LDPC decoding, significantly improving adaptive decoding efficiency in highly dynamic channel environments.

[0003] The DVB-S2X system supports real-time switching of up to 112 modulation and coding formats (MODCOD) in ACM mode. This places core technical requirements on the channel decoder to dynamically adapt to multiple code rates (64800 / 16200) and multiple modulation orders (QPSK to 256APSK). Existing GPU acceleration solutions suffer from resource fragmentation and low utilization of computing cores in ACM mode due to dynamic changes in frame structure. Summary of the Invention

[0004] The purpose of this invention is to provide a GPU parallel implementation method for multi-frame, multi-rate LDPC decoding, which improves adaptive decoding efficiency by optimizing the GPU parallel computing resource scheduling mechanism. This addresses the technical problem in existing technologies where LDPC decoding (such as the backpropagation (BP) algorithm) requires a large number of iterative calculations, while the high data rates and real-time requirements of satellite communication make it difficult for traditional algorithms to complete the decoding task within a limited time.

[0005] To solve the above-mentioned technical problems, the specific technical solution of the present invention is as follows:

[0006] A GPU parallel implementation method for multi-frame, multi-rate LDPC decoding, the method comprising the following steps:

[0007] Step S1: Based on the hardware parameters and the signaling frame information input from the front end, calculate the longest number of LDPC decoding frames that can be processed in parallel in the processor and the GPU running parameters.

[0008] Step S2: Based on the LLR information and the code rate information of the multi-frame LDPC codes in the signaling frame information input from the front end, the CPU processes the parity check matrix to obtain the parity check matrix compression parameters and frame offset parameters.

[0009] Step S3: Allocate the parity-check matrix compression parameters and frame offset parameters to the GPU's constant memory space, and initialize the constant memory space;

[0010] Step S4: Allocate memory on the CPU side to store the log-likelihood ratio information LLR transmitted from the front end and initialize the verification parameter transmission node C2V, variable parameter transmission node V2C, variable node log-likelihood ratio LOV, and decoding result Out_Dec;

[0011] Step S5: Allocate global memory space via GPU for the log-likelihood ratio information LLR, the verification parameter passing node C2V, the variable parameter passing node V2C, the variable node log-likelihood ratio LOV, and the decoding result Out_Dec;

[0012] Step S6: Configure GPU thread blocks based on the calculated GPU running parameters;

[0013] Step S7: Dynamically adjust the parity matrix compression parameters according to the frame offset parameters, and pass the initialized parity parameters to node C2V, the variable parameters to node V2C, and the variable node log-likelihood ratio (LOV) to update the nodes in the GPU through kernel functions;

[0014] Step S8: Synchronize on the GPU, make hard decisions on the codewords, and verify the check equation. If the equation is satisfied, end the iteration early; otherwise, continue iterating until the number of iterations reaches the set upper limit.

[0015] Step S9: Copy the decoding result back to the Host via asynchronous transmission, and calculate the error rate and decoding delay statistics of LDPC decoding;

[0016] Step S10: Release resources for the CPU and the GPU.

[0017] Furthermore, the longest frame number and thread block number of LDPC decoding in step S1 are calculated as follows:

[0018] Step S101: Calculate the number of threads required per frame. The number of threads required per frame is calculated as follows:

[0019]

[0020] in, Indicates the number of threads required for the i-th frame, blockLens i With parityLens i represents the number of variable nodes and the number of verification nodes in the i-th frame, respectively, and max represents taking the maximum value.

[0021] Step S102: Convert the number of threads per frame to the number of thread blocks, using the following method:

[0022]

[0023] in, This represents the number of thread blocks required for the i-th frame, where ceil represents rounding up, and B... size This indicates the number of threads in each thread block.

[0024] Step S103: The longest frame count satisfies the thread block resource usage limit of the SM. The formula for the thread block resource usage limit of the SM is as follows:

[0025]

[0026] Where S represents the number of SMs, B SM This indicates the maximum number of active thread blocks per SM;

[0027] Step S104: The longest frame count meets the thread resource usage limit of SM. The formula for the thread resource usage limit of SM is as follows:

[0028]

[0029] Among them, t SM This indicates the maximum number of threads per SM;

[0030] Step S105: Based on the thread block resource usage limit of SM and the thread resource usage limit of SM, obtain the longest frame number K.

[0031] Step S105: Calculate the number of thread blocks B based on the longest frame number K. num The calculation method is as follows:

[0032]

[0033] Number of threads per thread block B size and thread block count B num The parameters that make up the GPU's operating parameters.

[0034] Furthermore, in step S2,

[0035] Processing the parity check matrix to obtain parity check matrix compression parameters refers to replacing the original parity check matrix with the node positions represented by the parity check matrix compression parameters, thereby achieving compression. The matrix compression process is the process of calculating the parity check matrix compression parameters. The parity check matrix compression parameters include matrix row offset, row weight, column offset, column weight, column index, and index mapping table.

[0036] The row offset is the starting position of the non-zero element in each row of the parity check matrix in row-order compressed storage within the column index array; the row weight is the number of non-zero elements in each row of the parity check matrix in row-order compressed storage; the column offset is the starting position of the non-zero element in each column of the parity check matrix in column-order compressed storage within the index mapping table; the column weight is the number of non-zero elements in each column of the parity check matrix in column-order compressed storage; the column index represents the column coordinates of all non-zero elements stored in row-order; the index mapping table is a mapping that replaces the edge information stored in row-order compressed storage with angles stored in column-order compressed storage to access the same edge.

[0037] The frame offset parameter refers to the parity check matrix compression parameter for different frames when multiple frames are input simultaneously. The offset is determined by the frame offset parameter to ensure that the corresponding parity check matrix compression parameter is used for different frames during calculation.

[0038] Further, step S7 includes the following steps:

[0039] Step S71: Update the information passed from the check node to the variable node. Obtain the row offset, row weight and index mapping table of the current frame through the compressed check matrix information adjusted based on the frame offset parameter. Combine the information passed from the check node to the variable node collected by the current variable node to calculate the message passed from the check node to each variable node. The update process is executed in parallel row by row. For the check node information update of multiple frames with different bit rate signals, only the information function passed from the check node to the variable node needs to be called once.

[0040] Step S72: Update the information passed from the variable node to the check node. Obtain the column offset, column weight, column index and index mapping table of the current frame through the information in the compression matrix adjusted based on the frame offset parameter. Combine the LLR value of the current variable node and the message received from the check node to calculate the message passed from the variable node to each check node. The update process is executed in parallel column by column. For the information update of variable nodes of multiple frames with different bit rates, only the information function passed from the variable node to the check node needs to be called once.

[0041] Step S73: Update the log-likelihood ratio information of the variable node. Obtain the column offset and column weight of the current frame through the information in the compression matrix adjusted based on the frame offset parameter, and calculate the final LLR value of the variable node by combining the initial information of the current variable node and the messages received from all connected check nodes. The update process is executed in parallel column by column, and the LLR information update of the variable node for multiple frames of signals with different bit rates only needs to call the variable node information function once.

[0042] Further, in step S71, the information function passed from the verification node to the variable node, i.e., the information update formula from verification node i to variable node j, is:

[0043]

[0044] Where L(·) represents the log-likelihood ratio calculated for the elements within the parentheses; λ i→j This represents the information passed from check node i to variable node j; N(i)\j represents the set of all variable nodes connected to check node i except variable node j; j′ represents a variable node in the set of all variable nodes connected to check node i except variable node j; v j′→i This represents the information passed from variable node j′, which is one of the set of all variable nodes (excluding variable node j) connected to check node i, to check node i.

[0045] Further, in step S72, the information function corresponding to the variable node passing the information to the verification node, that is, the information update formula from variable node j to verification node i, is:

[0046] L(v j→i )=L(S j )+∑ i′∈M(j)\i L(λ i′→j )

[0047] Among them, v j→i This represents the information passed from variable node j to check node i; S j λ represents the initial information of variable node j in the current iteration number; M(j)\i represents the set of all check nodes connected to variable node j except check node i; i′ represents a check node in the set of all check nodes connected to variable node j except check node i; λ i′→j This represents the information passed to variable node j by one of the check nodes in the set of all check nodes (excluding check node i) connected to variable node j.

[0048] Furthermore, in step S73, the information function of the variable node, i.e., the LLR decision information update formula of the variable node, is:

[0049] L(v j)=L(S j )+∑ i∈M(j) L(λ i→j )

[0050] Among them, v j This represents the final information of variable node j at the current iteration number; S j M(j) represents the initial information of variable node j in the current iteration number; M(j) represents the set of all verification nodes connected to variable node j.

[0051] Furthermore, in step S8, the formula for hard word decision is:

[0052] D j =sgn(L(v j ))

[0053] The formula for verifying the equation is:

[0054] H*D j =0

[0055] Where H represents the parity check matrix.

[0056] Compared with the prior art, the present invention has the following beneficial technical effects:

[0057] 1) This invention makes full use of the GPU's computing core utilization. By preprocessing to obtain information such as the parity check matrix parameters and frame length of multiple frames of data, the GPU thread block is set by calling different parameter matrix data in the decoding stage, the intra-frame parallelism is set, and the parallel decoding of multiple frames of LDPC data is completed by combining decoding algorithms such as LLR-BP.

[0058] 2) This invention preprocesses the input LLR data, parses the multi-frame parity matrix parameters, eliminates memory access conflicts caused by dynamic bitrate, and improves the utilization of GPU computing cores.

[0059] 3) This invention utilizes an elastic thread allocation mechanism to obtain multi-frame LDPC decoding results, further improving the communication rate in satellite communication ACM mode. Attached Figure Description

[0060] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0061] Figure 1 This is a schematic diagram of the structure of a Tanner graph that converts the LDPC code parity check matrix into bidirectional bipartite graph features.

[0062] Figure 2 This is a flowchart illustrating the multi-frame, multi-rate decoding method for LDPC code parallel GPUs according to the present invention.

[0063] Figure 3 This is a schematic diagram of the architecture of the LDPC code parallel GPU multi-frame multi-rate decoding method of the present invention. Detailed Implementation

[0064] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0065] LDPC (Low Density Parity Check code), a linear block code with a sparse parity-check matrix, plays a crucial role in error correction during data transmission and is one of the core technologies for ensuring communication reliability. The parity-check matrix parameters, as key information within the LDPC code's parity-check matrix, clearly define the complex relationships between data bits and parity bits in the codeword, encompassing critical details such as the precise positions of non-zero elements in the matrix. These parity-check matrix parameters provide indispensable foundational support for subsequent decoding operations.

[0066] LDPC codes can be uniquely determined by a parity-check matrix. The number of non-zero elements in each row of the parity-check matrix is ​​the row weight, and the number of non-zero elements in each column is the column weight. Let's take an LDPC code parity-check matrix H... 6×12 Taking the parity check matrix as an example, the LDPC code parity check matrix H... 6×12 It is expressed as follows:

[0067]

[0068] The above LDPC code check matrix H 6×12 The row weight is 6, the column weight is 3, and the bit rate is 0.5.

[0069] To better illustrate the relationship between variable nodes and check nodes in the parity-check matrix, and to more intuitively describe the LDPC decoding process, the above LDPC code parity-check matrix H is used. 6×12 Represented as a Tanner graph with bidirectional bipartite graph characteristics, such as Figure 1As shown, in the Tanner graph, vertices are called nodes. In the LDPC code parity-check matrix, columns correspond to variable nodes, rows correspond to parity nodes, the number of rows corresponds to the number of parity nodes, and the number of columns corresponds to the number of variable nodes. Edges describe the positions of non-zero elements in the parity-check matrix; the parity nodes and variable nodes they connect correspond to the positions of non-zero elements in the parity-check matrix. The number of edges connected to each node is the degree. Figure 1 In this matrix, s1 represents the first row of the parity check matrix, e1 represents the first column of the variable node, and there are a total of 6 parity check nodes and 12 variable nodes. The degree of each parity check node is 6, and the degree of each variable node is 3.

[0070] In practical DVB-S2X communication scenarios, the signals received by the receiver typically contain LDPC codes with multiple code rates. These codes have higher matrix dimensions and more check nodes and variable nodes than the aforementioned parity-check matrices, making their parity-check matrices and corresponding Tanner diagrams more complex. For example, in actual DVB-S2X communication environments, LDPC code rates include, but are not limited to, those shown in Table 1:

[0071] Table 1. LDPC Code Rate Table in Actual DVB-S2X Communication Environment

[0072]

[0073]

[0074] This invention innovatively presents a GPU-parallel implementation method for multi-frame, multi-rate LDPC decoding, applied to satellite receivers. Given the unique characteristics of multi-frame, multi-rate LDPC decoding, the processing flow of this parallel GPU decoding method is as follows: Figure 2 As shown, the process includes the following steps:

[0075] Step S1: Based on the hardware parameters and the signaling frame information input from the front end, calculate the longest number of LDPC decoding frames that can be processed in parallel in the processor and the GPU operating parameters.

[0076] The hardware parameters include: the number of SMs (Streaming Multiprocessors) S, and the maximum number of threads per SM T. SM Maximum number of active thread blocks per SM (B) SM The longest frame count K represents the maximum number of frames that can be computed with existing computing resources. GPU runtime parameters include the number of threads per thread block, B. size and thread block count B num In this invention, the number of threads in each thread block is B. size Fixed at 1024.

[0077] The signaling frame information includes the LDPC code rate information and frame length information of the data frame. The number of threads required for LDPC decoding of each frame is calculated from the number of check nodes and the number of variable nodes.

[0078] The longest frame count and thread block count for LDPC decoding are calculated as follows:

[0079] Step S101: Calculate the number of threads required per frame. The number of threads required per frame is calculated as follows:

[0080]

[0081] in, Indicates the number of threads required for the i-th frame, blockLens i With parityLens i represents the number of variable nodes and the number of verification nodes in the i-th frame, respectively, and max represents taking the maximum value.

[0082] Step S102: Convert the number of threads per frame to the number of thread blocks, using the following method:

[0083]

[0084] in, This represents the number of thread blocks required for the i-th frame, and ceil indicates rounding up.

[0085] Step S103: The longest frame count satisfies the thread block resource usage limit of the SM. The formula for the thread block resource usage limit of the SM is as follows:

[0086]

[0087] Step S104: The longest frame count meets the thread resource usage limit of SM. The formula for the thread resource usage limit of SM is as follows:

[0088]

[0089] Step S105: Based on the thread block resource usage limit of SM and the thread resource usage limit of SM, obtain the longest frame number K.

[0090] Step S105: Calculate the number of thread blocks B based on the longest frame number K. num The calculation method is as follows:

[0091]

[0092] Step S2: Based on the LLR (Log-Likelihood Ratio) information input from the front end and the code rate information of the multi-frame LDPC codes in the signaling frame information, the CPU (host side) processes the parity check matrix to obtain the parity check matrix compression parameters and frame offset parameters.

[0093] The LLR information, or Log-Likelihood Ratio (LLR) data, reflects the probability that each bit in the received signal is 0 or 1, and is a crucial raw input for the decoding algorithm. The "multiple frames" in the multi-frame LDPC code imply simultaneous processing of multiple data frames, improving data processing efficiency. The LDPC code is a low-density parity-check code used for error correction during data transmission. The signaling frame information includes the code rate information of the multi-frame LDPC code, which refers to the ratio of information bits to codeword length in the LDPC code. Different code rates correspond to different coding redundancy and error correction capabilities. The CPU processing of the parity-check matrix represents the use of the central processing unit to perform matrix compression operations on the parity-check matrix of the LDPC code. The parity-check matrix is ​​a key mathematical description of the LDPC code, defining the parity-check relationship between each bit in the codeword. Since the parity-check matrix of DVB's LDPC code is large and sparse, compression can be achieved by replacing the original parity-check matrix with only the node positions (i.e., "1"s) using multiple parity-check matrix compression parameters. The matrix compression process involves calculating the parity-check matrix compression parameters (matrix row offset, row weight, column offset, column weight, column index, and index mapping table). The parity-check matrix encompasses key information such as its dimension and the positions of non-zero elements. Since LDPC decoding requires the joint implementation of the CPU and GPU, with the CPU acting as the host and the GPU as the device, the parity-check matrix compression parameters describe the parity-check matrix as multiple parameter information by compression by row or column. These parameters include matrix row offset, row weight, column offset, column weight, column index, and index mapping table.

[0094] The row offset is the starting position of the non-zero element in each row (check node) of the parity check matrix in row-order compressed storage within the column index array. The row weight is the number of non-zero elements in each row of the parity check matrix in row-order compressed storage, i.e., the number of variable nodes connected to each row (i.e., each check node). Using the row offset and row weight, the positions of all non-zero elements corresponding to that row in the column index array can be quickly located. Similarly, the column offset is the starting position of the non-zero element in each column (variable node) of the parity check matrix in column-order compressed storage within the index mapping table. The column weight is the number of non-zero elements in each column of the parity check matrix in column-order compressed storage, i.e., the number of check nodes connected to each column (i.e., each variable node). Using the column offset and column weight, the positions of all non-zero elements corresponding to that column in the column index array can be quickly located. The column index represents the column coordinates of all non-zero elements stored in row-order, indicating the specific variable node connected to each row. The index mapping table is a mapping that replaces the row-order compressed storage (i.e., check node-based) of edge information with column-order compressed storage (variable node-based) to access the same edge. During the decoding process, it is necessary to access the message on the same edge from two different orders (by check node order and by variable node order). The index mapping table can quickly find the position of the same edge in the data structure organized by variable nodes.

[0095] The frame offset parameter refers to the offset of the parity check matrix compression parameters for different frames when multiple frames are input simultaneously. This parameter determines the offset to ensure that different frames use the corresponding parity check matrix compression parameters during calculation. These parameters are important bases for subsequent decoding operations.

[0096] In one possible implementation, the frame offset parameters include multi-frame row offset, multi-frame row weight offset, multi-frame column offset, multi-frame column weight offset, multi-frame column index offset, and multi-frame index mapping table offset.

[0097] The multi-frame row offset refers to a vector of row offset lengths in different frames; the multi-frame row weight offset refers to a vector of row weight offset lengths in different frames; the multi-frame column offset refers to a vector of column offset lengths in different frames; the multi-frame column weight offset refers to a vector of column weight offset lengths in different frames; the multi-frame column index offset refers to a vector of column index offset lengths in different frames; and the multi-frame index mapping table offset refers to a vector of index mapping table lengths.

[0098] Step S3: Allocate the parity matrix compression parameters and frame offset parameters to the GPU's constant memory space, and initialize the constant memory space.

[0099] The constant memory space of the GPU is a specific storage area within the GPU, specially optimized for storing data that remains unchanged during computation. Allocating the parity matrix compression parameters to the GPU's constant memory space leverages its unique properties to improve data retrieval efficiency. Initializing the constant memory space refers to setting the parameters for this memory area to ensure that the internal data is in a standard state that can be accessed by the GPU, eliminating potential interference factors.

[0100] It's important to note that allocating the parity-check matrix compression parameters to the GPU's constant memory space fully leverages its high-speed cache capabilities, allowing the GPU to quickly read data during decoding operations and significantly improving computational efficiency. Furthermore, constant memory is thread-friendly, reducing conflicts when multiple threads access the parity-check matrix compression parameters and enhancing parallel computing performance. Initializing this memory space ensures the integrity and consistency of the parity-check matrix compression parameters in subsequent decoding operations, providing reliable data to the GPU and effectively guaranteeing the stability and accuracy of the entire decoding process, ensuring the decoding result is precise and error-free.

[0101] Step S4: Allocate memory on the CPU side to store the log-likelihood ratio (LLR) information passed from the front end and initialize the verification parameter passing node C2V, variable parameter passing node V2C, variable node log-likelihood ratio (LOV), and decoding result Out_Dec.

[0102] The CPU-side memory allocation refers to allocating a specific storage area at the central processing unit (CPU), the core of computing, to hold critical data transmitted from the front-end system. The verification parameter passing node (C2V) records the relevant data records that the verification node transmits messages to the variable node, assisting the variable node in updating its own state. Conversely, the variable parameter passing node (V2C) is the information carrier that the variable node feeds back messages to the verification node. The variable node's log-likelihood ratio (LOV) represents the log-likelihood ratio of the variable node and plays a crucial role in the decoding iteration. The decoding result Out_Dec is the result of the hard decision after the final node update.

[0103] Specifically, the verification parameter passing node C2V is initialized to the input log-likelihood ratio information LLR, the variable parameter passing node V2C is initialized to a zero matrix with a length equal to that of the variable node, and the variable node log-likelihood ratio LOV is initialized to a zero matrix with the same length as the log-likelihood ratio information LLR.

[0104] It's worth noting that allocating memory and storing LLR information on the CPU facilitates unified management and preliminary processing in the early stages of the decoding process, providing ordered and accurate data preparation for subsequent high-intensity GPU computation. Initializing the C2V (Check Parameter Passing) node, V2C (Variable Parameter Passing) node, and LOV (Log Likelihood Ratio) node significantly improves the iterative efficiency and accuracy of the decoding algorithm. The initialization operation ensures that the C2V, V2C, and LOV nodes meet the logical requirements of the decoding algorithm from the initial state, reducing error accumulation during iteration, accelerating convergence, and enabling faster and more accurate reconstruction of the original data. This enhances the overall performance of the multi-frame, multi-rate LDPC code parallel GPU decoding system.

[0105] Step S5: Allocate global memory space via GPU for the log-likelihood ratio information LLR, the verification parameter passing node C2V, the variable parameter passing node V2C, the variable node log-likelihood ratio LOV, and the decoding result Out_Dec.

[0106] The GPU, as the graphics processing unit, possesses powerful parallel computing capabilities and undertakes critical computational tasks in this decoding process. Global memory space, a type of memory space in the GPU architecture, has a large storage capacity, capable of storing massive amounts of data for access by multiple threads within the GPU when performing complex computational tasks. Allocating information to global memory space aims to provide sufficient storage locations for this data to meet the data storage requirements of the decoding computation.

[0107] Step S6: Configure the GPU thread block based on the calculated GPU running parameters.

[0108] The GPU runtime parameters refer to the parallel parameters set during CUDA runtime, specifically including: number of thread blocks B. num The number of threads in each thread block, B size .

[0109] It should be noted that proper thread block settings can make data access more efficient, because threads within a thread block can access data in the parity matrix sub-blocks in a specific order, thereby optimizing memory access patterns, further accelerating the decoding process, and ensuring that the entire multi-frame, multi-rate LDPC code parallel GPU decoding system can complete the decoding task quickly and accurately.

[0110] Step S7: Dynamically adjust the parity matrix compression parameters according to the frame offset parameters, and pass the initialized parity parameters to node C2V, the variable parameters to node V2C, and the variable node log-likelihood ratio (LOV) to update the nodes in the GPU through kernel functions.

[0111] The dynamic adjustment method involves offsetting the parity-check matrix compression parameters during calculation based on the frame offset parameter corresponding to each frame. This means the parity-check matrix compression parameters for different frames occupy different positions within the input parity-check matrix compression parameters, determined by the frame offset parameter. The kernel function is a parallel-executable function on the GPU, fully utilizing the GPU's parallel computing resources for efficient processing of input data. The kernel function includes the information function passed from the parity node to the variable node in step S71, the information function passed from the variable node to the parity node in step S72, and the information function of the variable node in step S73. The node update refers to using the kernel function to calculate and modify the initialized node information to gradually approximate the correct decoding result.

[0112] It's worth noting that updating the initial parity check parameter passing nodes (C2V), variable parameter passing nodes (V2C), and variable node log-likelihood ratio (LOV) using kernel functions in the GPU can significantly leverage the GPU's parallel computing advantages. Kernel functions can process information from multiple nodes simultaneously, accelerating iterative computation and significantly improving decoding efficiency. Dynamically adjusting the parity check matrix compression information based on the code rate is also crucial. Since the parity check matrix structure differs for LDPC codes at different code rates, dynamically adjusting the parity check matrix compression parameters allows the system to better adapt to different code rates, reducing unnecessary storage and computational resource consumption while ensuring decoding accuracy, thus improving overall system performance. This approach makes multi-frame, multi-code-rate LDPC code parallel GPU decoding systems more flexible and efficient, better able to handle complex and ever-changing communication scenarios.

[0113] Step S71: Update the information passed from the check node to the variable node. Obtain the row offset, row weight and index mapping table of the current frame through the compressed check matrix information adjusted based on the frame offset parameter, and calculate the message passed from the check node to each variable node in combination with the information collected by the current variable node (stored in the variable node information array (Lq array)). The update process is executed in parallel row by row, and for the check node information update of multiple frames with different bit rate signals, only the information function passed from the check node to the variable node needs to be called once.

[0114] Here, the information collected by each variable node refers to the information passed from the verification node to the variable node. Specifically, according to the theory of the LLR-BP algorithm, the information function passed from the verification node to the variable node, that is, the information update formula from verification node i to variable node j, is:

[0115]

[0116] Where L(·) represents the log-likelihood ratio calculated for the elements within the parentheses; λ i→jThis represents the information passed from check node i to variable node j; N(i)\j represents the set of all variable nodes connected to check node i except variable node j; j′ represents a variable node in the set of all variable nodes connected to check node i except variable node j; v j′→i This represents the information passed from variable node j′, which is one of the set of all variable nodes (excluding variable node j) connected to check node i, to check node i.

[0117] Row offset is the starting position of the non-zero element in each row (verification node) of the parity matrix in row-order compressed storage within the column index array. Row weight is the number of non-zero elements in each row of the parity matrix in row-order compressed storage, i.e., the number of variable nodes connected to each row (i.e., each parity node). Using row offset and row weight, the positions of all non-zero elements corresponding to that row in the column index array can be quickly located. The index mapping table is a mapping that replaces the edge information stored in row-order compressed storage (i.e., parity nodes as the primary focus) with the edge information stored in column-order compressed storage (variable nodes as the primary focus) to access the same edge. During decoding, it is necessary to access the messages on the same edge from two different orders (parity node order and variable node order). The index mapping table can quickly find the position of the same edge in the data structure organized by variable nodes.

[0118] The update process first locates the starting position of the current check node in the column index array by row offset, determines the number of variable nodes connected to the node by combining row weight, traverses these variable nodes and transforms their messages to the probability domain using the tanh function for product operation; then, calculates the feedback message of each variable node based on the product result, maps the result to the correct position in the check node information array (Lr array) through the index mapping table, and uses ±36.7 to replace the calculation result when the inverse hyperbolic tangent value = ±1 under double-precision floating-point precision; finally, the message transmission from check node to variable node is completed, providing a basis for subsequent variable node updates.

[0119] Step S72: Update the information passed from the variable node to the check node. Obtain the column offset, column weight, column index and index mapping table of the current frame through the information in the compression matrix adjusted based on the frame offset parameter. Combine the LLR value of the current variable node (stored in the variable node log-likelihood ratio information array (LQ array)) and the message received from the check node (stored in the check node information quantity array (Lr array)) to calculate the message passed from the variable node to each check node. The update process is executed in parallel column by column, and for the variable node information update of multiple frames with different bit rate signals, only the information function passed from the variable node to the check node needs to be called once.

[0120] Wherein, the corresponding information function is passed from the variable node to the verification node, that is, the information update formula from variable node j to verification node i is:

[0121] L(v j→i )=L(S j )+∑ i′∈M(j)\i L(λ i′→j )

[0122] Among them, v j→i This represents the information passed from variable node j to check node i; S j λ represents the initial information of variable node j in the current iteration number; M(j)\i represents the set of all check nodes connected to variable node j except check node i; i′ represents a check node in the set of all check nodes connected to variable node j except check node i; λ i′→j This represents the information passed to variable node j by one of the check nodes in the set of all check nodes (excluding check node i) connected to variable node j.

[0123] Column offset is the starting position of each non-zero element (variable node) in the column-order compressed storage within the index mapping table. Column weight is the number of non-zero elements in each column of the parity check matrix in the column-order compressed storage, i.e., the number of parity check nodes connected to each column (i.e., each variable node). Using column offset and column weight, the positions of all non-zero elements corresponding to a given column in the column index array can be quickly located. Column index represents the column coordinates of all non-zero elements stored in row-order, indicating the specific variable node connected to each row. The index mapping table is a mapping that replaces the row-order compressed storage (i.e., parity check node-centric) edge information with column-order compressed storage (variable node-centric) for accessing the same edge.

[0124] The update process is as follows: First, the starting position of the current variable node in the check node information array (Lr array) is located by column offset. The number of check nodes connected to this node is determined by combining the column weight. These check nodes are traversed and accumulated with the initial information of variable node j under the current iteration number to obtain the updated variable node LLR value (which can be understood as temp value). Then, the variable nodes connected to each check node are located by column offset and column index. When calculating the message passed from the variable node to the check node, the message previously passed by the corresponding check node is subtracted from the current variable node's LLR value to ensure message independence. Finally, the result is stored in the variable node information array (Lq array) to complete the message passing from the variable node to the check node.

[0125] Step S73: Update the log-likelihood ratio information of the variable node. Obtain the column offset and column weight of the current frame through the information in the compression matrix adjusted based on the frame offset parameter, and combine the initial information of the current variable node and the messages received from all connected check nodes (stored in the Lr array) to calculate the final LLR value of the variable node (stored in the LQ array). The update process is executed in parallel column by column, and the LLR information update of the variable node for multiple frames of signals with different bit rates only needs to call the variable node information function once.

[0126] Specifically, the information function of the variable node, i.e., the update formula for the LLR decision information of the variable node, is as follows:

[0127] L(v j )=L(S j )+∑ i∈M(j) L(λ i→j )

[0128] Among them, v j This represents the final information of variable node j at the current iteration number; S j M(j) represents the initial information of variable node j in the current iteration number; M(j) represents the set of all verification nodes connected to variable node j.

[0129] "LLR" is the log-likelihood ratio information, which carries the soft information of the channel output and connects the physical layer received signal with the digital decoding.

[0130] The update process first involves traversing each variable node, using column offsets to locate its starting position in the Lr array, and combining this with column weights to determine the number of check nodes connected to that node. Then, these check nodes are traversed, and the received information from the check nodes connected to the corresponding positions is accumulated into the log-likelihood ratio information to obtain the updated LLR value of the variable node. This process efficiently locates the positions of non-zero elements in the sparse matrix through column offsets and column weights, avoiding traversing all zero elements and significantly reducing computational complexity. Finally, the LLR values ​​of all variable nodes are updated, providing a basis for subsequent check node processing.

[0131] Step S8: Synchronize on the GPU (Device), make hard decisions on the codewords, and verify the check equation. If the equation is satisfied, end the iteration early; otherwise, continue iterating until the number of iterations reaches the set upper limit.

[0132] Specifically, the formula for hard-word judgment is:

[0133] D j =sgn(L(v j ))

[0134] Among them, D jsgn represents the hard decision result of the codeword; sgn represents the sign function.

[0135] Specifically, the formula for verifying the equation is:

[0136] H*D j =0

[0137] Where H represents the parity check matrix.

[0138] It should be noted that steps S71-S73 are based on the LLR-BP algorithm, utilizing the strong error correction capability of LDPC codes to gradually approximate the correct decoding result. This step is controlled by a check equation and incorporates a maximum number of iterations, ensuring the reliability of the decoding process while avoiding getting bogged down in invalid calculations. The parallel computing advantages of the GPU are fully utilized in this process, with multiple threads simultaneously completing node updates, thus improving computational efficiency.

[0139] Step S9: Copy the decoding result back to the Host via asynchronous transmission, and calculate the error rate and decoding delay statistics of LDPC decoding.

[0140] The asynchronous transmission method is a data transmission mode in which data sending and receiving do not require strict synchronization. The sender can continue performing other tasks after sending data without waiting for a response from the receiver, thus improving system efficiency. The decoding result refers to the final data result obtained after multi-frame, multi-rate LDPC code parallel GPU decoding processing, i.e., the final decoding result Out_Dec. The host end typically refers to the main unit of a computer system, such as the CPU portion, which is responsible for overall system control and management. The decoding result needs to be copied back to the host end for further processing and analysis. The bit error rate is an important indicator of the reliability of a communication system; it represents the ratio of the number of erroneous code bits during transmission to the total number of transmitted code bits. The decoding latency refers to the time spent from the start of the decoding operation to obtaining the decoding result, reflecting the speed of the decoding process.

[0141] It should be noted that using asynchronous transmission to copy the decoding results back to the host effectively reduces the waiting time during data transmission, fully utilizes system resources, and improves the overall system efficiency. Calculating the bit error rate and decoding latency statistics in the communication system after transmitting the decoding results back to the host is of great significance. Bit error rate statistics can intuitively reflect the accuracy of the decoding results and the reliability of the communication system, helping to evaluate the performance of the LDPC code decoding method. Decoding latency statistics allow us to understand the speed of the decoding process, providing important references for optimizing system performance and meeting real-time requirements. Through accurate statistical analysis of bit error rate and decoding latency, the parallel GPU decoding method for multi-frame, multi-rate LDPC codes can be further improved, enhancing the overall quality of the communication system.

[0142] Step S10: Release resources for the CPU and the GPU.

[0143] The resource release refers to returning the memory, registers, and other system resources occupied by the CPU and GPU during operation to the system so that they can be used by other programs or tasks.

[0144] It's important to note that releasing CPU and GPU resources offers several significant advantages. Firstly, timely resource release prevents issues like memory leaks, ensuring efficient use of system memory and preventing performance degradation or even system failures due to excessive resource consumption. Releasing CPU memory resources after decoding allows for smoother and more efficient processing of subsequent tasks. Secondly, releasing GPU resources improves resource utilization, preparing for the next parallel computing task. Timely GPU resource release allows for rapid resource allocation to meet new decoding or other parallel computing demands, enhancing the overall system's responsiveness and processing power. By releasing CPU and GPU resources, multi-frame, multi-bitrate LDPC parallel decoding systems can operate more stably and efficiently, providing a favorable resource environment for subsequent operations and tasks.

[0145] Refer to the instruction manual. Figure 3 The schematic diagram of the architecture of the multi-frame, multi-rate LDPC code parallel GPU decoding method provided in the embodiments of the present invention can be clearly seen.

[0146] Figure 3In this process, multiple LLR information frames with different bitrates and signaling frame information are input into the global memory space from the host-side memory space. `decision` represents the hard decision result after final decoding on the device side. The CPU is responsible for data preprocessing, data transmission, memory space initialization, and task allocation. Data preprocessing includes receiving the input LLR information and signaling frame information, and compressing the corresponding parity-check matrix based on the bitrate information of the signaling frame information. The constant memory space stores the processed parity-check matrix compression parameters and frame offset parameters. The parity-check matrix compression parameters include row weights, row offsets, column weights, column offsets, column indices, and an index mapping table. The global memory space simultaneously stores the Check to Variable (C2V) node, the Variable to Check (V2C) node, the Log-Likelihood Ratio (LOV) of the variable node, and the decoding result Out_Dec. C2V, V2C, and LOV are variables that are continuously updated during the iteration process. C2V represents the information passed from the check node to the variable node stored on the device side; V2C represents the information passed from the variable node to the check node stored on the device side; LOV represents the LLR of the variable node stored on the device side; and Out_Dec is the final decoding result after hard decision. The PCIe bus, as the connection between the CPU and GPU, is responsible for the transmission of information and commands.

[0147] Figure 3 The process is as follows: The CPU receives LLR information and signaling frame information from multiple frames with different bitrates. Then, based on the bitrate information and frame length, it compresses the parity check matrix information to obtain row weights, row offsets, column weights, column offsets, column indices, and index mapping tables for multiple frames with different bitrates, and stores them in constant memory space. Then, on the host side, memory space is allocated for the parity parameter passing node C2V, variable parameter passing node V2C, LLR information, and variable node log-likelihood ratio (LOV), and its addresses are passed to the GPU for processing. Based on the longest frame number K calculated in step S1 and the GPU running parameters (number of threads per block B), the CPU... size Number of thread blocks B num The system allocates threads based on their size, and each thread uses the LLR-BP algorithm to calculate and update variables, iterating continuously until the upper limit of the number of iterations is reached or the check equation is satisfied. The final decoding result, Out_Dec, is then received by the CPU and stored as decision, completing the decoding process. This entire process fully leverages the CPU's efficient task management capabilities and the GPU's parallel computing advantages to achieve high-speed decoding of multiple frames of LDPC codes with different bitrates.

[0148] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A GPU parallel implementation method for multi-frame, multi-rate LDPC decoding, characterized in that, The method includes the following steps: Step S1: Based on the hardware parameters and the signaling frame information input from the front end, calculate the longest number of LDPC decoding frames that can be processed in parallel in the processor and the GPU running parameters. Step S2: Based on the LLR information and the code rate information of the multi-frame LDPC codes in the signaling frame information input from the front end, the CPU processes the parity check matrix to obtain the parity check matrix compression parameters and frame offset parameters. Step S3: Allocate the parity-check matrix compression parameters and frame offset parameters to the GPU's constant memory space, and initialize the constant memory space; Step S4: Allocate memory on the CPU side to store the LLR information passed from the front end and initialize the verification parameter passing node C2V, variable parameter passing node V2C, variable node log likelihood ratio LOV, and decoding result Out_Dec; Step S5: Allocate global memory space through the GPU for LLR information, verification parameter passing node C2V, variable parameter passing node V2C, variable node log-likelihood ratio LOV, and decoding result Out_Dec; Step S6: Configure GPU thread blocks based on the calculated GPU running parameters; Step S7: Dynamically adjust the parity matrix compression parameters according to the frame offset parameters, and pass the initialized parity parameters to node C2V, the variable parameters to node V2C, and the variable node log-likelihood ratio (LOV) to update the nodes in the GPU through kernel functions; Step S8: Synchronize on the GPU, make hard decisions on the codewords, and verify the check equation. If the equation is satisfied, end the iteration early; otherwise, continue iterating until the number of iterations reaches the set upper limit. Step S9: Copy the decoding result back to the Host via asynchronous transmission, and calculate the error rate and decoding delay statistics of LDPC decoding; Step S10: Release resources for the CPU and the GPU; The longest frame count for LDPC decoding in step S1 is calculated in relation to the GPU running parameters as follows: Step S101: Calculate the number of threads required per frame. The number of threads required per frame is calculated as follows: in, Indicates the first Number of threads required for a frame and They represent the first The number of variable nodes and the number of check nodes in the frame. This indicates taking the maximum value; Step S102: Convert the number of threads per frame to the number of thread blocks, using the following method: in, Indicates the first The thread block required for the frame. Indicates rounding up. This indicates the number of threads in each thread block; Step S103: The maximum number of frames satisfies the thread block resource usage limit of the streaming multiprocessor. The formula for the thread block resource usage limit of the streaming multiprocessor is as follows: in, Indicates the number of streaming multiprocessors. This indicates the maximum number of active thread blocks per stream multiprocessor; Step S104: The maximum number of frames meets the thread resource usage limit of the streaming multiprocessor. The formula for the thread resource usage limit of the streaming multiprocessor is as follows: in, This indicates the maximum number of threads per stream multiprocessor; Step S105: Obtain the maximum number of frames based on the thread block resource usage limit and the thread resource usage limit of the streaming multiprocessor. ; Step S105: Based on the longest frame number Calculate the number of thread blocks The calculation method is as follows: Number of threads per thread block and number of thread blocks The parameters that make up the GPU's operating parameters.

2. The GPU parallel implementation method for multi-frame, multi-rate LDPC decoding according to claim 1, characterized in that, In step S2, Processing the parity check matrix to obtain the parity check matrix compression parameters means replacing the original parity check matrix with only the node positions represented by the parity check matrix compression parameters, thereby achieving compression. The matrix compression process is the process of calculating the parity check matrix compression parameters. The compression parameters for the verification matrix include matrix row offset, row weight, column offset, column weight, column index, and index mapping table; The row offset is the starting position of the non-zero element in each row of the parity check matrix in row-order compressed storage within the column index array; the row weight is the number of non-zero elements in each row of the parity check matrix in row-order compressed storage; the column offset is the starting position of the non-zero element in each column of the parity check matrix in column-order compressed storage within the index mapping table; the column weight is the number of non-zero elements in each column of the parity check matrix in column-order compressed storage; the column index represents the column coordinates of all non-zero elements stored in row-order; the index mapping table is a mapping that replaces the edge information stored in row-order compressed storage with angles stored in column-order compressed storage to access the same edge. The frame offset parameter refers to the parity check matrix compression parameter for different frames when multiple frames are input simultaneously. The offset is determined by the frame offset parameter to ensure that the corresponding parity check matrix compression parameter is used for different frames during calculation.

3. The GPU parallel implementation method for multi-frame, multi-rate LDPC decoding according to claim 1, characterized in that, Step S7 includes the following steps: Step S71: Update the information passed from the check node to the variable node. Obtain the row offset, row weight and index mapping table of the current frame through the compressed check matrix information adjusted based on the frame offset parameter. Combine the information passed from the check node to the variable node collected by the current variable node to calculate the message passed from the check node to each variable node. The update process is executed in parallel row by row. For the check node information update of multiple frames with different bit rate signals, only the function of passing the information from the check node to the variable node needs to be called once. Step S72: Update the information passed from the variable node to the check node. Obtain the column offset, column weight, column index and index mapping table of the current frame through the information in the compression matrix adjusted based on the frame offset parameter. Combine the LLR value of the current variable node and the message received from the check node to calculate the message passed from the variable node to each check node. The update process is executed in parallel column by column. For the information update of variable nodes of signals with different bit rates in multiple frames, the function of passing information from the variable node to the check node only needs to be called once. Step S73: Update the log-likelihood ratio information of the variable node. Obtain the column offset and column weight of the current frame through the information in the compression matrix adjusted based on the frame offset parameter. Combine the initial information of the current variable node and the messages received from all connected check nodes to calculate the final LLR value of the variable node. The update process is executed in parallel column by column. For the LLR information update of variable nodes with different bit rates in multiple frames, only the variable node information function needs to be called once.

4. The GPU parallel implementation method for multi-frame, multi-rate LDPC decoding according to claim 3, characterized in that, In step S71, the information function passed from the verification node to the variable node, i.e., the verification node... Pass to variable node The information update formula is: in, This indicates that the log-likelihood ratio is calculated for the elements within the parentheses. Indicates the verification node Passed to variable node Information; Indicates and verifies nodes Connected divisor nodes The set of all external variable nodes; Indicates and verifies nodes Connected divisor nodes A variable node in the set of all external variable nodes; Indicates and verifies nodes Connected divisor nodes A variable node in the set of all external variable nodes Passed to the verification node Information.

5. The GPU parallel implementation method for multi-frame, multi-rate LDPC decoding according to claim 4, characterized in that, In step S72, the information function passed from the variable node to the verification node is the variable node. Transmitted to the verification node The information update formula is: in, Represents variable nodes Passed to the verification node Information; Represents the variable node at the current iteration number. Initial information; Represents the variable node Connected except for the check node The set of all external verification nodes; Represents the variable node Connected except for the check node A check node in the set of all external check nodes; Represents the variable node Connected except for the check node Pass one of the check nodes from the set of all external check nodes to the variable node. Information.

6. The GPU parallel implementation method for multi-frame, multi-rate LDPC decoding according to claim 5, characterized in that, In step S73, the information function of the variable node, i.e., the LLR decision information update formula of the variable node, is: in, Represents the variable node at the current iteration number. The final information; This represents the initial information of variable node j at the current iteration number; Represents the variable node The set of all connected verification nodes.

7. The GPU parallel implementation method for multi-frame, multi-rate LDPC decoding according to claim 6, characterized in that, In step S8, the formula for hard word determination is: in, This indicates the hard-coded judgment result; Represents a symbolic function; The formula for verifying the equation is: in, This represents the parity check matrix.

Images