LDPC DECODER WITH MULTI-CORE ARCHITECTURE

Description

Domaine de l'invention

[0001] The present invention relates to the field of low density parity check (LDPC) codes. In particular, the invention relates to a multi-core architecture for an LDPC decoder. Etat de la technique

[0002] LDPC codes are currently used in several communication technologies, including the IEEE 802.16 (WiMAX), IEE 802.11n (Wi-Fi) standards, the 5G standard of the 3GPP organization ("3rd Generation Partnership Project"), the DVB-S2 standard ("Digital Video Broadcasting, 2nd Generation"), or the CCSDS C2 space communications standard ("Consultative Committee for Space Data Systems, C2").

[0003] A binary LDPC code is a linear error-correcting code defined by a low-density binary parity matrix (i.e., the number of non-zero elements in the matrix is ​​relatively small compared to the size of the matrix).

[0004] To reduce the hardware implementation complexity of an LDPC decoder, it is known to use special structures of the parity matrix. In particular, quasi-cyclic LDPC codes (QC-LDPC for "Quasi-Cyclic Low Density Parity Check") are defined by parity matrices composed of submatrices of size Z x Z. The term Z is generally called "expansion factor". Submatrices of size Z x Z are generally called "circulant matrices". A parity matrix of a QC-LDPC code has a layered structure that allows parallelization of the calculations of parity check messages within a layer.

[0005] The 3GPP TS 38.212 technical specification document describes the LDPC configurations that must be supported by a device compatible with the 5G standard.

[0006] These 5G LDPC codes are compatible in terms of coding rate for Incremental Redundancy Hybrid Automatic ReQuest (IR-HARQ). HARQ is a technique for retransmitting data that has been corrupted by the communication channel. In the Chase Combining (CC-HARQ) variant, the same coding rate is used for each retransmission. In the IR-HARQ variant, a different coding rate is used for each retransmission.

[0007] 5G LDPC codes are based on quasi-cyclic parity matrices. Each 5G LDPC configuration corresponds to a triplet of parameters including the size K of the encoded word (this is the number of useful bits in the LDPC codeword), the coding rate R (this roughly corresponds to the ratio K / N between the size K of the encoded word and the size N of the LDPC codeword) and the expansion factor Z. By defining the parameters K and R, we can deduce the parameter Z to use, then dynamically construct the parity matrix to use.

[0008] A very large number (several thousand) of different configurations are supported by the specification (K can vary from a few bits to several thousand bits, Z can take about fifty possible values, and a large number of coding rates R are supported). This makes 5G LDPC codes very flexible and adaptable to a very wide range of transmission conditions.

[0009] This ultra-flexibility of LDPC codes, however, leads to a very high complexity of the decoders implementing them. In addition, conventional 5G LDPC decoders are generally inefficient for transmissions using a fixed spectral band. The high flexibility on the Z expansion factor leads to a complexity of the permutation network of the layered architecture. This complexity increases the footprint of the registers and logic gates of the circuit. This complexity also leads to a reduction in the overall throughput of the decoder. In addition, the parallel architecture of a conventional 5G LDPC decoder is often suboptimal for low values ​​of the Z expansion factor.

[0010] Space-related constraints (in particular in terms of size, weight and energy consumption) mean that conventional 5G LDPC decoders are not suitable for being carried on board a satellite.

[0011] Patent application US 2022 / 182076 A1 describes an LDPC decoder comprising a main decoder (“ full range decoder ”) and one or more auxiliary decoders (“ auxiliary decoders "). Codewords for which the expansion factor is greater than a predefined threshold are decoded by the main decoder, while codewords for which the expansion factor is less than the threshold are decoded by the auxiliary decoders. The paper "Comparative Analysis of Polar and LDPC Codes in Space and Satellite Communication Systems", Fominykh A. et al., concerns the use of LDPC codes in satellite communications. The paper "Design of a Multi-Core Scheduling Scheme for Tera-bit / s LDPC Decoding", Zhao Qiangyi et al., presents a multi-core architecture for an LDPC decoder.

[0012] The paper "A real-time programmable LDPC decoder chip for arbitrary QC-LDPC parity check matrices", Sin-Yu Shih et al., describes an on-the-fly reconfigurable LDPC decoder.

[0013] The paper “Low Latency MCS Design for LEO Satellite Communication Based on 5G”, Jin Zuolin et al., describes different coding and modulation schemes for a 5G-based LEO satellite communication system.

[0014] The paper "Design of a Multi-Core Scheduling Scheme for Tera-bits / s LDPC Decoding", Zhao Qiangyi et al., describes a scheduling scheme for a multi-core LDPC decoder.

[0015] Patent EP 3 331 180 B1 discloses a method and device for FEC (Forward Error Correction) decoding to be used in the field of telecommunications, in particular for a network element of a communication network with wavelength division multiplexing (WDM).

[0016] Patent application EP 2 369 749 A2 describes a flexible LDPC decoder that can be implemented with a level of parallelism lower than the total parallelism of the code structure used to control the decoding process.

[0017] US Patent 11,108,410 B1 describes a programmable LDPC decoder that can be configured to support a wide range of LDPC codes. Exposé de l'invention

[0018] The present invention aims to remedy all or part of the drawbacks of the prior art.

[0019] To this end, and according to a first aspect, the present invention provides a multi-core LDPC decoder for decoding low density parity check code words, or LDPC code, according to claim 1.

[0020] This multi-core approach is particularly advantageous because it allows the decoding of several code words in parallel. Thus, at a given time, different code words can be decoded in parallel by different cores according to different configurations. The multi-core approach also makes it possible to optimize memory resource requirements, by sharing memory between all the cores in the same group.

[0021] In particular embodiments, the invention may further comprise one or more of the following features, taken individually or in any technically possible combination.

[0022] In particular embodiments, the predefined NC configurations form a subgroup, in the strict sense, of the 5G LDPC configurations defined in the 3GPP TS 38.212 standard.

[0023] In particular embodiments, each core comprises a local configuration memory whose size is at least equal to the largest of the sizes of the predefined NC configurations stored in the shared memory, and the size of the local memory is at least four times smaller than the size of the shared memory.

[0024] The smaller the ratio between the size of a core's local memory and the size of the memory shared between different cores in the same group, the more efficient the memory sharing between the different cores.

[0025] In particular embodiments, the number NC of predefined configurations stored in the shared memory is between 8 and 512, or even between 8 and 256, or even between 8 and 128.

[0026] By selecting a limited number of LDPC configurations, it is possible to precompute and memorize the parity matrices corresponding to the selected configurations. It is then no longer necessary to dynamically construct the parity matrix each time a codeword has to be decoded with a new LDPC configuration. This also allows optimizing the decoder's hardware resources, particularly in terms of memory requirements, but also in terms of hardware complexity at the multiplexers and permutation network level, and in terms of energy consumption. This can also allow optimizing the scheduling of the parity check nodes for each configuration, in order to maximize the decoder's performance.

[0027] In particular embodiments, each of the NC configurations comprises an optimized scheduling of parity check nodes of the core. The scheduling is defined according to a parity degree of each parity check node for the configuration considered.

[0028] Such arrangements help mitigate situations where some control nodes cannot be executed because the output data from other control nodes is unavailable. In other words, this helps mitigate the performance loss due to "data hazards": the number of waiting cycles in the decoding process is lower, and the overall throughput of the decoder is improved.

[0029] In particular embodiments, decoding an LDPC codeword by a core comprises performing one or more iterations until a stopping criterion is satisfied. The stopping criterion comprises a check whether a maximum number of iterations is reached and, for a new codeword to be decoded by a core, the maximum number of iterations is defined according to a load rate of the multi-core decoder.

[0030] It is advantageous to have a lower maximum number of iterations when the multi-core decoder load is high. Indeed, when the decoder load is high, it is advantageous to quickly free up cores to be able to decode new codewords.

[0031] In particular embodiments, the load rate at a given time is calculated based on a number of cores simultaneously engaged in decoding an LDPC codeword at said time.

[0032] In particular embodiments, the maximum number of iterations is also defined as a function of the size of the new code word.

[0033] In particular embodiments, the maximum number of iterations is also defined based on a coding rate used for the new codeword.

[0034] In particular embodiments, the maximum number of iterations is also defined based on an estimated signal-to-noise ratio for the new codeword.

[0035] In particular embodiments, the multi-core decoder comprises a scheduling module adapted to schedule the cores by favoring, for the decoding of a new code word, the selection of a core for which the last configuration used by the core for the decoding of a previous code word is the same as the configuration to be used for the decoding of the new code word.

[0036] Such arrangements can avoid having to reload a new configuration into a core's local memory to decode a new codeword. This optimizes decoding time and limits concurrent access to shared memory.

[0037] According to a second aspect, the present invention relates to a receiving device comprising a multi-core decoder according to any one of the embodiments described above.

[0038] According to a third aspect, the present invention relates to a satellite comprising such a reception device. Présentation des figures

[0039] The invention will be better understood upon reading the following description, given by way of non-limiting example, and made with reference to the figures 1 à 22 which represent: [ Fig. 1 ] a schematic representation of a parity matrix of an LDPC code, [ Fig. 2 ] a schematic representation of a bipartite graph (Tanner graph) associated with a parity matrix, [ Fig. 3 ] an illustration of a method used to obtain a parity matrix of a quasi-cyclic LDPC code, [ Fig. 4 ] a schematic representation of an exemplary implementation of a method for decoding an LDPC codeword with a layered ordering, [ Fig. 5 ] a schematic representation of an exemplary embodiment of an LDPC decoder according to the invention, [ Fig. 6 ] a schematic representation of an example of realization of a core of the decoder of the figure 5 , to implement a decoding method such as that described in figure 4 , [ Fig. 7 ] a table showing the memory footprint for (uncompressed) parity check messages for different candidate configurations based on BG1, [ Fig. 8 ] a graphical representation of the memory footprint for (uncompressed) parity check messages for different candidate configurations based on BG1, [ Fig. 9 ] a graphical representation of the memory footprint for (uncompressed) parity check messages for different candidate configurations based on BG2, [ Fig. 10 ] a table showing the memory footprint for the a priori estimation variables for different candidate configurations based on BG1, [ Fig. 11 ] a graphical representation of the memory footprint for the a priori estimation variables for different candidate configurations based on BG1, [ Fig. 12 ] a graphical representation of the memory footprint for the a priori estimation variables for different candidate configurations based on BG2, [ Fig. 13 ] a table listing a set of selected configurations based on BG1, [ Fig. 14 ] a table listing a set of selected configurations based on BG2, [ Fig. 15 ] a graphical representation of the selected configurations listed in the tables of figures 13 And 14 , [ Fig. 16 ] a graphical representation of the degrees of the parity check nodes of the basis matrices BG1 and BG2, [ Fig. 17 ] a graphical representation of the degrees of the parity check nodes of the basic matrices BG1 and BG2, after scheduling, for the minimum coding rate, [ Fig. 18 ] a graphical representation of the degrees of the parity check nodes of the basic matrices BG1 and BG2, after scheduling, for a coding rate 1 / 2, [ Fig. 19 ] a graphical representation of the degrees of the parity check nodes of the basic matrices BG1 and BG2, after scheduling, for the maximum coding rate, [ Fig. 20 ] a schematic representation of another example of an LDPC decoder, with a multi-core architecture comprising a group of four cores, [ Fig. 21 ] a schematic representation of a second exemplary embodiment of a multi-core LDPC decoder comprising two groups of four cores, [ Fig. 22 ] a schematic representation of a third example embodiment of a multi-core LDPC decoder with a two-level hierarchy.

[0040] In these figures, identical references from one figure to another designate identical or similar elements. For reasons of clarity, the elements represented are not necessarily to the same scale, unless otherwise indicated. Description détaillée de l'invention

[0041] In the remainder of the description, the case of an LDPC decoder for space communications is considered in a non-limiting manner. The decoder may in particular be part of a receiver device on board a satellite intended to be placed in orbit around the Earth.

[0042] An LDPC code is defined by a parity matrix. The figure 1 schematically represents a parity matrix H of an LDPC code. We consider the case of a binary LDPC code. The parity matrix H is therefore a binary matrix, which means that each element of the matrix H is either a '0' or a '1'. We consider that the matrix H is of size M x N, with M and N positive integers. The matrix therefore has M rows and N columns. The parity matrix H is of low density, that is to say that the number of elements of the matrix equal to '1' is relatively small compared to the total number M x N of elements of the matrix. For example, the number of non-zero elements of the matrix is ​​less than 1% of the total number of elements of the matrix.

[0043] As illustrated on the figure 2 , an LDPC code can also be represented in the form of a bipartite graph G (Tanner graph) having connections between N nodes of variable VN n (n varying between 1 and N) and M parity check nodes CN m (m varying between 1 and M). Each non-zero element of the parity matrix H corresponds to a connection between a node of variable VN n and a parity check node CN m . Each row of the parity matrix H corresponds to a parity equation associated with a parity check node CN m . Each column of the parity matrix H corresponds to a variable associated with a node of variable VN n . A code word to be decoded corresponds to a set of values ​​taken respectively by the variables associated with the N variable nodes (it is the set of estimated values ​​of the bits of the code word).

[0044] A code word can have a relatively large size, for example a size greater than or equal to one thousand bits (N ≥ 1000), or even greater than ten thousand bits (N ≥ 10000). We are considering the case of an LDPC decoder which supports different code word sizes, and different coding rates. The coding rate corresponds to the ratio between the number of useful bits in a code word and the total number of bits in a code word. The closer the coding rate is to '1', the lower the computational complexity and the higher the useful bit rate can be; in return, the error correction power is lower. Conversely, the closer the coding rate is to '0', the greater the error correction power; in return, the computational complexity is higher and the useful bit rate is lower. The number of lines M and the density of the parity matrix generally depend on the coding rate.

[0045] The decoding of an LDPC codeword is based on an iterative exchange of information on the likelihood of the values ​​taken by the bits of the codeword. The iterative decoding process is based on a belief propagation algorithm which relies on an exchange of messages between the variable nodes VN n and the parity check nodes CN m .

[0046] As illustrated on the figure 2 , a message sent by a parity check node CN m to a variable node VN n is denoted β m,n . The value of a message β m,n is calculated at the parity node CN m for each of the variable nodes VN n connected to the parity check node CN m on the graph G.

[0047] A message sent by a variable node VN n to a parity check node CN m is denoted α n,m . The value of a message α n,m is calculated at a variable node VN n for each of the parity nodes CN m connected to the variable node VN n on the graph G.

[0048] This is an iterative process: the messages α n,m are calculated from the previously calculated messages β m,n, and the messages β m,n are calculated from the previously calculated messages α n,m. This iterative process takes as input a priori estimation variables of the codeword which correspond for example to log-likelihood ratio (LLR) logarithms. These are values ​​representing the probability that the value of a bit in the codeword is equal to '1' or '0' (logarithm of the ratio between the probability that the value of the bit is equal to '0' and the probability that the value of the bit is equal to '1').

[0049] A posteriori estimation variables γ n (n varying from 1 to N) of the bits of the code word are also calculated iteratively from the messages β m,n . These values ​​γ n are also representative of the probability that the value of a bit of the code word is equal to '1' or '0'. They allow a decision to be made on the value of each of the bits of the code word. A syndrome can then be calculated from the estimated values ​​of the bits of the code word and the parity equations defined by the parity matrix H. If we denote by c = (c 1 , c 2 , ..., c N ) the set of estimated values ​​of the bits of the code word, then the syndrome s is defined by the matrix equation s = H * c T< . A zero syndrome means that the estimated values ​​of the bits of the code word satisfy the parity equations.

[0050] Different conventional algorithms can be considered for the iterative LDPC decoding process (BP-SPA, Min-Sum, Offset Min-Sum). These algorithms are known to those skilled in the art. Sections 2.3.1 and 2.3.3 of the document « Efficient Hardware Implementations of LDPC Decoders through Exploiting Impreciseness in Message-Passing Decoding Algorithms » , TT Nguyen Ly (document subsequently referenced by "Ref1"), respectively describe an example of an iterative LDPC decoding process with the BP-SPA algorithm and with the Min-Sum algorithm in the case of flooding scheduling.

[0051] To reduce the hardware implementation complexity of the LDPC decoder, it is possible to use special structures of the parity matrix H that give the matrix a horizontal or vertical layered organization. For example, a horizontal layer of the parity matrix H can be defined as a set of consecutive rows defined in such a way that, for a given variable (i.e., for a given column of the parity matrix H), the layer has only one non-zero element.

[0052] This layered structure allows for parallel computation of parity check messages within a layer because the parity equations of a layer do not involve a variable of the code word more than once. Indeed, if a layer has only one non-zero element for a given variable, this means that the variable nodes VN n connected to a parity check node CN m of a layer are not connected to another parity check node of said layer.

[0053] There are several ways to obtain a parity matrix H with a layered structure. In particular, and as illustrated in the figure 3 , it is possible to obtain a parity matrix H from a basis matrix B of size R x C by replacing each element of the basis matrix B with a matrix of size Z x Z corresponding either to a zero matrix, or to the identity matrix, or to a shift of the identity matrix. The parity matrix then has R x Z rows (M = R x Z) and C x Z columns (N = C x Z). The term Z is generally called an "expansion factor". The submatrices of size Z x Z are generally called "circulant matrices". The terms R, C and Z are positive integers. An LDPC code defined by such a parity matrix H is called a "quasi-cyclic" LDPC code (QC-LDPC).

[0054] For example, and as illustrated on the figure 3 , each element of the basis matrix B is an integer with value '-1', '0', or a value less than Z. An element of the basis matrix B with value '-1' is replaced by the zero matrix; an element of the basis matrix B with value '0' is replaced by the identity matrix; an element of the basis matrix B with a value d between 1 and (Z-1) is replaced by a value shift d of the identity matrix.

[0055] A horizontal layer of the parity matrix H can then be defined as a set of ZP consecutive rows of the parity matrix H originating from a row of the basis matrix B, with ZP ≤ Z.

[0056] In a horizontally layered architecture, computations are primarily centered on the parity check nodes CN m . The number ZP corresponds to the number of functional units used to execute in parallel the computations performed at the parity check nodes. When ZP = Z, the level of parallelization is maximum.

[0057] Section 2.5.2 of Ref1 describes an example of an iterative LDPC decoding process with the Min-Sum algorithm in the case of horizontal layer scheduling. The posterior estimation variables γ n are initialized with the prior estimation variables (LLRs). The messages β m,n are initialized to zero. Then, at each iteration, the different layers are processed successively. For each layer: the messages α n,m are calculated from the messages β m,n and the posterior estimation variables γ n ; the messages β m,n are calculated from the messages α n,m ; the posterior estimation variables γ n are calculated from the messages β m,n ; a partial syndrome can then be calculated from the posterior estimation variables γ n .

[0058] There figure 4 schematically illustrates an exemplary implementation of a method 100 for decoding an LDPC codeword with a horizontal layered architecture.

[0059] As illustrated on the figure 4 , the method 100 comprises performing one or more iterations until a stopping criterion is satisfied. Each iteration comprises successively processing the layers of the parity matrix H. The processing 110 of a layer comprises: a calculation 111 of variable messages α n,m , for the variable nodes VN n involved in said layer, a calculation 112 of parity check messages β m,n , for the parity check nodes CN m involved in said layer, a calculation 113 of the a posteriori estimation variables γ n , a calculation 114 of a partial syndrome for said layer.

[0060] The calculation 111 of a variable message α n,m is performed for each variable node VN n involved in the layer being processed and for each of the parity check nodes CN m connected to said variable node VN n . The messages α n,m are calculated from the current values ​​of the a posteriori estimation variables γ n and from the current values ​​of the parity check messages β m,n . These current values ​​correspond either to the initialization values ​​(for the first iteration) or to the values ​​calculated during the previous iteration. For example, a message α n,m is calculated such that α n,m = γ n - β m,n .

[0061] The calculation 112 of a parity check message β m,n is performed for each parity check node CN m involved in the layer being processed and for each of the variable nodes VN n connected to said parity check node CN m . The messages β m,n are calculated from the current values ​​of the variable messages α n,m . For example, a message β m,n is calculated by considering all the messages α n',m associated with the parity check node CN m excluding the message α n,m associated with the variable node VN n ; the absolute value of a message β m,n is equal to the smallest absolute value of the messages α n',m considered; the sign of a message β m,n is equal to the product of the signs of the messages α n',m considered.

[0062] The calculation 113 of a value of the a posteriori estimation variable γ n is performed for each bit of the code word. For example, the γ n are calculated from the current values ​​of the parity check messages β m,n and the current values ​​of the variable messages α n,m such that γ n = α n,m + β m,n .

[0063] The calculation 114 of a partial syndrome for the layer being processed is performed by applying the parity equations of said layer to the posterior estimation variables γ n . The partial syndrome is then a vector of size L.

[0064] The method 100 comprises, at the end of the processing of each layer, a check 120 whether the iteration is finished or not. The iteration is finished when all the layers have been processed.

[0065] At the end of an iteration, the method 100 comprises an evaluation 130 of a stopping criterion. It is for example conceivable to consider that the stopping criterion is satisfied when all the partial syndromes calculated respectively for the different layers are zero. Other stopping criteria can however be envisaged: it is for example also possible to consider that the stopping criterion is satisfied when the partial syndromes of the different layers are all zero for a predetermined number of successive iterations. According to yet another example, the stopping criterion is satisfied if, for a plurality of successive iterations, the number of iterations for which all the partial syndromes are zero from which is subtracted the number of iterations for which at least one of the partial syndromes is non-zero is greater than or equal to a predetermined stopping threshold.

[0066] There figure 5 schematically represents an exemplary embodiment of an LDPC decoder 30 comprising at least one core 10 and a non-volatile memory 20 in which a number NC of predefined configurations is stored. The core 10 is a computing unit (a processor) adapted to be dynamically configured with any one of the NC predefined configurations stored in the memory 20 in order to decode an LDPC code word using this configuration. As illustrated in the figure 5 , the core 10 comprises a local configuration memory 13 whose size is at least equal to the largest of the sizes of the predefined NC configurations stored in the memory 20. Thus, each of the NC configurations can be temporarily loaded into the local memory 13 for the decoding of an LDPC code word. A new configuration is loaded into the local memory 13 each time a new LDPC code word must be decoded with a configuration different from that which is currently loaded into the local memory 13. The core 10 is adapted to carry out the iterative LDPC decoding method 100 described above with reference to the figure 4 . The core 10 is for example implemented in the form of a specific integrated circuit of the ASIC type (English acronym for “Application-Specific Integrated Circuit”), or a reprogrammable integrated circuit of the FPGA type (English acronym for “Field-Programmable Gate Array”).

[0067] There figure 6 schematically illustrates an example of embodiment of the core 10 described above with reference to the figure 5 . It should be noted, however, that there are many possible architectures for implementing an LDPC core in the literature. In the example shown in figure 5 , core 10 includes: an input buffer 11 of the first in-first out (FIFO) type for storing a data frame while another data frame is being processed, an input alignment unit 12 for forming blocks of data bits to be decoded of the size of the parallelization factor ZP, a local configuration memory 13, for example a volatile RAM (Random Access Memory) type memory, in which configuration information relating to the LDPC code is stored, in particular the parity matrix H to be used (which can be stored in any suitable form), a volatile memory 14 in which the current values ​​of the a posteriori estimation variables γ n are stored, a volatile memory 15 in which the current values ​​of the parity check messages β m,n are stored,a processing unit 16 configured to execute the iterations of the decoding process, that is to say in particular to implement the permutation network (shift operations of the identity matrix), to perform the calculations of the a posteriori estimation variables γ n , of the messages α n,m and β m,n , of the partial syndromes, and to determine whether the stopping criterion is satisfied, a multiplexer 19 for directing into the memory 14 the values ​​of the a priori estimation variables (for the first iteration) or the values ​​of the a posteriori estimation variables γ n calculated by the processing unit 16 (for the following iterations), a volatile memory 17 in which the hard decision values ​​of the bits of the code word are stored, an output alignment unit 18 for adapting the size of the blocks of decoded data bits to the expected size at the output of the decoder 10. , Compatibilité avec la 5G :

[0068] The 3GPP standard (acronym for "3rd Generation Partnership Project", a cooperation between telecommunications standards bodies), and more specifically the 3GPP technical specification document TS 38.212 (version 15.0.0 and later) describes the LDPC configurations that must be supported by a device compatible with the 5G standard (fifth generation of the 3GPP mobile communications standard).

[0069] Each 5G LDPC configuration corresponds to a triplet of parameters {K, R, Z} and a parity matrix. The parameter K corresponds to the size of the encoded word (this is the size of the useful data in the LDPC codeword). The parameter Z corresponds to an expansion factor ("lifting size Z"). The parameter R corresponds to the coding rate. This corresponds roughly to the ratio between the size of the encoded word and the size of the LDPC codeword (K / N ratio). More precisely, the coding rate R corresponds to the ratio K / (NN P ), where NP is a number of punctured bits.

[0070] 5G LDPC codes are based on quasi-cyclic parity matrices that can be constructed from a BG1 or BG2 basis matrix (“Base Graph 1 or Base Graph 2”).

[0071] The BG1 basis matrix has a maximum of 46 rows and 68 columns. The BG2 basis matrix has a maximum of 42 rows and 52 columns. Each entry of the basis matrix can be expanded with the expansion factor Z ('lifting size Z' in 3GPP TS 38.212). The number of rows and columns to be used depends on the coding rate R (the lower the coding rate, the larger the size of the basis matrix).

[0072] The choice of the BG1 base matrix or the BG2 base matrix is ​​defined by the specification depending on the values ​​of K and R (see section 6.2.2 of 3GPP TS 38.212): if K ≤ 3824 and R ≤ 0.67, then BG2 is selected, if K ≤ 292, then BG2 is selected, if R ≤ 0.25, then BG2 is selected, otherwise, BG1 is selected.

[0073] Once the base matrix is ​​selected, the specification defines a parameter K b which represents the number of columns of the base matrix to be used to process the information bits of the word of size K: for BG1, K b = 22; for BG2: ∘ if K > 640, then K b = 10, ∘ if 560 < K ≤ 640, then K b = 9, ∘ if 192 < K ≤ 560, then K b = 8, ∘ if K ≤ 192, then K b = 6.

[0074] The expansion factor Z is determined as the smallest value of Z satisfying K bx Z ≥ K.

[0075] Knowing the expansion factor Z, we can define from table 5.3.2-1 of the 3GPP TS 38.212 specification to which index i LS it corresponds. Table 5.3.2-2 then allows us to construct the basic matrix by filling it with values ​​between 0 and (Z-1). As described previously with reference to the figure 3 , an element of the base matrix with value '-1' is replaced by the zero matrix; an element of the base matrix with value '0' is replaced by the identity matrix; an element of the base matrix with an integer value 'd' between 1 and (Z-1) is replaced by an offset of value 'd' of the identity matrix.

[0076] A very large number of different configurations are supported by the specification. For example, K can vary from a few bits or a few tens of bits to several thousand bits (up to 8448 bits); the specification supports more than fifty possible values ​​for Z (values ​​between 2 and 384); a large number of different values ​​are possible for the coding rate R (the coding rate is directly related to the number of rows in the base matrix).

[0077] The need to support a very large number of different configurations for 5G LDPC codes is explained in particular by the need to have compatible codes in terms of coding rate to support IR-HARQ. IR-HARQ is used in particular to introduce frequency diversity in order to minimize the impacts of multipath which is very often present in terrestrial communications. IR-HARQ is also used to optimize spectral efficiency for communications characterized by very low propagation time.

[0078] 5G LDPC codes are therefore designed to be very flexible and adaptable to a very wide range of transmission conditions. This means that they use parity matrices of very variable length, which require a significant amount of logic to be implemented in hardware. Also, the number of different configurations to be supported is so large (several thousand different configurations in 5G) that it is not feasible to pre-calculate the parity matrices associated with these configurations in order to store them in memory. It is then necessary to dynamically calculate the parity matrix of the chosen configuration.

[0079] In return for this ultra-flexibility, conventional 5G LDPC decoders are generally relatively hardware inefficient for fixed spectral band processing. In particular, the high flexibility on the Z expansion factor leads to complexity in the permutation network of the layered architecture. This complexity increases the footprint of the circuit's registers and logic gates. This complexity also leads to an increase in the number of pipeline stages to maintain a high maximum circuit frequency. This increase in the number of pipeline stages, however, reduces the overall decoder throughput due to data hazards that are typically resolved by wait cycles (the term "data hazards" is used here to refer to a situation in which an instruction cannot be executed because it depends on the value of another instruction that is not yet available).

[0080] With a conventional 5G decoder, high data rates can be achieved with high values ​​for the coding rate R and the expansion factor Z. Conventional 5G decoders use a layered architecture with multiple processing units working in parallel, as mentioned earlier. The parallelization factor ZP is often chosen to be as large as possible. However, for smaller expansion factor values, the parallel architecture often becomes suboptimal.

[0081] For high-speed satellite communications applications (and possibly for some other specific applications), the ultra-flexibility offered by 5G in the choice of LDPC configurations is not useful, and it can significantly increase the hardware complexity and power consumption of the device on board the satellite.

[0082] In the field of space communications, where the transmission channel is essentially AWGN (Additive White Gaussian Noise), the benefit of using IR-HARQ is significantly reduced. The usefulness of considering all 5G LDPC codes (to maintain compatibility in terms of coding rate) is then reduced.

[0083] To obtain a 5G compatible LDPC decoder with good performance in terms of hardware efficiency, the present invention proposes to select a limited number of configurations from the very large number of LDPC configurations supported by the 3GPP TS 38.212 standard.

[0084] It may indeed be interesting to design an LDPC decoder that is compatible with 5G, in the sense that it supports at least some 5G LDPC configurations, without necessarily supporting all 5G LDPC configurations. In a satellite communications system, the resources to be used to establish communication between a ground station (for example a 5G mobile terminal) and a satellite are allocated by a ground gateway station. Among these resources is the LDPC configuration to be used to encode (on transmission) and decode (on reception) a code word included in a message exchanged between the ground station and the satellite. The gateway station may in particular comprise a radio resource control module configured to allocate only 5G LDPC configurations included in the predefined NC configurations.

[0085] In the following, we denote by NC the limited number of configurations supported by the decoder 30. This number NC is advantageously low, such that the parity matrices associated with these configurations are precalculated and stored in the memory 20. It is then no longer necessary to construct the entire parity matrix each time a new code word must be decoded with a new LDPC code. This makes it possible to limit the complexity of the decoder: the decoder does not need to implement the logic necessary for the construction of the parity matrix, and the permutation network can be simplified and optimized for the NC configurations retained.

[0086] The predefined NC configurations therefore form a strict subgroup of the 5G LDPC configurations defined in the 3GPP TS 38.212 standard.

[0087] In particular embodiments, the number NC of predefined configurations is between 8 and 512, or even between 8 and 256, or even between 8 and 128. Such a value of NC offers an interesting compromise between a sufficiently large number of configurations to cover a sufficient number of scenarios in terms of SNR and desired throughput, and a sufficiently small number of configurations to limit memory requirements and implementation complexity.

[0088] Each configuration corresponds to a triplet {K, R, Z}, and to a parity matrix constructed as a function of at least part of the parameters K, R and Z. As explained previously, by defining K and R, we can deduce the basic matrix to use (BG1 or BG2), then the value of Z, then the complete parity matrix.

[0089] As another example, it is possible to start by defining a set of some preferred values ​​for the expansion factor Z to which the NC configurations will be limited, and then deduce different possible values ​​of K to support certain coding rates R. As explained previously, a parity matrix can be constructed for each triplet {K, R, Z} retained.

[0090] Advantageously, the set of values ​​taken by the Z parameter among the predefined NC configurations includes at least two different values. This makes it possible to manage different message sizes (different values ​​of K).

[0091] In particular embodiments, the set of values ​​taken by the parameter Z among the NC predefined configurations comprises NZ different values ​​Z i and ordered in ascending order with the index i (i is an index varying between 0 and (NZ -1)), NZ being an integer between 2 and 32, or even between 4 and 16, the values ​​Z i being advantageously chosen such that, for i varying between 1 and (NZ -1), the ratio Z i Z 0 is equal to an integer value. Advantageously, one can choose NZ ≥ 8 to have a good variety in the supported configurations.

[0092] It is then advantageous to choose a value of Z 0 equal to the parallelization factor ZP of the decoder 30 (ZP = Z 0 ). As a reminder, the parallelization factor ZP corresponds to the maximum number of functional units of the core 10 that can be used in parallel to execute the calculations of the parity check nodes. Such arrangements make it possible to optimize the use of the decoder's hardware resources for parallelization and, as will be seen later, to offer more flexibility for resolving data randomness situations.

[0093] It should be noted, however, that the value Z 0 is not necessarily the smallest value among the set of values ​​taken by the parameter Z among the predefined NC configurations (nothing would prevent having a configuration with a value of Z strictly lower than ZP , for example if this configuration allows for the specific treatment of relatively rare cases of transmission of small messages).

[0094] To optimize the hardware implementation of the decoder, it is also advantageous to choose a value of Z 0 equal to a power of two (in other words, a value of Z 0 that can be written in the form 2 n < , where n is a positive integer). This allows to maximize the hardware use of the multiplexers and the permutation network.

[0095] As a non-limiting example, we can choose Z 0 = 32, NZ = 12, and Z i = (i + 1) x Z 0 for i varying between 0 and (NZ -1).

[0096] For the values ​​Z i retained, it is advantageous to select configurations which limit the size of the addressing bus of the volatile memory 15 of the core 10 in which the current values ​​of the parity check messages β m,n are stored.

[0097] The table in figure 7 gives the size in bits of the memory address bus 15 for different configurations with the values ​​Z i retained when the basic matrix to be used is BG1. Each column of the table corresponds to a particular value Z i, each row of the table corresponds to a particular coding rate value R. For a pair of values ​​{Z i ; R}, it is possible to determine the corresponding value of the parameter K. Each box of the table of the figure 7 therefore corresponds to a candidate configuration.

[0098] The size of the memory address bus 15 for parity check messages (uncompressed) β m,n is equal to log 2 N conn Z P , where N conn corresponds to the number of non-zero elements (number of connections) in the parity matrix of the configuration considered. N conn also corresponds to Z i multiplied by the number of non-zero elements in the m B rows and n B columns of the basic matrix used for the configuration considered.

[0099] As illustrated on the figure 7 , it is for example advantageous to select the supported configurations such that the size of the memory addressing bus 15 for the parity check messages β m,n is less than or equal to 16 − log 2 Z P (i.e. less than or equal to 11 when ZP = 32).

[0100] There figure 8 is a graphical representation of the table of the figure 7 (this is a graphical representation of the bit size of the memory address bus 15 for different candidate configurations with the Z i values ​​retained when the basic matrix to be used is BG1). The figure 9 is a graphical representation of the bit size of the memory address bus 15 for different candidate configurations with the Z i values ​​retained when the basic matrix to be used is BG2. It can be observed that the configurations based on BG1 are more restrictive than those based on BG2.

[0101] As described in section 4.3.1 of document Ref1, it is possible to "compress" the β m,n parity check messages processed by a functional unit. For example, rather than storing the values ​​of the β m,n messages associated with a check node, it may be sufficient to store the signs of these messages, the absolute value of at least two minimum values ​​among these messages, and the indexes associated with these minimum values ​​except one.

[0102] Thus, in the uncompressed case, each memory entry corresponds to a message β m,n , whereas in the compressed case, each memory entry corresponds to the compressed data (signs, min, index) of a layer.

[0103] In the case where the parity check messages are compressed, the size of the memory address bus 15 for the parity check messages is equal to log 2 m B ⋅ Z i Z P , where m B corresponds to the number of rows of the base matrix used, and m B ⋅ Z i Z P corresponds to the number of layers in the parity matrix for the configuration considered ( m B · Z i is equal to the number M of rows of the parity matrix for the configuration considered).

[0104] In the case where the parity check messages are compressed, it is for example advantageous to select the supported configurations such that the size of the memory address bus 15 for the parity check messages is less than or equal to 14 − log 2 Z P (i.e. less than or equal to 9 when ZP = 32).

[0105] For the values ​​Z i retained, it may also be advantageous to select configurations which limit the size of the address bus of the volatile memory 14 of the core 10 in which current values ​​of a posteriori estimation variables γ n are stored (the term APP is also used to designate the a posteriori estimation variables).

[0106] The table in figure 10 gives the size in bits of the memory address bus 14 for different configurations with the Z i values ​​retained when the basic matrix to be used is BG1.

[0107] The size of the memory address bus 14 for the posterior estimation variables γ n is equal to log 2 N Z P , where N corresponds to the size of a code word for the configuration considered. The size N is equal to n B · Z i , where n B corresponds to the number of columns of the basic matrix used for the configuration considered.

[0108] As illustrated on the figure 10 , it is for example advantageous to select the supported configurations such that the size of the memory address bus 14 for the a posteriori estimation variables γ n is less than or equal to 14 − log 2 Z P (i.e. less than or equal to 9 when ZP = 32).

[0109] There figure 11 is a graphical representation of the table of the figure 10 (this is a graphical representation of the bit size of the memory address bus 14 for different candidate configurations with the Z i values ​​retained when the basic matrix to be used is BG1). The figure 12 is a graphical representation of the bit size of the memory address bus 14 for different candidate configurations with the Z i values ​​retained when the basic matrix to be used is BG2. It can be observed that the configurations based on BG1 are more restrictive than those based on BG2.

[0110] In the example considered, the selected configurations are listed in the tables in figure 13 And 14 . The table in figure 13 lists fifty-one selected configurations based on BG1, while the table in figure 14 lists twenty selected configurations based on BG2. In this example, there are therefore a total of seventy-one configurations (NC = 71) to be stored in non-volatile memory 20.

[0111] In the tables of figures 13 And 14 , the "Connections" column indicates the number of connections (number of non-zero elements) in the base matrix. The number N conn of connections in the parity matrix corresponds to the number of connections in the base matrix multiplied by the expansion factor Z.

[0112] There figure 15 is a graphical representation of the selected configurations listed in the tables of figures 13 And 14. In this figure, the selected configurations based on BG1 are represented by squares, the selected configurations based on BG2 are represented by circles. It is clear from this representation that, advantageously, for K > 3824, the number of predefined configurations with an expansion factor equal to Z i is a decreasing function with the value of Z i . Similarly, for K ≤ 3824 and R ≤ 0.67, the number of predefined configurations with an expansion factor equal to Z i is a decreasing function with the value of Z i .

[0113] 5G LDPC codes have a very irregular distribution of CN m check node parity degrees. This means that different check nodes can have different (and potentially very different) numbers of data bits connected to them. The parity degree of a CN m parity check node corresponds to the number of data bits connected to it; it also corresponds to the number of parity equations in which the check node is involved.

[0114] There figure 16 illustrates this irregularity of 5G LDPC codes. The figure 16 represents the degrees of the parity check nodes of the basis matrices BG1 and BG2. On the figure 16 , the degrees of the parity check nodes for BG1 are represented by squares, the degrees of the parity check nodes for BG2 are represented by crosses.

[0115] In a layered architecture, CN m parity check nodes can be executed in parallel. However, the uneven distribution of the parity degrees of the check nodes leads to situations where some check nodes cannot be executed until the output data from other check nodes is available. It then becomes necessary to insert additional wait cycles into the decoding process. This reduces the overall throughput of the decoder.

[0116] To solve this problem, it is possible to schedule the control nodes in a special and optimized way according to their parity degree. In particular, the control nodes can be scheduled in ascending order of parity degrees (this means that the control nodes with the fewest connected data bits are executed first).

[0117] It is also possible to optimize, using heuristics, the order of control nodes with the same degree of parity, or the order of calculations within a control node.

[0118] Each configuration selected and stored in the memory 20 can therefore advantageously include this optimized ordering of the control nodes (i.e. an indication of the order in which the control nodes must be executed). This approach cannot be implemented for conventional 5G LDPC decoders due to the large number of different configurations they must support. This approach, however, applies very well to the decoder 30 according to the invention because the number NC of predefined configurations is limited.

[0119] THE figures 17 , 18 And 19represent respectively the degrees of the parity check nodes of the basic matrices BG1 and BG2 after ordering in ascending order of the parity degrees, for different values ​​of the coding rate R. The figure 17 corresponds to the minimum coding rate (case where all rows of the basic matrices BG1 and BG2 are used), the figure 18 corresponds to a coding rate of value ½ (the basic matrix BG1 then has twenty-four lines, while the basic matrix BG2 has twelve lines), and the figure 19 corresponds to a maximum coding rate (case where the basic matrices BG1 and BG2 have only four lines).

[0120] It appears on the figures 17 à 19 that, for BG1-based configurations, parity-check nodes with a parity degree of nineteen are always present, regardless of the coding rate. Similarly, for BG2-based configurations, parity-check nodes with a parity degree of eight or ten are always present, regardless of the coding rate.

[0121] For a given value of Z, the ordering of the control nodes of the configuration corresponding to the maximum coding rate can therefore be common to all the configurations. In other words, for a given value of Z, for each configuration selected and stored in the memory 20, the ordering of the control nodes can comprise a part common to all the configurations and a specific part specific to the configuration considered. The common part corresponds to the ordering of the control nodes of high degree; the specific part corresponds to the ordering of the control nodes of lower degree.

[0122] This common part allows to limit the memory size necessary to memorize the configurations (the common part is memorized only once for all the configurations with the same value of Z). This concept is illustrated by the columns "Config size" and "Opt. config size" of the tables of figures 13 And14 . For each selected configuration, the number shown in the "Config Size" column is representative of the total size needed to store the ordering of the control nodes for that configuration. This number corresponds to the number N conn of connections in the parity matrix divided by the parallelization factor ZP (it also corresponds to the number of connections in the base matrix, shown in the "Connections" column, multiplied by the ratio Z Z P ). For a given value of Z, the number indicated in the "Config Size" column for the maximum coding rate (R=0.92) corresponds to the size of the common part; the number indicated in the "Config Size" column for a lower coding rate corresponds to the sum of the size of the common part and the size of the specific part. For a given value of Z, the number indicated in the "Opt. Config Size" column corresponds either to the size of the common part (for the maximum coding rate), or to the size of the specific part (for lower coding rates). For each value of Z, it is sufficient to memorize the common part corresponding to the maximum coding rate (R=0.92) and the specific parts corresponding to the lower coding rates selected. Proceeding in this way makes it possible to almost halve the memory size necessary to memorize the selected configurations listed in the tables of figures 13 And 14 .

[0123] As mentioned earlier, it is advantageous to choose a parallelization factor ZP equal to the smallest Z 0 value among the supported Z i values, as this limits the loss of parallelism while providing greater flexibility in solving data hazard situations for high values ​​of the expansion factor. This choice goes against an established idea that the largest possible parallelization factor should be used. Using the largest possible parallelization factor certainly has an advantage in limiting decoding latency, but it offers less flexibility in the ability to solve data hazards with a particular scheduling of control nodes. In the field of space communications, the constraints on LDPC decoding latency are significantly less demanding than for terrestrial communications. Architecture multicœur :

[0124] The invention also relates to an LDPC decoder with a multi-core architecture. This multi-core architecture is particularly well suited to a 5G-compatible LDPC decoder as described above. However, nothing would prevent implementing an LDPC decoder with a multi-core architecture and a set of predefined NC configurations without these configurations corresponding to 5G LDPC configurations.

[0125] THE figures 20 à 22 present three examples 31-a, 31-b, 31-c of embodiment of a multi-core decoder 31 (in the following, the reference number 31 is used to generically indicate a multi-core LDPC decoder according to the invention).

[0126] In the example illustrated on the figure 20 , the decoder 31-a comprises a group of four cores 10, each core being similar to the core 10 of the decoder 30 described with reference to the figure 5 . Memory 20 is shared between these four cores 10.

[0127] Each core 10 of the group is adapted to be dynamically configured with any of the predefined NC configurations stored in the shared memory 20 in order to decode an LDPC code word using this configuration. Each predefined configuration comprises a binary parity matrix corresponding to an LDPC code (this is advantageously the complete parity matrix, and not just a sub-matrix for calculating the parity matrix).

[0128] Advantageously, several cores of the group can simultaneously decode each a different LDPC code word. Each time a new code word must be decoded by the decoder 31, a scheduling module 21 is configured to select an available core 10 from among the different cores 10 of the group, to load into the local memory 13 of the selected core 10 the LDPC configuration to be used to decode the code word, and to launch the decoding of the code word by the selected core 10.

[0129] Each time a core 10 has completed its process of decoding a code word, it sends information to the scheduling module 21 to indicate to it that it is available to decode a new code word.

[0130] This multi-core approach is particularly advantageous since it allows the decoding of several code words in parallel, i.e. simultaneously. Thus, at a given time, different code words can be decoded in parallel by different cores 10 according to different configurations.

[0131] The multi-core approach also optimizes memory resource requirements. Memory cost is reduced because memory 20 is shared with all cores in the group. The smaller the ratio between the size of local memory 13 of a core 10 and the size of memory 20 shared between cores 10 in the same group, the more efficient the sharing of memory 20 between different cores 10 is.

[0132] As seen previously, the decoding of an LDPC codeword by a core 10 involves the execution of one or more iterations until a stopping criterion is satisfied, for example based on the partial syndromes calculated for the different layers. It is also appropriate to set a maximum number of iterations after which the decoding process must stop.

[0133] It is important to correctly define this maximum number of iterations because it has a significant impact on the decoder's performance. In particular, when the LDPC decoder is embedded in a satellite, constraints in terms of computing power and energy consumption lead to choosing a relatively low maximum number of iterations, generally of the order of ten. Each additional iteration therefore has an impact of around ten percent on performance.

[0134] To optimize the performance of the multi-core decoder 31, the maximum number of iterations is defined according to a load rate of the decoder. Each time a new code word must be decoded by a core 10 of the multi-core decoder 31, the maximum number of iterations to be used for the decoding of this new code word is calculated.

[0135] At a given instant, the load rate of the multi-core decoder 31 is calculated based on the number of cores simultaneously occupied in decoding an LDPC code word. For example, for the multi-core decoder 31-a described with reference to the figure 20 , the load rate is respectively 0%, 25%, 50%, 75% or 100% depending on whether the number of cores 10 simultaneously occupied in decoding a code word is equal to zero, one, two, three or four. The load rate is for example calculated by the scheduling module 21.

[0136] To define the maximum number of iterations to be used for decoding a new code word, the load rate of the decoder 31 is calculated just before the start of decoding of the new code word. The load rate may or may not take into account the fact that the core 10 responsible for decoding the new code word is busy. In the remainder of the description, we consider the case where the load rate does not take into account the occupancy of the core 10 which will be responsible for decoding the new code word. In this case, if the load rate is equal to 100%, then the scheduling module 21 must wait for a core 10 to become available to assign it the decoding of the new code word.

[0137] As a non-limiting example, when the load rate is less than or equal to 50%, the maximum number of iterations is set at ten. When the load rate is strictly greater than 50%, then the maximum number of iterations is set at eight.

[0138] However, nothing would prevent setting another threshold value for the load rate, or other values ​​for the maximum number of iterations depending on the load rate compared to the threshold.

[0139] It is advantageous to have a lower maximum number of iterations when the load rate of the multi-core decoder 31 is high. Indeed, when the load rate of the decoder 31 is high, it is necessary to quickly release the cores 10 to be able to decode new code words. Using a lower maximum number of iterations makes it possible to limit the decoding time of a code word (while accepting the possible risk of having errors in the decoding).

[0140] In particular embodiments, the maximum number of iterations may also be defined as a function of the coding rate R used for the new codeword. As a non-limiting example, when the load rate is less than or equal to 50%, the maximum number of iterations is set to ten. When the load rate is strictly greater than 50% and the coding rate is 2 / 5, then the maximum number of iterations is set to eight. When the load rate is strictly greater than 50% and the coding rate is 8 / 9, then the maximum number of iterations is set to six. Again, in variants, other values ​​could be envisaged for the load rate threshold, the coding rates and / or the values ​​of the maximum number of iterations.

[0141] It is advantageous to have a lower maximum number of iterations when the coding rate of the multi-core decoder 31 is higher because a higher coding rate generally corresponds to a faster convergence of the decoding process.

[0142] In particular embodiments, the maximum number of iterations may also be defined as a function of the size N of the new codeword. For example, the larger the size N of the codeword, the smaller the maximum number of iterations may be, since the decoding process tends to converge faster for larger codeword sizes.

[0143] In particular embodiments, the maximum number of iterations may also be defined based on an estimated signal-to-noise ratio (SNR) for the new codeword. For example, the higher the estimated value of the SNR, the lower the maximum number of iterations may be. Indeed, the decoding process also tends to converge faster for high SNR values.

[0144] The maximum number of iterations to be used by a core 10 for decoding a new codeword can be set based on a combination of conditions depending on the decoder load rate, the coding rate R to be used for decoding the new codeword, the size N of the new codeword, or the estimated SNR level for the new codeword.

[0145] The multi-core 31-a decoder described above with reference to the figure 20 comprises a single group of four cores 10. However, nothing would prevent, in variants, the design of a multi-core decoder comprising several groups of several cores. In the example illustrated in figure 21 , the multi-core 31-b decoder has two groups of four cores. Each group has a memory 20 shared between the four cores 10 of the group.

[0146] There would also be nothing to prevent having a different number of cores 10 within each group (e.g. only two cores, or eight cores), or having different numbers of cores for the different groups.

[0147] When there are several groups of cores, the load threshold at a given time can be calculated as a function of the total number of cores simultaneously engaged in decoding an LDPC code word at that time, taking into account all the groups. However, nothing would prevent, in variants, taking into account only the load rate of the group to which the core responsible for decoding the new code word belongs, or else defining an average load rate per group. The different possible methods for calculating the load rate and for defining the maximum number of iterations as a function of the load rate are only variants of the invention.

[0148] In particular embodiments, the scheduling module 21 is configured to schedule the different cores 10 of the multi-core decoder 31 by favoring, for the decoding of a new code word, the selection of a core 10 for which the last configuration used by the core for the decoding of a previous code word is the same as the configuration to be used for the decoding of the new code word.

[0149] Such arrangements make it possible to avoid having to reload a new configuration into the local memory 13 of the core 10 for decoding the new code word. This makes it possible to optimize the decoding time and to limit concurrent accesses to the shared memory 20.

[0150] For this purpose, a buffer memory may be used by the scheduling module 21 to store the configuration last used by each of the cores 10 of the multi-core decoder 31. When a new code word is to be decoded according to a particular configuration, the scheduling module 21 is configured to identify, among the different cores, whether a core is available for which the configuration last used is the same as the configuration to be used for decoding the new code word. If such a core is identified, then it is preferentially selected for decoding the new code word.

[0151] As illustrated by the figure 22 , the concept of multi-core architecture of LDPC decoder can also be generalized with multiple levels of hierarchy.

[0152] There figure 22 schematically represents a third example 31-c of an embodiment of a multi-core LDPC decoder with a two-level hierarchy. The multi-core decoder 31-c comprises four first-level groups each comprising four LDPC cores 10, a first-level shared memory 20 (“Mem. lv. 1”) and a first-level scheduling module 21 (“Ord. lv. 1”) configured to schedule the cores 10 of the first-level group. The multi-core decoder 31-c also comprises a second-level group comprising the four first-level groups, a second-level shared memory 22 (“Mem. lv. 2”) and a second-level scheduling module 23 (“Ord. lv. 2”) configured to schedule the first-level scheduling modules 21.

[0153] The concept illustrated in the figure 22 could be extended to a number of hierarchy levels greater than two. The highest level shared memory 22 is a non-volatile memory that stores the set of predefined NC configurations. Different groups of configurations can be dynamically loaded into the lower level shared memories 20. The size of a shared memory can be larger the higher its hierarchy level. Résultats de tests :

[0154] Tests were carried out to compare a conventional 5G decoder made in FPGA (Xilinx) with an LDPC decoder according to the invention, for the decoding of a code word according to certain particular configurations.

[0155] It was observed that the coded rate values ​​are significantly more homogeneous with the decoder according to the invention for the different configurations tested (the coded rate can be measured in MLLR / s, one MLLR / s corresponds to a rate of 10 6< LLR values ​​per second). The ratio between the highest coded rate and the lowest coded rate is of the order of five for the conventional 5G decoder, compared to a ratio of the order of 2.5 with an LDPC decoder according to the invention.

[0156] For high coding rates (e.g. for a configuration {K=5632, R=8 / 9, Z=256}), it has been observed that the memory requirements are about 1.25 times higher and the logic requirements are about 2 times higher for the conventional 5G decoder compared to the LDPC decoder according to the invention. The memory requirements can be measured in BRAM per MLLR / s; a BRAM corresponds to a 36 kbit RAM block. The logic requirements can be measured in LUT6 per MLLR / s; a LUT6 is an FPGA resource corresponding to a six-entry Look-Up Table.

[0157] For low coding rates (e.g. for a configuration {K=5632, R=2 / 5, Z=256}), it has been observed that the memory requirements are about 2.0 times higher and the logic requirements are about 3.6 times higher for the conventional 5G decoder compared to the LDPC decoder according to the invention.

[0158] It should be noted that the above results were obtained for an optimal parallelization rate for the conventional 5G decoder. With a more heterogeneous distribution of the tested configurations, the decoder according to the invention would have outperformed the conventional decoder even more significantly.

[0159] The above description clearly illustrates that, through its various characteristics and their advantages, the present invention achieves the set objectives. In particular, the decoder according to the invention is compatible with 5G while remaining particularly well suited and very efficient for satellite communications.

[0160] It should be noted that the embodiments considered above have been described as non-limiting examples, and that other variants are therefore conceivable. In particular, the value of the NC number or the specific examples of LDPC configurations retained are in no way limiting. Other configurations could be selected to form a strict subgroup of the set of 5G LDPC configurations defined by the 3GPP TS 38.212 specification.

[0161] Similarly, different values ​​may be considered for the number of cores or the number of groups of cores forming the LDPC decoder. Also, different methods may be considered for defining the maximum number of iterations as a function of a load rate of the decoder. The different possible choices for these values ​​or these methods constitute only variants of the invention.

[0162] The invention has been described by considering an LDPC decoder intended to be embedded in a satellite in orbit around the Earth. However, nothing excludes, following other examples, from considering other specific areas in which it could be interesting to have an LDPC decoder compatible with 5G without necessarily supporting all 5G LDPC configurations.

[0163] The present application relates on the one hand to a multi-core architecture for an LDPC decoder, and on the other hand to obtaining a 5G-compatible LDPC decoder (i.e., compatible with at least some 5G LDPC configurations) that remains suitable and efficient for satellite communications. These two aspects can, however, be applied independently of each other: the proposed multi-core architecture is an invention in its own right, whether or not it is used for a 5G-compatible LDPC decoder. The proposed multi-core architecture is, however, particularly well-suited for designing a 5G-compatible LDPC decoder suitable for satellite communications.

Claims

1. Multicore decoder (31) for decoding low-density parity-check, or LDPC, code words, said multi-core decoder (31) comprising at least one group of several cores (10), several of these cores (10) each simultaneously capable of decoding a different LDPC code word, said at least one group comprising a memory (20) shared between the various cores (10) in which a number NC of predefined configurations is stored, each predefined configuration being associated with a parity matrix corresponding to an LDPC code, each core (10) being adapted to be dynamically configured with any one of the NC predefined configurations stored in the memory (20) in order to decode an LDPC code word using this configuration; characterized by: the parity matrices associated with the NC predefined configurations being precomputed and stored in the shared memory (20).

2. Multicore decoder (31) according to claim 1, wherein the NC predefined configurations form a subgroup, in the strict sense, of the 5G LDPC configurations defined in the 3GPP TS 38.212 standard.

3. Multicore decoder (31) according to either one of claims 1 to 2, wherein each core (10) includes a local configuration memory (13) the size of which is at least equal to the largest of the sizes of the NC predefined configurations stored in the shared memory (20), and the size of the local memory (13) is at least four times smaller than the size of the shared memory (20).

4. Decoder (31) according to any one of claims 1 to 3, wherein the number NC of predefined configurations stored in the shared memory (20) is between 8 and 512, or even between 8 and 256, or even between 8 and 128.

5. Decoder (31) according to any one of claims 1 to 4, wherein each of the NC configurations comprises an optimized scheduling of parity check nodes of the core (10), said scheduling being defined according to a degree of parity of each parity check node for the configuration in question.

6. Multicore decoder (31) according to any one of claims 1 to 5 wherein decoding an LDPC code word by a core (10) comprises executing one or more iterations until a stop criterion is met, said stop criterion comprising checking whether a maximum number of iterations is reached and, for a new code word to be decoded by a core (10), the maximum number of iterations is defined according to a load on the multicore decoder (31).

7. Multi-core decoder (31) according to claim 6, wherein the load at a given time is calculated according to a number of cores (10) simultaneously occupied decoding an LDPC code word at said time.

8. Multicore decoder (31) according to any one of claims 6 to 7, wherein the maximum number of iterations is also defined according to the size of the new code word.

9. Multicore decoder (31) according to any one of claims 6 to 8, wherein the maximum number of iterations is also defined according to an encoding rate used for the new code word.

10. Multicore decoder (31) according to any one of claims 6 to 9, wherein the maximum number of iterations is also defined according to an estimated signal-to-noise ratio for the new code word.

11. Multi-core decoder (31) according to any one of claims 1 to 10, comprising a scheduling module (21) suitable for scheduling the cores (10) by favoring, for decoding a new code word, the selection of a core (10) for which the last configuration used by the core (10) for decoding a previous code word is the same as the configuration to be used for decoding the new code word.

12. Receiving device comprising a decoder (31) according to any one of claims 1 to 11.

13. Satellite comprising a receiving device according to claim 12.