HK1129781B

HK1129781B - Decoder

Info

Publication number: HK1129781B
Application number: HK09107380.4A
Authority: HK
Inventors: 安德鲁．布兰克斯拜; 阿尔文．莱．林
Original assignee: 美国博通公司
Priority date: 2007-08-06
Filing date: 2009-08-11
Publication date: 2012-06-29

Description

Decoder

Technical Field

The present invention relates to a communication system, and more particularly, to a technique for decoding a Low Density Parity Check (LDPC) encoded signal in a communication system.

Background

Data communication systems have continued to evolve for many years, and in recent years, communication systems employing iterative error correction codes have been the focus of attention by researchers. Of which the most interesting is the communication system employing LDPC codes. The error rate of a communication system using iterative codes is generally lower than that of a communication system using other codes with the same signal-to-noise ratio.

A continuing and leading direction in the art is to reduce the signal-to-noise ratio in a communication system to achieve a particular bit error rate. The ideal goal is to try to study the Shannon's limit (Shannon's limit) in a communication channel, which can be seen as the data transmission rate used in a channel with a certain signal-to-noise ratio, through which error-free transmission can be achieved. In other words, the shannon limit is the theoretical limit of channel capacity for a given modulation and coding rate.

LDPC codes have been demonstrated to provide very good decoding performance approaching the shannon limit in some cases. Theoretically, some LDPC decoders have been demonstrated to achieve a performance of 0.3 db from shannon limits. Irregular LDPC codes, one million in length, have achieved this performance, which has proven to be very promising for application of LDPC codes in communication systems.

The use of LDPC coded signals continues to be applied in many new areas. Examples of several possible communication systems in which LDPC coded signals may be employed include communication systems employing 4-pair twisted-pair cables for high-speed ethernet applications (e.g., 10Gbps ethernet operation in accordance with IEEE 802.3an (10GBASE-T)) and communication systems operating within a wireless environment (e.g., within the IEEE802.11 environment space including the IEEE802.11n emerging standard).

For these particular fields of communication system applications, error correction codes that can achieve near capacity are highly desirable. The potential limitations introduced by the use of traditional chaining codes have prevented their use in high data rate communication system applications.

Generally, in the context of a communication system employing LDPC codes, there is a first communication device having encoder capabilities at one end of a communication channel and a second communication device having decoder capabilities at the other end of the communication channel. In most cases, either or both of the two communication devices have encoder and decoder capabilities (e.g., in a two-way communication system). LDPC codes may also be used in a variety of other applications, including those that employ some form of data storage (e.g., hard disk drive HDD applications and other storage devices), in which data is encoded prior to being written to a storage medium and then decoded after being read/retrieved from the data medium.

One of the biggest difficulties in designing an efficient device and/or communication device to decode LDPC encoded signals in many such existing communication devices is the large area and memory required to store and manage all bit edge messages (bit edge messages) and check edge messages (check edge messages) that are updated and used in the iterative decoding process (e.g., when storing and passing check edge messages and bit edge messages back and forth between a check engine and a bit engine). The memory requirements and memory management required to handle these check-edge and bit-edge messages would be very difficult to handle when handling relatively large block sizes in an LDPC code environment. There is thus a need in the art and there continues to be a need for a better means of decoding LDPC coded signals to extract the information encoded therein.

In addition, when the size of the low density parity check matrix H for decoding the LDPC encoded signal reaches a predetermined certain size, the interconnectivity between the first and second processing modules (e.g., the check engine and the bit engine) will be significantly increased.

Disclosure of Invention

The apparatus and methods of the present invention are further described in the following brief description of the drawings, detailed description of the invention, and claims.

According to an aspect of the present invention, there is provided a decoder for decoding an LDPC (low density parity check) encoded signal, the decoder comprising:

a plurality of memories;

a plurality of bit engines, and each of the plurality of bit engines is for connecting to at least one of the plurality of memories;

a plurality of verification engines, each of the plurality of verification engines for coupling to at least one of the plurality of memories; and

a plurality of Multiplexers (MUXs) to:

selectively decoding the plurality of bits during a decoding process of the first LDPC coded signal

The engine and the plurality of verification engines are coupled to a first selected memory of the plurality of memories;

and

selectively decoding the plurality of bits during a decoding process of the second LDPC coded signal

The engine and the plurality of verification engines are coupled to a second selected memory of the plurality of memories; and wherein:

the plurality of memories comprises a predetermined number of memories for representing a plurality of non-zero sub-matrices of a plurality of LDPC matrices corresponding to a plurality of LDPC codes;

the decoder is configured to decode the first LDPC coded signal corresponding to a first LDPC matrix of the plurality of LDPC matrices to generate a best estimate of bits encoded within the first LDPC coded signal; and

the decoder is configured to decode the second LDPC encoded signal corresponding to a second LDPC matrix of the plurality of LDPC matrices to generate a best estimate of bits encoded within the second LDPC encoded signal.

Preferably, a part of the memories within the plurality of memories is determined by superimposing a plurality of non-zero submatrices among a plurality of LDPC matrices corresponding to a plurality of LDPC codes on each other.

Preferably, a portion of the memories within the plurality of memories is determined by performing a greedy, depth (depth) search on a superposition of a plurality of non-zero submatrices of a plurality of LDPC matrices corresponding to the plurality of LDPC codes.

Preferably, a part of memories in the plurality of memories is determined by performing a greedy, deep search on a superposition of a plurality of non-zero submatrices in a plurality of LDPC matrices corresponding to a plurality of LDPC codes;

and is

The first greedy, deep search considers, at least in part, a column affine metric (column affine) representing connectivity of a column in the first LDPC matrix to at least another column in the first LDPC matrix and a column in the second LDPC matrix.

Preferably, the layout of the plurality of memories within the communication device is based on a merge pattern (mergepattern) generated by considering, at least in part, a column affine metric representing connectivity of a column in the first LDPC matrix to at least another column in the first LDPC matrix and a column in the second LDPC matrix.

Preferably, the plurality of memories includes a plurality of merge memories, one of which corresponds to a first non-zero sub-matrix of the first LDPC matrix and also corresponds to a second non-zero sub-matrix of the second LDPC matrix.

Preferably, the first LDPC matrix of the plurality of LDPC matrices comprises a first plurality of non-zero sub-matrices;

the second LDPC matrices of the plurality of LDPC matrices comprise a second plurality of non-zero sub-matrices;

and

using one of the plurality of memories when processing a first non-zero submatrix of the first plurality of non-zero submatrices during decoding of the first LDPC coded signal; in the decoding process of the second LDPC coded signal, the one of the plurality of memories is also used when processing a first non-zero submatrix of the second plurality of non-zero submatrices.

Preferably, the first LDPC matrix of the plurality of LDPC matrices comprises a subset of the plurality of non-zero submatrices; and

the second LDPC matrices of the plurality of LDPC matrices include the subset of the plurality of non-zero submatrices and at least one additional non-zero submatrix.

Preferably, one of the plurality of memories is used when a first non-zero submatrix of the first LDPC matrix is used in the decoding of the first LDPC encoded signal and when a second non-zero submatrix of the second LDPC matrix is used in the decoding of the second LDPC encoded signal; and

the positions of the rows and columns of a first non-zero submatrix in the first LDPC matrix are the same as the positions of the rows and columns of a second non-zero submatrix in the second LDPC matrix.

Preferably, one of the plurality of memories is used when decoding the first LDPC encoded signal using a first non-zero sub-matrix of the first LDPC matrix and when decoding the second LDPC encoded signal using a second non-zero sub-matrix of the second LDPC matrix;

the first non-zero submatrix comprises a first row and a first column in the first LDPC matrix;

and

the second non-zero submatrix includes a second row and a second column in the second LDPC matrix.

Preferably, during the processing of the bit node, one of the multiplexers connects one of the bit engines to one of the memories; and

during processing of the check node, the one of the plurality of multiplexers connects one of the plurality of check engines to the one of the plurality of memories.

Preferably, the decoder is implemented in an integrated circuit.

Preferably, the decoder is implemented in a communication device for receiving the first LDPC coded signal or the second LDPC coded signal from a communication channel; and

the communication device is implemented in at least one of: satellite communication systems, wireless communication systems, wired communication systems, and fiber optic communication systems.

a plurality of memories;

a plurality of bit engines, and each of the plurality of bit engines is connected to at least one of the plurality of memories;

a plurality of verification engines, each of the plurality of verification engines coupled to at least one of the plurality of memories; and

a plurality of Multiplexers (MUXs) to:

connecting a first selected bit engine of the plurality of bit engines to a first selected memory of the plurality of memories during bit node processing when decoding a first LDPC coded signal;

when decoding the first LDPC coded signal, the check node processing is performed

A first selected one of the plurality of verification engines is connected to the first selected one of the plurality of memories;

connecting a second selected bit engine of the plurality of bit engines to a second selected memory of the plurality of memories during bit node processing when decoding a second LDPC encoded signal; and

connecting a second selected one of the plurality of check engines to the second selected one of the plurality of memories during check node processing when decoding the second LDPC coded signal; wherein:

Preferably, the first selected bit engine of the plurality of bit engines is the second selected bit engine of the plurality of bit engines; and

the first selected one of the plurality of verification engines is the second selected one of the plurality of verification engines.

Preferably, said first selected bit engines of said plurality of bit engines are all bit engines of said plurality of bit engines; and

the first selected one of the plurality of verification engines is all of the plurality of verification engines.

Preferably, during decoding of the first LDPC coded signal, the first LDPC coded signal is disconnected from all of the bit engines of the plurality of bit engines and all of the check engines.

Preferably, during decoding of the first LDPC encoded signal, one of the plurality of multiplexers is configured to connect one of the plurality of memories to at least one bit engine;

during decoding of the first LDPC coded signal, the multiplexers of the plurality of multiplexers to connect the memories of the plurality of multiplexers to at least one check engine; and

during decoding of the second LDPC coded signal, the multiplexer of the plurality of multiplexers is to disconnect the memory of the plurality of memories from all bit engines of the plurality of bit engines and all check engines of the check engines.

Preferably, a portion of the memories within the plurality of memories is determined by superimposing the plurality of non-zero submatrices of a plurality of LDPC matrices corresponding to the plurality of LDPC codes on each other.

Preferably, a portion of the memories within the plurality of memories is determined by performing a greedy, deep search of a superposition of the non-zero submatrices of a plurality of LDPC matrices corresponding to the plurality of LDPC codes.

Preferably, a part of memories in the plurality of memories is determined by performing a greedy, deep search on a superposition of the non-zero submatrices in a plurality of LDPC matrices corresponding to the plurality of LDPC codes; and is

The first greedy, deep search considers, at least in part, a column affine metric representing connectivity of a column in the first LDPC matrix with at least another column in the first LDPC matrix and a column in the second LDPC matrix.

Preferably, the layout of the plurality of memories within the communication device is based on a merge pattern generated by considering, at least in part, a column affine metric representing connectivity of a column in the first LDPC matrix with at least another column in the first LDPC matrix and a column in the second LDPC matrix.

and

Preferably, the decoder is implemented in an integrated circuit.

a plurality of memories;

a plurality of Multiplexers (MUXs) to:

connecting the plurality of bit engines to a first selected memory of the plurality of memories during bit node processing when decoding a first LDPC coded signal;

connecting the plurality of check engines to the first selected one of the plurality of memories during check node processing when decoding the first LDPC coded signal;

connecting the plurality of bit engines to a second selected memory of the plurality of memories during bit node processing when decoding a second LDPC coded signal;

connecting the plurality of check engines to the second selected one of the plurality of memories during check node processing when decoding the second LDPC coded signal;

connecting the plurality of bit engines to a third selected memory of the plurality of memories during bit node processing when decoding a third LDPC encoded signal; and

connecting the plurality of check engines to the third selected one of the plurality of memories during check node processing when decoding the third LDPC encoded signal; wherein:

the decoder is configured to decode the first LDPC coded signal corresponding to a first LDPC matrix of the plurality of LDPC matrices to generate a best estimate of bits encoded within the first LDPC coded signal;

the decoder is configured to decode the second LDPC coded signal corresponding to a second LDPC matrix of the plurality of LDPC matrices to generate a best estimate of bits encoded within the second LDPC coded signal; and

the decoder is configured to decode the third LDPC encoded signal corresponding to a third LDPC matrix of the plurality of LDPC matrices to generate a best estimate of bits encoded within the third LDPC encoded signal.

The first greedy, deep search considers, at least in part, column affine metrics representing connectivity of a column in the first LDPC matrix with at least another column in the first LDPC matrix, a column in the second LDPC matrix, and a column in the third LDPC matrix.

Preferably, the layout of the plurality of memories within the communication device is based on a merge pattern generated by considering, at least in part, column affine metrics representing connectivity of columns in the first LDPC matrix with at least another column in the first LDPC matrix, columns in the second LDPC matrix, and columns in the third LDPC matrix.

Preferably, the plurality of memories includes a plurality of merge memories, one of which corresponds to a first non-zero sub-matrix of the first LDPC matrix, also corresponds to a second non-zero sub-matrix of the second LDPC matrix, and also corresponds to a third non-zero sub-matrix of the third LDPC matrix.

the second LDPC matrices of the plurality of LDPC matrices include a subset of the plurality of non-zero submatrices and at least one additional non-zero submatrix.

and

Preferably, the decoder is implemented in an integrated circuit.

Various advantages, aspects and novel features of the invention, as well as details of an illustrated embodiment thereof, will be more fully described with reference to the following description and drawings.

Drawings

The invention will be further described with reference to the accompanying drawings and examples, in which:

fig. 1 and 2 show different embodiments of a communication system;

FIG. 3 illustrates an embodiment of an apparatus for performing LDPC decoding processes;

FIG. 4 illustrates an alternative embodiment of an apparatus for performing LDPC decoding processes;

FIG. 5 illustrates an embodiment of an LDPC coded bipartite graph;

FIG. 6 illustrates an embodiment of an LDPC decoding function;

FIG. 7 illustrates an embodiment of a non-zero submatrix superposition of multiple LDPC matrices;

FIG. 8 illustrates an embodiment of a process to provide memory to accommodate non-zero submatrices of the LDPC matrix superimposed in FIG. 7;

FIGS. 9A and 9B illustrate embodiments of decoding architectures for accommodating the processing of non-zero sub-matrices of the LDPC matrices superimposed in FIG. 7;

FIG. 10 illustrates an embodiment of a decoding architecture for adapting the processing of the non-zero submatrices of the LDPC matrix superimposed in FIG. 7;

FIG. 11 illustrates an embodiment of a decoding architecture for adapting the processing of non-zero sub-matrices of a superimposed LDPC matrix;

FIG. 12 illustrates an alternative embodiment of a decoding architecture for accommodating processing of non-zero sub-matrices of a superimposed LDPC matrix;

FIGS. 13 and 14 illustrate embodiments providing hardware for decoding non-zero submatrices of a superimposed LDPC matrix;

FIG. 15 illustrates an embodiment of a connection between 2 mutually independent memories used for check node processing during the LDPC decoding process;

FIG. 16 illustrates an embodiment of the connectivity of a merge memory used for check node processing during an LDPC decoding process;

FIG. 17 illustrates an embodiment of a method of processing an LDPC coded signal;

FIG. 18 illustrates an embodiment of a method of processing an LDPC coded signal;

FIG. 19 illustrates an embodiment of a method of providing hardware for processing various LDPC coded signals;

FIG. 20 shows an alternative embodiment of a superimposed LDPC matrix.

Detailed Description

LDPC (low density parity check) codes are capacity approaching forward Error Correction Codes (ECCs) and are being adopted by a number of communication standards (e.g., IEEE 802.3an, IEEE802.11n, 802.20, DVB-S2). Related fields of application include magnetic recording, wireless, high-speed data transmission over copper cables and optical fibers.

In one embodiment, the LDPC decoding process is performed using an iterative decoding method, wherein messages (e.g., check edge messages and bit edge messages (and sometimes also referred to as variable edge messages)) are passed back in the future while performing check node processing (also sometimes referred to as check engine processing) and bit node processing (also sometimes referred to as bit engine processing). Sometimes this is referred to as a message passing decoding process, operating on a graphical representation of the encoding (e.g., an LDPC bipartite graph, sometimes also referred to in the art as a "Tanner" graph).

In most communication applications using LDPC coded signals, it is necessary and/or desirable to support multiple codes. Various reasons are included here. In one aspect, various different encodings may be used for different noise environments and/or data characteristics. For example, when the operating environment of the communication system changes (e.g., SNR changes), the particular code being used may also be adaptively changed to accommodate the change in environment, maintaining an acceptable level of performance (e.g., an acceptable high throughput at an acceptably low bit error rate). Alternatively, the transceiver may be designed as a multi-protocol transceiver capable of supporting multiple encodings of different communication protocols. Many applications also operate using LDPC codes, which correspond to LDPC matrices that are sub-matrix based, and some of which use sub-matrices that change in order.

For example, the IEEE802.11n standard specifies 12 different LDPC codes that are based on a sub-matrix structure. Likewise, the IEEE 802.16a standard specifies 24 different LDPC codes, which are also based on a sub-matrix structure. Some aspects of the invention may be used in these application examples.

The method provided by the invention uses the sub-matrix structure of the LDPC code family supported by the decoder, which is an effective way to reduce the implementation complexity of the decoder. In general, the decoder architecture of the present invention enables efficient sharing of memory devices and computational units, at any time the decoder need only support one coding scheme in the LDPC coding family (e.g., when decoding a particular coded signal generated using a particular LDPC code). This may reduce the decoder's requirements for memory space and computational units to a large extent and thus reduce the decoder's size.

In addition, the present invention also provides a method to obtain a "merged" decoder construction from all PDPC code overlays (which must be supported by a particular application) in the LDPC code family using a variety of correlation techniques. This merging technique uses the zero submatrix in the individual coding structure and is based on the proximity metric (metrics based on proximity) in the graph marking of the LDPC coding.

It should be noted that the method provided by the present invention can also be applied to other LDPC decoding configurations, including the aforementioned U.S. provisional patent application 60/958,014 and U.S. utility patent application 11/828,532, which are both entitled LDPC decoding configurations of "Distributed processing LEPC (LoW Density Parity Check) decoder".

The novel approach provided by the present invention uses a single communication device and/or hardware to perform the decoding operations of various LDPC encoded signals. Each of these LDPC coded signals has a corresponding LDPC matrix that can be used to perform the decoding process. In some embodiments, each LDPC matrix corresponding to each LDPC code may have the same number of sub-matrices. In other embodiments, the number of sub-matrices in each LDPC coding matrix may need to be different. The goal of this approach is to minimize the area overhead of the communication device while reducing path congestion therein.

The method may also be used to design a communication device for decoding a plurality of LDPC encoded signals. For example, one embodiment may be used to derive a communication device for decoding an LDPC encoded signal generated according to any one of 12 encoding schemes used by the IEEE802.11n standard. Furthermore, the method of the present invention can be optimized using a way of merging memories (e.g. used when decoding mutually exclusive sub-matrices of different LDPC matrices).

There are various ways to minimize the amount of hardware used to decode multiple LDPC coded signals in a communication device. For example, a straightforward approach involves superimposing each LDPC matrix corresponding to each LDPC encoding on top of each other. Whenever a sub-matrix position results, the superimposed LDPC matrix includes non-zero entries (non-null entries), and then a memory is used to store the sub-matrix position. This direct superposition approach can provide a sufficient hardware environment for decoding multiple LDPC encoded signals. In addition, the additional savings in hardware components resulting from this direct overlay method will be described in later embodiments.

The goal of a digital communication system is to transmit digital data from one location or subsystem to another location or subsystem without error or with an acceptably low error rate. As shown in fig. 1, data may be transmitted over various communication channels within a variety of communication systems: magnetic media, wired, wireless, optical, copper, and other types of media.

Fig. 1 and 2 are schematic diagrams of communication systems 100 and 200, respectively, according to different embodiments of the present invention.

As shown in fig. 1, the communication system 100 includes a communication channel 199 that communicatively couples a communication device 110 (including a transmitter 112 with an encoder 114 and a receiver 116 with a decoder 118) at one end of the communication channel 199 to another communication device 120 (including a transmitter 126 with an encoder 128 and a receiver 122 with a decoder 124) at the other end of the communication channel 199. In some embodiments, both communication devices 110 and 120 may include only one transmitter or only one receiver. Communication channel 199 may be implemented by various different types of media (e.g., satellite communication channel 130 using satellite dishes 132 and 134, wireless communication channel 140 using towers 142 and 144 and/or local antennas 152 and 154, wired communication channel 150, and/or fiber optic communication channel 160 using an electro-optical (E/O) interface 162 and an optical-electrical (O/E) interface 164). In addition, communication channels 199 may be formed by more than one medium being connected together.

To reduce undesired transmission errors in a communication system, error correction and channel coding schemes are commonly employed. In general, these error correction and channel coding schemes include the use of a transmitter side encoder and the use of a receiver side decoder.

In communication system 200 shown in fig. 2, at the transmit end of communication channel 299, information bits 201 are provided to a transmitter 297, which transmitter 297 may perform encoding of these information bits 201 using an encoder and symbol mapper 200 (which may be considered to be distinct functional blocks 222 and 224, respectively) to generate a sequence of discrete-valued modulation symbols 203, which is then provided to transmit driver 230. Transmit driver 230 generates a continuous-time transmit signal 204 using a DAC (digital-to-analog converter) 232 and then passes through a transmit filter 234 to generate a filtered continuous-time transmit signal 205 that is substantially suitable for communication channel 299. At the receiving end of communication channel 299, continuous-time received signal 206 is provided to AFE (analog front end) 260, AFE 260 including receive filter 262 (generating filtered continuous-time received signal 207) and ADC (analog-to-digital converter) 264 (generating discrete-time received signal 208). A metric generator (metric generator)270 computes symbol metrics (symbol metrics)209, which are used by a decoder 280 to make a best estimate 210 of the discrete-valued modulation symbols and the information bits encoded therein.

The decoder in the foregoing embodiments has various features of the present invention. In addition, some of the figures and associated descriptions that follow describe other and specific embodiments of devices, systems, functionality, and/or methods in support of the present invention (some of which are described in greater detail). One particular type of signal that is processed in accordance with the present invention is an LDPC coded signal. Before giving a more detailed introduction, the LDPC code is briefly described.

FIG. 3 illustrates one embodiment of an apparatus 300 to perform LDPC decoding processing. The apparatus 300 includes a processing module 320 and a memory 310. The memory 310 is connected to the processing module 320, and the memory 310 is used to store operation instructions that enable the processing module 320 to perform various functions. The processing module 320 is used to perform and/or control the manner in which LDPC decoding processing is performed in accordance with any of the embodiments described herein or an equivalent thereof.

The processing module 320 may be implemented using a shared processing device, a single processing device, or multiple processing devices. Such a processor may be a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that processes signals (analog and/or digital) based on operational instructions. The memory 310 may be a single memory device or a plurality of memory devices. Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, and/or any device that stores digital information. Note that when the processing device 320 performs one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions is embedded within the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry.

If so desired in some embodiments, the manner in which the LDPC decoding process is performed (e.g., the portion, module, and/or functional module that moves from the check engine to the bit engine) can be provided from the apparatus 300 to the communication system 340 that performs LDPC encoding using the desired LDPC code. For example, information corresponding to the LDPC code being used (e.g., a parity check matrix of the LDPC code) may also be provided from the processing module 320 to any communication device 330 within the communication system 340. In addition, in which manner the LDPC code to be executed within any one of the communication devices 330 within the communication system 340 is to be executed, may also be provided from the processing module 320.

If desired, processing module 320 may be designed to generate various ways of performing LDPC decoding in accordance with various needs and/or expectations. In some embodiments, the processing module 320 selectively provides different information (e.g., information corresponding to different LDPC codes, etc.) to different communication devices and/or communication systems. Thus, different communication links between different communication devices may employ different LDPC codes and/or the manner in which LDPC decoding is performed. It is understood that the processing module 320 can also provide the same information to each of the different communication devices and/or communication systems without departing from the scope and spirit of the present invention.

Fig. 4 shows an apparatus 400 for performing LDPC decoding processing according to another embodiment. The apparatus 400 includes a processing module 420 and a memory 410. The memory 410 is coupled to the processing module 420, and the memory 410 is used to store operating instructions that enable the processing module 420 to perform various functions. Processing module 420 (served by memory 410) may be implemented as a device capable of performing any of the functions of the various modules and/or functional blocks described herein. For example, processing module 420 (served by memory 410) may be implemented as an apparatus for performing and/or controlling the manner in which LDPC decoding processing is performed in accordance with any of the embodiments described herein or an equivalent thereof.

The processing module 420 may be implemented using a shared processing device, a single processing device, or multiple processing devices. Such a processor may be a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, logic circuitry, analog circuitry, digital circuitry, and/or any device that processes signals (analog and/or digital) based on operational instructions. The memory 410 may be a single memory device or a plurality of memory devices. Such a memory device may be a read-only memory, random access memory, volatile memory, non-volatile memory, static memory, dynamic memory, flash memory, and/or any device that stores digital information. Note that when the processing device 420 performs one or more of its functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions is embedded within the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry.

If desired in some embodiments, the apparatus 400 may be any type of communication device 430, or any portion of such a communication device 430. The communication device 430, including the processing module 420 and the memory 410, may be implemented within any communication system 440. It is also noted that the various embodiments of LDPC decoding processes and/or operating parameter modifications pursuant to LDPC decoding processes and their various equivalent embodiments in the present application are applicable to a wide variety of types of communication systems and/or communication devices.

FIG. 5 is a schematic diagram of an LDPC code bipartite graph 500. LDPC bipartite graphs are also known in the industry as Tanner graphs (Tanner graphs). An LDPC code is considered to be a code having a binary parity check matrix such that almost all elements of the matrix are zero values (e.g., the binary parity check matrix is a sparse matrix). For example, H ═ H_ij)_MxNIs considered to be an LDPC code parity check matrix of block length N.

The LDPC code is a linear block code, so the set x ∈ C of all codewords is distributed within the null space of the parity check matrix H.

(1)

For LDPC codes, H is a sparse binary matrix of dimensions m × n. Each row of H corresponds to a parity check, a set of elements H_ijIndicating that data symbol j participates in parity i. Each column of H corresponds to a code character number.

For each codeword x, there are n symbols, where m are parity symbols. Thus, the coding rate r is given by:

r＝(n-m)/n(2)

the row and column weights are defined as the number of collection elements for a given row or column of H, respectively. The set elements of H are selected to meet the performance requirements of the encoding. The number of 1's in the ith column of the parity check matrix is denoted as d_v(i) The number of 1's in the j-th row of the parity check matrix is represented as d_c(j) In that respect If for all i, d_v(i)＝d_vFor all j, d_c(j)＝d_cSuch an LDPC code is then called (d)_v，d_c) Regular LDPC codes, otherwise known as irregular LDPC codes.

For the introduction of LDPC codes, reference is made to the following references:

[1]R.Gallager，Low-Dentisy Parity-Check Codes，Cambridge，MA：MITPress，1963.

[2]R.G. Gallager，“Low dentisy parity check codes，”IRE Trans.Info.Theory.Vol.IT-8，Jan.1962，pp.21-28.

[3] M.G.Luby，M.Mitzenmacher，M.A.Shokrollahi，D.A.Spielman，and V.Stemann.“Practical Loss-Resilient Codes”，Proc.29^th Symp.On Theory OfComputing，1997，pp.150-159.

the regular LDPC code may be represented as a bipartite graph 500 with the left nodes of the parity check matrix being code bit variables (or "variable nodes" (or "bit nodes") 510 in the bit decoding method for decoding LDPC encoded signals) and the right nodes being check equations (or "check nodes" 520). A bipartite graph 500 (or referred to as a tanner graph 500) of an LDPC code defined by H may be defined by N variable nodes (e.g., N bit nodes) and M check nodes. Each of the N variable nodes 510 has an exact d_v(i) An edge (e.g., edge 530) connecting bit nodes, e.g., v_i512 and one or more check nodes (within the M check nodes). The edge 530 shown in the figure connects the bit nodes v_i512 and check node c_j522. D is_vSide (e.g. d)_v514 shown) is added to the total amount of the (c) d)_vCalled degree i of the variable node. Similarly, each check node in M check nodes 520 has an exact d_c(j) Side (e.g. d)_c524) that are connected to one or more variable nodes (or bit nodes) 510. Number of the sides d_cReferred to as degree j of the check node.

Variable node v_i(or bit node b)_i)512 and check node c_jThe edge 530 between 522 may be defined as e ═ i, j. On the other hand, however, given an edge e ═ j, the nodes of that edge can be represented as e ═ (v (e), c (e)) (or e ═ b (e), c (e))). Alternatively, the edges in the bipartite graph correspond to the Collection elements of H, where the Collection elementsVegetarian food_jiIndicating that an edge connects a bit (e.g., variable) node i and a parity node j.

Suppose given variable node v_i(or bit node b)_i) The slave node v can be connected_i(or bit node b)_i) The emitted set of edges is defined as E_v(i) (E/v (E) i } (or E)_b(i) { e/b (e) ═ i }). These edges are referred to as bit edges and the messages corresponding to these bit edges are referred to as bit edge messages.

Suppose a check node c is given_jThe slave node c_jThe emitted set of edges is defined as E_c(j) J } of { e/c (e) ═ j }. These edges are referred to as check edges and the messages corresponding to these check edges are referred to as check edge messages. Then, the derived result is | E_v(i)|＝d_v(or | E)_b(i)|＝d_b) And | E_c(j)|＝d_c。

Generally, any code that can be represented by a bipartite graph is characterized. It is noted that irregular LDPC codes may also be represented by bipartite graphs. However, the degree of each group of nodes within an irregular LDPC code may be selected according to some distribution. Thus, two different variable nodes for irregular LDPC codesAnd|E_v(i₁) | may not be equal to | E_v(i₂) L. This relationship is also true for two check nodes. The concept of irregular LDPC codes was first described in the above reference [3]The introduction is given in.

In summary, by way of illustration of LDPC codes, the parameters of LDPC codes can be defined by degrees of distribution, as described in the above reference [3] by m.luby et al, and the following references are also described in relation thereto:

[4]T.J.Richardson and R.L. Urbanke，“The capacity of low-densityparity-check code under message-passing decoding”，IEEE Trans.Inform.Theory，Vol.47，No.2，Feb.2001，pp.599-618.

this distribution can be described as follows:

by λ_iFraction, p, representing edges transmitted from a variable node of degree i_iRepresenting the fraction of edges transmitted from check nodes of degree i, the degree distribution pair (λ, ρ) is defined as follows:

andwherein M is_vAnd M_cAnd respectively representing the maximum degrees of the variable nodes and the check nodes.

Although various embodiments described herein employ regular LDPC codes, it is noted that the features of the present invention apply to both regular and irregular LDPC codes.

It is also noted that most embodiments described in this application use the nomenclature "bit node" and "bit edge message" or equivalent expressions. But generally in the prior art of LDPC decoding, "bit nodes" and "bit edge messages" are also referred to as "variable nodes" and "variable edge messages", and thus, the bit values (or variable values) are those values that are attempted to be estimated. Both of these designations may be used herein.

FIG. 6 illustrates one embodiment of an LDPC decoding function 600. In order to perform decoding of an LDPC coded signal having an m-bit signal sequence, the functional blocks shown in fig. 6 are employed. Generally, a continuous-time signal (continuous-time signal) is received from a communication channel, as shown by reference numeral 601. The communication channel may be any type of channel including, but not limited to, a wired communication channel, a wireless communication channel, a fiber optic communication channel, a read channel of an HDD, or other type of communication channel capable of carrying a continuous-time signal that has been encoded using an LDPC code.

An Analog Front End (AFE)610 performs any initial processing on the continuous-time signal (e.g., by performing one or more of filtering (analog and/or digital), gain adjustment, etc.) and performs digital sampling, thereby generating a discrete-time signal 611. The discrete-time signal 611 is also referred to as a digital signal, a baseband signal, or other nomenclature known in the art. Typically, the discrete-time signal 611 is divided into I, Q (in-phase, quadrature) values of the signal.

The metric generator 620 receives the discrete-time signal 611 (e.g., which includes I, Q values) and computes corresponding bit metrics and/or log-likelihood ratios (LLRs) 621, which correspond to the received values within the discrete-time signal 611. In some embodiments, the computation of these bit metrics/LLR symbol metrics 621 is a two-step process in which the metric generator 620 first computes the symbol metrics corresponding to the symbols of the discrete-time signal 611, and the metric generator then uses the symbol metrics to decompose these symbol metrics into bit metrics/LLR 621. These bit metrics/LLRs 621 are then used by the bit engine 630 to initialize bit edge messages (e.g., as shown by reference numeral 629) that are to be used when performing the iterative decoding process 635 of the LDPC encoded signal (e.g., as performed by the bit engine 630 and the check engine 640).

The log-likelihood ratio (LLR) has a value of λ_iThe value of the corresponding received symbol is y_iFor each variable node i, bit edgesThe initialization of the message may be defined as follows:

(3)

likewise, at the bit node, bit engine 630 uses the most recently updated bit-edge message to compute the corresponding soft information for the bit (e.g., as shown by soft information 632). However, typically multiple decoding iterations are performed, and thus the initialized bit-edge message is passed to the check engine 640, where the check engine 640 updates the check-edge message with the initialized bit-edge message during the first decoding iteration.

At each check node, the LDPC decoding process forms a parity check result (XOR) on the sign (sign) of the inbound message. This is performed by finding the XOR of the sign of each outbound message as the sign of the corresponding inbound message with the parity result.

The outbound message reliability from check node j to bit (e.g., variable) node i is then calculated according to:

(4)

in some desirable embodiments, this calculation is performed in the log domain to convert the multiplication into an addition, as follows:

(5)

thereafter, bit engine 630 receives the updated edge messages (e.g., as shown by check edge message 641) from check engine 640 and updates the bit edge messages with them. Also, the bit engine 630 uses the bit metrics/LLRs 621 received from the metric generator 620 in performing the update of the bit edge message according to the LDPC decoding. These updated check edge messages 641 are then transmitted back to the bit nodes (e.g., bit engine 630) where the soft information 632 for the bit is computed using the bit metrics/LLRs 621 and the current iteration values of the check edge messages. At each bit (e.g., variable) node, the computation of soft information includes forming a sum of LLRs for received symbols within an inbound message (e.g., check edge message 641) from a check node. Decoded bitsGiven by the sign (sign) of the sum found. Each outbound message for the next decoding iteration is calculated by subtracting the corresponding inbound message from the sum. To continue the iterative decoding process 635, these bit-edge messages 631 are updatedAnd then passed to the verification engine 640.

And then performs another decoding iteration. At the check node, the check engine 640 receives the updated bit edge message 631 transmitted from the bit node (e.g., from the bit node 630) and updates the check edge message accordingly. The updated check edge message 641 is then communicated back to the bit node (e.g., bit engine 630) where the soft information 632 for the bit is computed using the bit metrics/LLRs 621 and the current iteration value of the check edge message. Thereafter, using the soft information 632 for this just calculated bit, the bit engine 630 updates the bit-edge message again with the previous value of the check-edge message (from the just previous iteration). The iterative process 635 continues between bit nodes and check nodes, depending on the LDPC code bipartite graph employed in encoding the signal being decoded.

These iterative decoding process steps performed by bit node engine 630 and check node engine 640 are repeated until a stopping criterion is met, as indicated by reference numeral 661 (e.g., after all syndromes of the LDPC code have been equal to zero (e.g., all parity checks have been met) after a predetermined or adaptively determined number of iterations have been performed, and/or other stopping criteria have been met). Another way for LDPC decoding to stop is when the current estimate of the LDPC codewordStopping when the following relationship is satisfied:

soft information 632 is generated in bit engine 630 during each decoding iteration. In this embodiment shown in the figure, the soft information 632 may be provided to a hard limiter (hard limiter)650 that makes a hard decision, and the hard information (e.g., hard/best estimate 651) may be provided to a syndrome calculator 660 to determine whether the syndromes of the LDPC code are all equal to zero. That is, the syndrome calculator 660 determines whether each syndrome associated with the LDPC code is equal to zero based on the current estimate of the LDPC codeword.

When the syndrome is not equal to zero, the iterative decoding process 635 is resumed, updating and passing the bit edge messages and check edge messages between the bit node engine 630 and check node engine 640 as appropriate. After all steps of the iterative decoding process are performed, a hard/best estimate 651 for the bit is output based on the soft information 632.

It is also important to note that for good decoding performance, it is important that the length of the cycle period in the bipartite graph is as long as possible. Short cycle periods, such as 4 cycles, may degrade the performance of the message-passing decoding method used to decode LDPC numbered signals.

While the mathematical calculations of the message passing decoding method include hyperbolic and logarithmic functions (see equation (5)), in a hardware implementation, these functions can also be approximated by look-up tables (LUTs) or directly by logic gates. Mathematical calculations involve only addition, subtraction and XOR operations. The number of bits required in a fixed-point implementation is determined by the required coding performance, the speed of decoder convergence and whether an error floor (error floor) has to be suppressed, as described in reference [5 ].

[5]Zhang，T.，Wang，Z.，and Parhi，K.，“On finite precision implementationof low density parity check codes decoder”，Proceedings of ISCAS，Sydney，Australia，May 2001，pp 202-205.

FIG. 7 illustrates an embodiment 700 of non-zero submatrix superposition of multiple LDPC matrices. Embodiment 700 describes two separate LDPC matrices (code 1, LDPC matrix 0 and code 2, LDPC matrix 720) corresponding to the two separate LDPC codes. LDPC matrices 710 and 720 each include 4 sub-matrices, two of which are zero sub-matrices and two of which are non-zero sub-matrices (e.g., containing more than one non-zero element).

The code 1, LDPC matrix 710 comprises a non-zero submatrix 711 and a non-zero submatrix 712; code 2, LDPC matrix 720 includes a non-zero submatrix 721 and a non-zero submatrix 722. The superposition of LDPC matrices 710 and 720 results in a superposition LDPC matrix 730. As shown, non-zero submatrix 711 and non-zero submatrix 712 are at the same position in the superposition LDPC. In this embodiment, only one non-zero submatrix remains in the superimposed LDPC matrix 730.

FIG. 8 illustrates an embodiment 800 of memory provisioning to accommodate the processing requirements of the non-zero submatrices of the superimposed LDPC matrix 730 illustrated in FIG. 7. A single memory construct for performing decoding processing for each LDPC code in the superimposed LDPC matrix 730 may employ either a three memory 810 construct (shown as including memory 811, memory 812, and memory 813) or a two memory construct (shown as including memory 821 and memory 822). In any embodiment, each memory may be selectively coupled to the bit engine and the check engine to perform bit node processing and check node processing, respectively, to update the bit edge messages and the check edge messages.

Fig. 9A and 9B show embodiments 901 and 902 of a decoding apparatus for processing non-zero submatrices in the superimposed LDPC matrix of fig. 7.

Referring to fig. 9A, this embodiment includes three memories (i.e., a memory 811, a memory 812, and a memory 813). The bit metrics/LLRs are provided to a plurality of bit engines (e.g., bit engine 931 and bit engine 932). The switching module 991 is coupled between the bit engine 931 and 932 and the memory 811 and 813. Another switching engine 992 is connected between verification engine 921-922 and memory 811-813.

It is noted that switching module 991 (as well as the other switching modules described herein) may be implemented using a Multiplexer (MUX) having multiple input/output terminals, multiple MUXs, or other means that allow selective connection between memory and bit engine and memory and check engine.

In decoding LDPC encoding 1, there is a memory unused (e.g., memory 812 as shown in the figure) and sub-matrix 711 is processed using memory 811, sub-matrix 712 is processed using memory 813, or vice versa.

Alternatively, a single switching module may be used (e.g., verification engine 921-922 may be connected to switching module 991).

After performing the appropriate bit node processing and check node processing and satisfying the stopping criterion, the bit engine 931 and 932 operations generate soft information from which an optimal estimate of the coded bits in the LDPC coded signal coded according to code 1 can be derived.

Referring to fig. 9B, in decoding LDPC encoding 2, there is again a memory unused (e.g., memory 813 as shown), and submatrix 721 is processed using memory 811, submatrix 722 is processed using memory 812, or vice versa.

Also alternatively, a single switching module may be used (e.g., verification engine 921-922 may be connected to switching module 991).

After performing the appropriate bit node processing and check node processing and satisfying the stopping criterion, the bit engine 931 and 932 operations generate soft information from which an optimal estimate of the coded bits in the LDPC coded signal coded according to code 2 can be derived.

The embodiment of fig. 9A and 9B shows a straightforward superposition approach, where three separate memories are used. Hereinafter, an LDPC coded signal coded according to the same two LDPC codes may be decoded using a configuration having only two memories.

Fig. 10 shows a schematic diagram of an embodiment of a decoding apparatus for processing the non-zero submatrices of the superimposed LDPC matrix 730 of fig. 7. This embodiment shows how the same LDPC matrices 710 and 720 are decoded with only two memories (as opposed to using three memories). As shown, sub-matrix 712 (of LDPC matrix 710) and sub-matrix 722 (of LDPC matrix 720) are not at the same sub-matrix position in each LDPC matrix 710 and 720. In each LDPC matrix 710 and 720, the two sub-matrix positions are mutually exclusive (mutuallyexclusive). Therefore, it is possible to perform the decoding process on the submatrix 712 in the decoding process of the first LDPC-coded signal encoded according to encoding 1 and perform the decoding process on the submatrix 722 in the decoding process of the first LDPC-coded signal encoded according to encoding 2 using a separate memory (e.g., a merged memory).

Regarding the merged memory, if a certain memory is not used by the LDPC encoding, it is apparent that the memory can be removed. Thus, the memory need only be provided for those sub-matrices with non-zero elements in the resulting superimposed LDPC. Moreover, each memory also has at least one non-zero LDPC code active therein (e.g., for decoding the LDPC code).

As mentioned above, higher efficiency may be obtained by incorporating memory elements corresponding to mutually exclusive non-zero sub-matrices. The set of memories storing the mutually exclusive activity encoding sets may be combined into a single memory. The greater the amount of memory in which the mutually exclusive active code sets are stored (which can be determined appropriately), the greater the degree of merging that can be achieved and the greater the hardware savings (e.g., reduced memory usage).

Referring to fig. 10, this embodiment includes only two memories (i.e., memory 1011 and memory 1012). The bit metrics/LLRs are provided to a plurality of bit engines (e.g., bit engine 1031 and bit engine 1032). The switching module 1091 is coupled between the bit engines 1031- & 1032 and the memories 1011- & 1012. Another switching engine 1092 is coupled between verification engine 1021 and storage 1011 and 1012.

As with another embodiment, it is noted that the switching module 1091 (as well as the other switching modules described herein) may be implemented using a Multiplexer (MUX) having multiple input/output terminals, multiple MUXs, or other means that allow selective coupling between the memory and the bit engine and the memory and the check engine.

In decoding LDPC code 1, both memories 1011 and 1012 are in use. The memory 1011 is used for processing the sub-matrix 711 and the memory 1012 is used for processing the sub-matrix 712, or vice versa.

After performing the appropriate bit node processing and check node processing and satisfying the stopping criteria, bit engine 1031-1032 operates to generate soft information from which an optimal estimate of the code bits in the LDPC coded signal encoded according to code 1 can be derived.

Also, in decoding the LDPC code 2, both memories 1011 and 1012 are used. Memory 1011 is used to process sub-matrix 721 and memory 1012 is used to process sub-matrix 722, or vice versa.

After performing the appropriate bit node processing and check node processing and satisfying the stopping criteria, bit engine 1031-1032 operates to generate soft information from which an optimal estimate of the code bits in the LDPC coded signal encoded according to code 2 can be derived.

Alternatively, as in another embodiment, a single switching module may be used (e.g., check engine 1021-.

As shown, a merge memory (e.g., memory 1012 as shown) may be used to perform processing for non-zero submatrix 712 for code 1 and to perform processing for non-zero submatrix 722 for code 2. The principle of using a merged memory to perform the decoding process of mutually exclusive non-zero sub-matrices can also be extended to larger LDPC matrices.

FIG. 11 shows a schematic diagram of an embodiment 1100 of a decoding apparatus for processing non-zero submatrices of a superimposed LDPC matrix. This embodiment can be generalized to be applied to decoding processing of an encoded signal of an LDPC matrix of any desired size.

Referring to fig. 11, this embodiment includes a plurality of memories 1110 (i.e., memories 1111-. The bit metrics/LLRs are provided to a plurality of bit engines (e.g., bit engine 1131 and bit engine 1133). The switching module 1191 is coupled between the bit engines 1131-1133 and the plurality of memories 1110. Another switching engine 1192 is coupled between verification engine 1121 and 1123 and the plurality of memories 1110.

Also, as with another embodiment, it is noted that the switching module 1191 (as well as the other switching modules described herein) may be implemented using a Multiplexer (MUX) having multiple input/output terminals, MUXs, or other devices that allow selective connection between the memories 1110 and the bit engines 1131-1133 and the memories 1110 and the check engines 1121-1123.

In decoding a first signal encoded in accordance with a first LDPC encoding, a first subset of memory 1110 is used to process non-zero submatrices of an LDPC matrix of the first LDPC encoding.

In decoding a second signal encoded pursuant to a second LDPC encoding, a second subset of memory 1110 is used to process non-zero submatrices of the LDPC matrix of the second LDPC encoding.

In decoding a third signal encoded in accordance with a third LDPC encoding, a third subset of memory 1110 is used to process non-zero submatrices of the LDPC matrix of the second LDPC encoding.

And so on.

In some embodiments, the same number of multiple memories 1110 are used in decoding each encoded signal. In other embodiments, different amounts of multiple memories are used in decoding different encoded signals. For example, in various embodiments, each of the first subset, the second subset, and the third subset described above may include the same amount of memory, or include a different amount of memory.

The switching modules 1191 and 1192 are configured to ensure proper communication between the multiple bit engines 1131 and 1133 and the multiple storages 1110 to obtain the check edge message required during the execution of the update bit edge message, and the switching modules 1191 and 1192 are configured to ensure proper communication between the multiple check engines 1121 and 1123 and the multiple storages 1110 to obtain the bit edge message required during the execution of the update check edge message.

After performing the appropriate bit node processing and check node processing and satisfying the stopping criteria, the bit engine 1131 & 1132 operation generates soft information from which an optimal estimate of the coded bits in the LDPC coded signal that were coded according to the particular LDPC code of interest can be derived.

FIG. 12 shows a schematic diagram of another embodiment 1200 of a decoding apparatus for processing non-zero submatrices of a superimposed LDPC matrix.

Referring to fig. 12, this embodiment includes a plurality of memories 1210 (i.e., memories 1211-1213). The bit metrics/LLRs are provided to a plurality of bit engines (e.g., bit engine 1231 and bit engine 1233). The switch module 1291 is coupled between the plurality of bit engines 1231 and 1233 and the plurality of memories 1210. The same switching engine 1191 also provides selectable connectivity between the verification engine 1221 and 1223 and the plurality of memories 1210.

In decoding a first signal encoded in accordance with a first LDPC encoding, a first subset of memory 1210 is used to process non-zero submatrices of an LDPC matrix of the first LDPC encoding.

In decoding a second signal encoded in accordance with a second LDPC encoding, a second subset of memory 1210 is used to process non-zero submatrices of an LDPC matrix of the second LDPC encoding.

In decoding a third signal encoded in accordance with a third LDPC encoding, a third subset of memory 1210 is used to process non-zero submatrices of the LDPC matrix of the second LDPC encoding.

And so on.

In some embodiments, the same number of multiple memories 1210 are used in decoding each encoded signal. In other embodiments, different amounts of multiple memories are used in decoding different encoded signals. For example, in various embodiments, each of the first subset, the second subset, and the third subset described above may include the same amount of memory, or include a different amount of memory.

The switching module 1291 is configured to ensure proper communication between the plurality of bit engines 1231 and 1233 and the plurality of memories 1210 for obtaining the check edge message required during the execution of the update bit edge message, and the switching module 1291 is further configured to ensure proper communication between the plurality of check engines 1221 and 1223 and the plurality of memories 1210 for obtaining the bit edge message required during the execution of the update check edge message.

After performing the appropriate bit node processing and node check processing, and encountering a stopping criterion, the bit engine 1231-1232 will generate soft information from the best estimate, which may be made from the LDPC coded signal encoded by the LDPC code of particular interest.

Fig. 13 and 14 show hardware instructions for decoding non-zero submatrices of a superimposed LDPC matrix.

Referring to fig. 13, each LDPC encoded signal decoded according to embodiment 4300 has the same number of non-zero submatrices. In decoding an LDPC coded signal encoded in accordance with each LDPC code, the only difference is that the subset of memory employed for each coded signal is different.

For example, when decoding a signal encoded according to code 1, the corresponding LDPC matrix includes 'X' non-zero sub-matrices, and all provided bit engines (provided bit engines) are available for bit node processing. All provided verification engines are used for verification processing. The total number of memories is 'Y', where 'X' memories are used, i.e. subset 1 of these 'Y' memories.

When decoding a signal encoded according to code 2, the corresponding LDPC matrix comprises 'X' non-zero sub-matrices, all provided bit engines are available for bit node processing. All provided check engines are used for the check process. The total number of memories is 'Y', where 'X' memories are used, i.e. subset 2 of these 'Y' memories. And so on as shown in the figure.

It can be seen that in embodiment 1300, when decoding different LDPC coded signals, the only difference is the difference in the subset of memories used.

When decoding each LDPC coded signal encoded according to each LDPC code in fig. 13, the number of bit engines and check engines used is the same.

Referring to fig. 14, an embodiment 1400 shows an embodiment employing different degrees of parallelism (variable dimensions of parallelisms). This embodiment 1400 shows better variability and flexibility in decoding different LDPC coded signals.

For example, when decoding a signal encoded according to code a, the corresponding LDPC matrix includes 'a 1' non-zero submatrices. The a2 subset of the total 'M' provided bit engines is available for bit node processing, the a3 subset of the total 'L' provided check engines is available for node check processing, and either 'a 2' or 'a 3' of the total 'Z' available memory, i.e., the subset a4 of the 'Z' memories, can be used.

When decoding a signal encoded according to code b, the corresponding LDPC matrix includes 'b 2' non-zero submatrices. The b2 subset of the total 'M' provided bit engines is available for bit node processing, the b3 subset of the total 'L' provided check engines is available for node check processing, and either 'b 2' or 'b 3' of the total 'Z' available memory, i.e., the subset b4 of the 'Z' memories, can be used. And so on as shown in the figure.

For example, in embodiment 1400, each sub-iteration (e.g., bit node processing or node check processing) may be performed using multiple loops. Note that in one example, bit node processing may update a first half of a bit edge message (bit edge messages) using a provided number of bit engines at a first time and may update a second half of the bit edge message using a provided number of bit engines at a second time, which may be considered a semi-parallelism bit node processing method, such that decoding sub-iterations (e.g., bit node processing) are completed in two steps.

In another embodiment, note that in another example of the node check process, a first third of the check-edge messages may be updated using a provided number of check engines in a first time, a second third of the check-edge messages may be updated using a provided number of check engines in a second time, and a last third of the check-edge messages may be updated using a provided number of check engines in a third time. This can be viewed as a parallelism node-check processing method, such that the decoding sub-iteration (e.g., node check processing) is done in three steps in steps.

It will be apparent that numerous modifications may be made to the invention without departing from the scope and spirit thereof, and therefore, the number of cycles taken per sub-iteration may vary depending on the particular embodiment.

Returning to embodiment 1400, each LDPC matrix need not include the same number of non-zero sub-matrices. When decoding a particular LDPC coded signal (when all of the provided memory is not required), the memory for the corresponding zero sub-matrix for a particular LDPC may be off. During decoding of a particular signal, when a particular memory is not in use, the memory may be disconnected (e.g., disconnected) from the rest of the circuit to prevent free memory from interfering with active computation and may save energy. The disconnection of the memory may be achieved by setting an input of each of the variable nodes and check nodes to the memory to 0 (or a maximum value "maxval"), which are respectively connected to the specific unused submatrix (zero submatrix) for decoding the specific code.

Fig. 15 and 16 show embodiments using at least one merge memory (merge memory). In these embodiments, there is a memory that can be used as follows.

Memory a is available when decoding signals encoded according to codes 0 and 1, and is free when decoding other codes.

Memory B is available when decoding signals encoded in accordance with codes 2 and 3, and is free when decoding other codes.

Fig. 15 shows connectivity between 2 mutually exclusive memories for check node processing according to the LDPC decoding process. This embodiment shows how memory a is used when decoding signals encoded according to codes 0 and 1, and shows how memory a is disconnected (e.g., disconnected) from the hardware when decoding signals encoded for other codes. When memory a is not in use, memory a is effectively disconnected (e.g., disconnected) from the rest of the hardware/circuitry when certain signals are decoded to prevent free memory from interfering with active operations and may save energy. The disconnection of the memory may be achieved by setting an input of each of the variable nodes and check nodes to the memory to 0 (or a maximum value "maxval"), which are respectively connected to the specific unused submatrix (zero submatrix) for decoding the specific code.

This embodiment also shows how memory B is used when decoding signals encoded according to codes 2 and 3, and shows how memory B is disconnected (e.g., disconnected) from the hardware when decoding encoded signals of other codes. When memory B is not in use, memory B is effectively disconnected (e.g., disconnected) from the rest of the hardware/circuitry when certain signals are decoded to prevent idle memory from interfering with active operations and may save energy. The disconnection of the memory may be achieved by setting an input of each of the variable nodes and check nodes to the memory to 0 (or a maximum value "maxval"), which are respectively connected to the specific unused submatrix (zero submatrix) for decoding the specific code.

It should be noted that the connection of the variable/bit engine to memories a and B is not shown in the figures, nor is the connection of the variable/bit engine to memory C shown in the following figures. However, after the connectivity of the check engine is shown, those skilled in the art will understand the connectivity of the associated variable/bit engine.

As can be seen, memories A and B may be merged into a single memory C. Next, the memory C is available when decoding signals encoded according to codes 0, 1, 2 and 3, and is free when decoding signals encoded by other codes.

It should be noted here that when the merge memory is provided separately, it can maintain all the emerging connectivity. In the example shown in fig. 15 and 16, the original connectivity of memory a and memory B (fig. 15) may be maintained when memory C is used (fig. 16).

For example, considering an embodiment where memory a and memory B have mutually exclusive sets of codes, and memory a is in a different row of sub-matrices than memory B (e.g., each of memory a and memory B corresponds to a sub-matrix at a different location in the true LDPC matrix), then memories a and B would be connected to different check nodes and could be incorporated into memory C. Likewise, memory C may maintain the connectivity of memory A to the check nodes and may also maintain the connectivity of memory B to the check nodes.

FIG. 16 illustrates an embodiment 1600 of the connectivity of the merged memory for check node processing in accordance with the LPDC decoding process. In a two-step embodiment, 3MUX is employed to allow a single memory C to replace memories A and B.

Fig. 17 shows an embodiment of a method 1700 for processing an LDPC coded signal.

Referring to fig. 17, as shown in block 1710, the method 1700 initially includes receiving a continuous-time signal. As shown in block 1712, the receiving and processing of the continuous-time signal may include performing any necessary down-conversion on the first continuous-time signal to generate a second continuous-time signal. Frequency conversion may be achieved by directly converting the carrier frequency to a baseband frequency. Alternatively, the frequency conversion may be realized by IF (intermediate frequency). In either embodiment, the received continuous-time signal is typically downconverted to a baseband continuous-time signal when the method is performed. Likewise, some type of gain adjustment/gain control may be applied to the received continuous-time signal.

As shown in block 1720, the method 1700 may also include sampling the first (or second) continuous-time signal to generate a discrete signal and extracting I, Q (in-phase, integral) components therefrom. An ADC (analog to digital converter) or similar device may be used to generate a discrete signal from a received continuous-time signal suitably down-converted (and may be filtered, gain-adjusted, etc. processed). The I, Q component of a single sample of the discrete-time signal may also be extracted at this step. Next, as shown in block 1730, method 1700 includes demodulating the I, Q components and may include symbol mapping of the I, Q components (e.g., to a constellation having a mapping of constellation points) to generate a sequence of discrete-valued modulation symbols.

As shown in block 1740, the next step of the method 1700 includes performing an edge message update until a stop criterion is encountered (e.g., a preset number of iterations until all symbols equal 0, or until other stop criteria are encountered). This step can be seen as performing the LPDC decoding according to the various embodiments described above. The LPDC decoding generally includes bit engine processing (as shown in block 1742) for updating bit-edge messages (e.g., variable-edge messages) and check engine processing (as shown in block 1744) for updating check-edge messages.

As shown in block 1746, the method 1700 may also include sampling selected hardware to provide to a selected LDPC code when decoding a particular LPDC encoded signal of interest. For example, the method 1700 is used to perform processing of different LDPC coded signals that are generated using different LDPC codes (and thus have different LDPC matrices, respectively). Depending on the signal being decoded, the method 1700 provides for the selection of appropriate hardware to perform the decoding of the particular LPDC encoded signal of interest.

As shown in block 1750, after encountering a stop criterion, the method 1700 includes making a hard decision (hard decision) based on soft information corresponding to the most recently updated bit-side information. The method 1700 finally includes outputting a best estimate of LDPC coded bits (e.g., LDPC codewords or LDPC code regions) extracted from the received continuous-time signal, including the information bits.

FIG. 18 illustrates an embodiment of a method 1800 for processing an LDPC coded signal.

As shown in block 1810, the method 1800 begins by identifying all LDPC matrices needed to decode all LDPC encoded signals.

Next, as shown in block 1820, the method 1800 generates a superposition of all LDPC matrices (e.g., including a superposition of each sub-matrix position of all LDPC matrices).

Next, as shown in block 1830, the method 1800 provides a memory that accommodates the sub-matrices for each of the superimposed results. This can be done in a number of ways and can include any number of steps. In one embodiment, this includes a greedy, first depth search of the final, superimposed LDPC matrix to determine the number of memories needed (as shown in block 1822).

While polynomial time-merging search algorithms can be employed to obtain memory-provided solutions, they do not always provide a solution from minimal memory. In a 4-node embodiment, the nodes may be considered alphabetical.

Message group	Combining capabilities
		A	B、C
B	A、D
		C	A
D	B

Memory a may be merged with memory B without further merging occurring. The 4-node minimum memory solution may merge memory a and memory B (e.g., to memory E), and merge memory C and memory D (e.g., to memory F).

A first depth search may also be employed to obtain a minimum memory solution, such a first full depth search being exhaustive and the actual minimum memory solution being found. However, certain embodiments show difficulties in using this approach. When it is considered that the tree root of the solution can be adapted to the IEEE802.11n standard and all 12 LDPC codes here (each with its own corresponding LDPC matrix), then the tree root for the IEEE802.11n standard has 2041 branches. The result for the maximum tree depth is about 105. (O (2041)¹⁰⁵) It is impossible to complete the entire search without requiring a large amount of processing and time.

One or more heuristic methods (hearistic) can be employed to make the search for minimal memory requirements (or relatively few memory requirements) and the merging of memory in the resulting superimposed LDPC matrix simpler. The measurements along those rows of column affine may be taken. Additionally, some assumptions that may be used to manage the merged search heuristic include: (1) the variable/bit nodes may be compressed with respect to each other, the check nodes may cover a relatively large area in the resulting superimposed LDPC matrix, and (2) the memory to be provided may be tightly clustered around (rightly clustered) the variable/bit nodes.

The search may sample a heuristic approach where the memories belonging to the columns of the resulting superimposed LDPC matrix are tightly chained and check nodes are connected to different columns of the superimposed LDPC matrix.

The column affine metric may then be generated based on the connections between columns and columns of the particular sub-matrix and other sub-matrices in the resulting superimposed LDPC matrix. As described below in another embodiment, the column affine metric can be used to control/manage greedy depth first search of the resulting superimposed LDPC matrix.

This may also include merging the memory banks with mutually exclusive active code into a merged memory, as shown in block 1824. The method 1800 may also include generating a merge pattern of the memories (e.g., based on greedy, deep-search-first, and mutually exclusive merging), and setting the memories based thereon, as shown in block 1826.

Next, as shown in block 1831, method 1800 decodes the first LDPC coded signal having the first corresponding LDPC matrix using the 1 st subset of the provided memory.

As shown in block 1832, if the LDPC encoded signal is to be decoded, the method 1800 may then use the nth subset of the provided memory to decode the nth LDPC encoded signal having the nth corresponding LDPC matrix.

FIG. 19 illustrates a method 1900 for providing hardware for various LDPC coded signal processing.

The method 1900 begins by identifying all LDPC matrices needed to decode all LDPC coded signals based on the connectivity between each column and the other columns, as shown in block 1910.

The method 1900 then generates a superposition of all LDPC matrices (e.g., including a superposition of each sub-matrix position of all LDPC matrices), as shown in block 1920.

As shown in block 1930, the method 1900 then performs a greedy, deep search of the overlay results to determine the number of memories needed and the set to merge (e.g., merge mode), using column affinity as a metric.

The method 1900 then provides appropriate memory for each sub-matrix of the superimposed results based on the merge mode, as shown in block 1940.

FIG. 20 illustrates an alternative embodiment 2000 of a superimposed LDPC matrix. This embodiment 2000 corresponds to the superposition of 12 individual LDPC matrices to perform a decoding process employing 12 codes in the IEEE802.11n standard. When superimposing 12 separate LDPC matrices (and each of their sub-matrices), there are a total of 205 non-zero sub-matrices in the last occurring superimposed LDPC matrix.

Messages corresponding to each non-zero submatrix may be stored in memory. Checksum bit engines may be implemented such that they can appropriately and selectively read information from or write information to operational memory to extract each of the appropriate non-zero submatrices that may be used to decode a particular signal encoded according to any of the 12 encoding schemes used by the IEEE802.11n standard.

In this embodiment, only 88 of the 205 memories are available at any one time. Of these 205 memories, at least 117 are always free. Notably, a first subset of the 205 memories (88 memories) may be used when decoding the first encoded signal, and a second subset of the 205 memories (88 memories) may be used when decoding the second encoded signal.

The 205 memory amounts provided can be significantly reduced by sampling the merge pattern and the minimum amount of memory (which may not be really the smallest) can be employed by using a greedy, deep search of the first of the final, superimposed LDPC matrix to determine the amount of memory needed. Such a merging pattern is shown in the appendix and can be obtained by greedy depth search of the last superimposed LDPC matrix using column affine as a metric. The merge mode only requires the provision of 102 memories (compared to 205). It can be seen that memory can be saved by about 50% and this will also cause the adjacent paths to be greatly compressed. While in practice a solution may be found that the amount of memory required may be less than 102 memories (e.g., using a first full depth search), it may be found that using 102 provided memories (e.g., found using a greedy depth search) has relatively good area trade-off ratios and signal congestion.

During decoding of a particular signal, when a particular memory is not in use, that memory can be disconnected (e.g., disconnected) from the rest of the circuitry to prevent free memory from interfering with active operations and to conserve energy. The disconnection of the memory may be achieved by setting an input of each of the variable nodes and check nodes to the memory to 0 (or a maximum value "maxval"), which are respectively connected to the specific unused submatrix (zero submatrix) for decoding the specific code.

It should be noted that the multicode approach presented herein can be used on any sub-matrix/sub-clock based LDPC decoder, where the messages corresponding to the sub-matrix/sub-clock are stored in some type of memory (e.g., SRAM, register set, etc.). Furthermore, when trying to obtain a more efficient memory solution, the heuristic method used may be more precisely tuned in terms of back-end execution detail (backend implementation). In other words, depending on the particular application that the multi-code LDPC decoder needs to perform, the heuristic can be tuned more precisely depending on the particular application.

It should be noted that the various modules described herein (e.g., encoders, decoders, processing modules, etc.) may each be a single processing device or multiple processing devices. Such a processing device may be a microprocessor, microcontroller, digital signal processor, microcomputer, central processing unit, field programmable gate array, programmable logic device, state machine, analog circuitry, digital circuitry, and/or any device that processes signals (digital and/or analog) according to operational instructions. The memory may be a single memory device or a plurality of memory devices. Such a memory device may be a read-only memory, random access memory, static memory, dynamic memory, flash memory, and/or any memory that may store digital information. It should be noted that when the processing device performs one or more functions via a state machine, analog circuitry, digital circuitry, and/or logic circuitry, the memory storing the corresponding operational instructions may be embedded within the circuitry comprising the state machine, analog circuitry, digital circuitry, and/or logic circuitry. In such an embodiment, the memory stores instructions and/or steps corresponding to at least some of the steps illustrated herein, which are executed by a processing module coupled to the memory.

The invention has been described above with the aid of method steps illustrating specified functions and relationships. For convenience of description, the boundaries and sequence of these functional building blocks and method steps have been defined herein specifically. However, given the appropriate implementation of functions and relationships, changes in the limits and sequences are allowed. Any such boundaries or sequence of changes should be considered to be within the scope of the claims.

The invention has also been described above with the aid of functional blocks illustrating some important functions. For convenience of description, the boundaries of these functional building blocks have been defined specifically herein. When these important functions are implemented properly, varying their boundaries is permissible. Similarly, flow diagram blocks may be specifically defined herein to illustrate certain important functions, and the boundaries and sequence of the flow diagram blocks may be otherwise defined for general application so long as the important functions are still achieved. Variations in the boundaries and sequence of the above described functional blocks, flowchart functional blocks, and steps may be considered within the scope of the following claims.

Those skilled in the art will also appreciate that the functional blocks described herein, and other illustrative blocks, modules, and components, may be implemented as discrete components, special purpose integrated circuits, processors with appropriate software, and the like.

Furthermore, although the description details are for the purpose of clarity and understanding the above-described embodiments, the present invention is not limited to these embodiments. Any technical solutions known to those skilled in the art to which various changes and equivalents of these features and embodiments are applied will fall within the scope of the present invention.

Introduction to accessories

The combining pattern may be generated in a variety of ways and embodiments to guide the provision of hardware in a device for decoding a plurality of LDPC encoded signals. One possible embodiment involves decoding according to any one of the 12 encoding schemes used by the IEEE802.11n standard.

In this embodiment, it can be seen that only 102 memories are needed when sampling merge searches, whereas 205 memories are needed when a simple overlap-and-add method is used.

Accessories (merge mode)

Uncombined memory, row 0 column 0, code 0(0, 0), code 1(0, 0), code 2(0, 0), code 3(0, 0), code 4(0, 0), code 5(0, 0), code 6(0, 0), code 7(0, 0), code 8(0, 0), code 9(0, 0), code 10(0, 0), code 11(0, 0)

Uncombined memory, row 0 column 2, code 1(0, 2), code 2(0, 2), code 3(0, 2), code 4(0, 2), code 5(0, 2), code 6(0, 2), code 7(0, 2), code 8(0, 2), code 9(0, 2), code 10(0, 2), code 11(0, 2)

Uncombined memory, row 0 column 3, code 1(0, 3), code 2(0, 3), code 3(0, 3), code 5(0, 3), code 6(0, 3), code 7(0, 3), code 9(0, 3), code 10(0, 3), code 11(0, 3)

Uncombined memory, row 0 column 4, code 0(0, 4), code 2(0, 4), code 3(0, 4), code 4(0, 4), code 5(0, 4), code 6(0, 4), code 7(0, 4), code 8(0, 4), code 9(0, 4), code 10(0, 4), code 11(0, 4)

Uncombined memory, row 0 column 7, code 0(0, 7), code 1(0, 7), code 2(0, 7), code 3(0, 7), code 7(0, 7), code 8(0, 7), code 9(0, 7), code 10(0, 7), code 11(0, 7)

Uncombined memory, row 0 column 8, code 0(0, 8), code 3(0, 8), code 4(0, 8), code 5(0, 8), code 6(0, 8), code 7(0, 8), code 8(0, 8), code 9(0, 8), code 11(0, 8)

Uncombined memory, row 0 column 23, code 0(0, 23), code 1(0, 23), code 2(0, 23), code 3(0, 23), code 4(0, 23), code 5(0, 23), code 6(0, 23), code 7(0, 23), code 8(0, 23), code 9(0, 23), code 10(0, 23), code 11(0, 23)

Uncombined memory, row 1 column 0, code 0(1, 0), code 1(1, 0), code 2(1, 0), code 3(1, 0), code 5(1, 0), code 6(1, 0), code 7(1, 0), code 8(1, 0), code 9(1, 0), code 10(1, 0), code 11(1, 0)

Open memory, row 1 column 1, code 1(1, 1), code 2(1, 1), code 3(1, 1), code 4(1, 1), code 5(1, 1), code 6(1, 1), code 7(1, 1), code 8(1, 1), code 9(1, 1), code 10(1, 1), code 11(1, 1)

Uncombined memory, row 1 column 2, code 0(1, 2), code 1(1, 2), code 2(1, 2), code 3(1, 2), code 5(1, 2), code 6(1, 2), code 7(1, 2), code 9(1, 2), code 10(1, 2), code 11(1, 2)

Uncombined memory, row 1 column 4, code 0(1, 4), code 1(1, 4), code 2(1, 4), code 3(1, 4), code 4(1, 4), code 5(1, 4), code 6(1, 4), code 7(1, 4), code 8(1, 4), code 9(1, 4), code 10(1, 4), code 11(1, 4)

Uncombined memory, row 1 column 5, code 0(1, 5), code 3(1, 5), code 6(1, 5), code 7(1, 5), code 9(1, 5), code 10(1, 5), code 11(1, 5)

Uncombined memory, row 1 column 7, code 0(1, 7), code 2(1, 7), code 3(1, 7), code 4(1, 7), code 5(1, 7), code 6(1, 7), code 7(1, 7), code 9(1, 7), code 10(1, 7), code 11(1, 7)

Uncombined memory, row 1 column 8, code 0(1, 8), code 1(1, 8), code 2(1, 8), code 3(1, 8), code 4(1, 8), code 7(1, 8), code 10(1, 8), code 11(1, 8)

Uncombined memory, row 1 column 22, code 0(1, 22), code 1(1, 22), code 2(1, 22), code 3(1, 22), code 4(1, 22), code 5(1, 22), code 6(1, 22), code 7(1, 22), code 8(1, 22), code 9(1, 22), code 10(1, 22), code 11(1, 22)

Uncombined memory, row 1 column 23, code 0(1, 23), code 1(1, 23), code 2(1, 23), code 3(1, 23), code 4(1, 23), code 5(1, 23), code 6(1, 23), code 7(1, 23), code 8(1, 23), code 9(1, 23), code 10(1, 23), code 11(1, 23)

Uncombined memory, row 2 column 0, code 0(2, 0), code 1(2, 0), code 2(2, 0), code 3(2, 0), code 4(2, 0), code 5(2, 0), code 6(2, 0), code 7(2, 0), code 9(2, 0), code 10(2, 0), code 11(2, 0)

Uncombined memory, row 2 column 1, code 1(2, 1), code 2(2, 1), code 3(2, 1), code 5(2, 1), code 6(2, 1), code 7(2, 1), code 8(2, 1), code 9(2, 1), code 10(2, 1), code 11(2, 1)

Uncombined memory, row 2 column 2, code 1(2, 2), code 2(2, 2), code 3(2, 2), code 4(2, 2), code 5(2, 2), code 6(2, 2), code 7(2, 2), code 9(2, 2), code 10(2, 2), code 11(2, 2)

Uncombined memory, row 2 column 3, code 1(2, 3), code 2(2, 3), code 3(2, 3), code 5(2, 3), code 6(2, 3), code 7(2, 3), code 8(2, 3), code 9(2, 3), code 10(2, 3), code 11(2, 3)

Uncombined memory, row 2 column 4, code 0(2, 4), code 2(2, 4), code 3(2, 4), code 4(2, 4), code 5(2, 4), code 6(2, 4), code 7(2, 4), code 8(2, 4), code 9(2, 4), code 10(2, 4), code 11(2, 4)

Uncombined memory, row 2 column 8, code 0(2, 8), code 2(2, 8), code 3(2, 8), code 4(2, 8), code 6(2, 8), code 7(2, 8), code 8(2, 8), code 10(2, 8), code 11(2, 8)

Uncombined memory, row 2 column 21, code 0(2, 21), code 1(2, 21), code 2(2, 21), code 3(2, 21), code 4(2, 21), code 5(2, 21), code 6(2, 21), code 7(2, 21), code 8(2, 21), code 9(2, 21), code 10(2, 21), code 11(2, 21)

Uncombined memory, row 2 column 22, code 0(2, 22), code 1(2, 22), code 2(2, 22), code 3(2, 22), code 4(2, 22), code 5(2, 22), code 6(2, 22), code 7(2, 22), code 8(2, 22), code 9(2, 22), code 10(2, 22), code 11(2, 22)

Uncombined memory, row 3 column 0, code 0(3, 0), code 1(3, 0), code 2(3, 0), code 3(3, 0), code 4(3, 0), code 5(3, 0), code 6(3, 0), code 7(3, 0), code 8(3, 0), code 9(3, 0), code 10(3, 0), code 11(3, 0)

Uncombined memory, row 3 column 1, code 0(3, 1), code 1(3, 1), code 2(3, 1), code 3(3, 1), code 5(3, 1), code 6(3, 1), code 7(3, 1), code 9(3, 1), code 10(3, 1), code 11(3, 1)

Uncombined memory, row 3 column 2, code 1(3, 2), code 2(3, 2), code 3(3, 2), code 5(3, 2), code 6(3, 2), code 7(3, 2), code 9(3, 2), code 10(3, 2), code 11(3, 2)

Uncombined memory, row 3 column 3, code 0(3, 3), code 2(3, 3), code 3(3, 3), code 4(3, 3), code 5(3, 3), code 6(3, 3), code 7(3, 3), code 9(3, 3), code 10(3, 3), code 11(3, 3)

Uncombined memory, row 3 column 4, code 0(3, 4), code 1(3, 4), code 2(3, 4), code 3(3, 4), code 4(3, 4), code 5(3, 4), code 6(3, 4), code 7(3, 4), code 8(3, 4), code 10(3, 4), code 11(3, 4)

Uncombined memory, row 3 column 5, code 0(3, 5), code 2(3, 5), code 3(3, 5), code 5(3, 5), code 6(3, 5), code 7(3, 5), code 8(3, 5), code 9(3, 5), code 10(3, 5), code 11(3, 5)

Uncombined memory, row 3 column 8, code 0(3, 8), code 1(3, 8), code 2(3, 8), code 3(3, 8), code 4(3, 8), code 7(3, 8), code 8(3, 8), code 9(3, 8), code 10(3, 8), code 11(3, 8)

Uncombined memory, row 3 column 20, code 0(3, 20), code 1(3, 20), code 2(3, 20), code 3(3, 20), code 4(3, 20), code 5(3, 20), code 6(3, 20), code 7(3, 20), code 8(3, 20), code 9(3, 20), code 10(3, 20), code 11(3, 20)

Uncombined memory, row 3 column 21, code 0(3, 21), code 1(3, 21), code 2(3, 21), code 3(3, 21), code 4(3, 21), code 5(3, 21), code 6(3, 21), code 7(3, 21), code 8(3, 21), code 9(3, 21), code 10(3, 21), code 11(3, 21)

Uncombined memory, row 4 column 1, code 0(4, 1), code 1(4, 1), code 2(4, 1), code 3(4, 1), code 5(4, 1), code 6(4, 1), code 7(4, 1), code 9(4, 1), code 10(4, 1), code 11(4, 1)

Uncombined memory, row 4 column 2, code 1(4, 2), code 2(4, 2), code 3(4, 2), code 4(4, 2), code 5(4, 2), code 6(4, 2), code 7(4, 2), code 9(4, 2), code 10(4, 2), code 11(4, 2)

Uncombined memory, row 4 column 3, code 1(4, 3), code 2(4, 3), code 3(4, 3), code 6(4, 3), code 7(4, 3), code 9(4, 3), code 10(4, 3), code 11(4, 3)

Uncombined memory, row 4 column 4, code 0(4, 4), code 2(4, 4), code 3(4, 4), code 4(4, 4), code 5(4, 4), code 6(4, 4), code 7(4, 4), code 8(4, 4), code 9(4, 4), code 10(4, 4), code 11(4, 4)

Uncombined memory, row 4 column 5, code 1(4, 5), code 2(4, 5), code 3(4, 5), code 5(4, 5), code 6(4, 5), code 7(4, 5), code 8(4, 5), code 10(4, 5), code 11(4, 5)

Uncombined memory, row 5 column 0, code 0(5, 0), code 1(5, 0), code 2(5, 0), code 3(5, 0), code 4(5, 0), code 5(5, 0), code 6(5, 0), code 7(5, 0), code 8(5, 0), code 9(5, 0), code 10(5, 0), code 11(5, 0)

Uncombined memory, row 5 column 1, code 1(5, 1), code 2(5, 1), code 3(5, 1), code 4(5, 1), code 5(5, 1), code 6(5, 1), code 7(5, 1), code 8(5, 1), code 9(5, 1), code 10(5, 1), code 11(5, 1)

Uncombined memory, row 5 column 2, code 1(5, 2), code 2(5, 2), code 3(5, 2), code 5(5, 2), code 6(5, 2), code 7(5, 2), code 8(5, 2), code 9(5, 2), code 10(5, 2), code 11(5, 2)

Uncombined memory, row 5 column 4, code 0(5, 4), code 1(5, 4), code 2(5, 4), code 3(5, 4), code 5(5, 4), code 6(5, 4), code 7(5, 4), code 9(5, 4), code 10(5, 4), code 11(5, 4)

Uncombined memory, row 5 column 6, code 1(5, 6), code 2(5, 6), code 3(5, 6), code 5(5, 6), code 6(5, 6), code 7(5, 6), code 8(5, 6), code 9(5, 6), code 11(5, 6)

Uncombined memory, row 5 column 8, code 0(5, 8), code 1(5, 8), code 2(5, 8), code 3(5, 8), code 4(5, 8), code 7(5, 8), code 8(5, 8), code 11(5, 8)

Merging memories, code 0(11, 8), code 1(2, 5), code 3(2, 5), code 4(11, 8), code 6(2, 5), code 7(2, 5), code 8(11, 8), code 10(2, 5), code 11(2, 5)

Merging memories, code 0(8, 3), code 1(1, 3), code 2(1, 3), code 3(1, 3), code 4(8, 3), code 5(1, 3), code 6(1, 3), code 7(1, 3), code 8(1, 3), code 9(1, 3), code 10(1, 3), code 11(1, 3)

Merge memory, code 0(4, 19), code 1(4, 19), code 2(4, 19), code 3(3, 19), code 4(4, 19), code 5(4, 19), code 6(4, 19), code 7(3, 19), code 8(4, 19), code 9(4, 19), code 10(4, 19)

Merging memories, code 0(10, 0), code 1(7, 2), code 2(4, 17), code 3(3, 17), code 4(10, 0), code 5(7, 2), code 6(3, 17), code 8(10, 0), code 9(7, 2), code 10(3, 17), code 11(3, 17)

Merging memories, code 0(9, 0), code 1(6, 1), code 3(0, 20), code 4(9, 0), code 5(6, 1), code 6(5, 7), code 7(0, 20), code 8(9, 0), code 9(6, 1), code 10(4, 11), code 11(0, 20)

Merge memory, code 0(6, 18), code 1(6, 18), code 2(2, 18), code 3(2, 18), code 4(6, 18), code 5(6, 18), code 6(2, 18), code 7(2, 18), code 8(6, 18), code 9(6, 18), code 10(2, 18), code 11(2, 18)

Merge memory, code 0(4, 20), code 1(4, 20), code 2(4, 20), code 3(1, 20), code 4(4, 20), code 5(4, 20), code 6(4, 20), code 7(1, 20), code 8(4, 20), code 9(4, 20), code 10(4, 20), code 11(1, 20)

Merge memory, code 0(7, 0), code 1(7, 0), code 2(0, 18), code 3(0, 18), code 4(7, 0), code 5(7, 0), code 6(0, 18), code 8(7, 0), code 9(7, 0), code 10(0, 18), code 11(0, 18)

Merge memory, code 0(11, 13), code 1(7, 13), code 3(3, 13), code 4(11, 13), code 6(3, 13), code 7(3, 13), code 8(11, 13), code 9(7, 13), code 10(3, 13), code 11(3, 13)

Merging memories, code 0(8, 0), code 1(7, 1), code 2(2, 16), code 3(2, 16), code 4(8, 0), code 5(7, 1), code 6(2, 16), code 7(2, 16), code 8(8, 0), code 9(7, 1), code 10(2, 16), code 11(2, 16)

Merging memories, code 0(11, 0), code 1(5, 3), code 2(5, 3), code 3(2, 19), code 4(11, 0), code 5(5, 3), code 6(5, 3), code 8(11, 0), code 9(5, 3), code 10(5, 3), code 11(2, 19)

Merge memory, code 0(6, 17), code 1(6, 17), code 3(2, 17), code 4(6, 17), code 5(6, 17), code 6(4, 16), code 7(2, 17), code 8(6, 17), code 9(6, 17), code 10(2, 17), code 11(2, 17)

Merging memories, code 0(4, 0), code 1(4, 0), code 2(4, 0), code 3(1, 19), code 4(4, 0), code 5(4, 0), code 6(4, 0), code 7(1, 19), code 8(4, 0), code 9(4, 0), code 10(4, 0), code 11(1, 19)

Merge memory, code 0(8, 16), code 1(0, 16), code 2(5, 16), code 3(0, 16), code 4(8, 16), code 5(0, 16), code 6(0, 16), code 7(0, 16), code 8(8, 16), code 9(0, 16), code 10(5, 16), code 11(0, 16)

Merge memory, code 0(5, 19), code 1(5, 19), code 2(5, 19), code 3(0, 19), code 4(5, 19), code 5(5, 19), code 6(5, 19), code 7(0, 19), code 8(5, 19), code 9(5, 19), code 10(5, 19), code 11(0, 19)

Merge memory, code 0(7, 17), code 1(7, 17), code 2(1, 17), code 3(1, 17), code 4(7, 17), code 5(7, 17), code 6(1, 17), code 7(1, 17), code 8(7, 17), code 9(7, 17), code 11(1, 17)

Merging memories, code 0(5, 12), code 1(6, 5), code 2(5, 12), code 3(2, 12), code 4(5, 12), code 5(5, 12), code 6(2, 12), code 7(2, 12), code 8(5, 12), code 9(2, 12), code 10(2, 12), code 11(2, 12)

Merge memory, code 0(9, 15), code 1(7, 15), code 3(2, 15), code 4(9, 15), code 5(7, 15), code 6(5, 15), code 7(2, 15), code 8(9, 15), code 9(7, 15), code 10(5, 15), code 11(2, 15)

Merge memory, code 0(11, 12), code 1(7, 6), code 2(4, 12), code 3(3, 1S), code 4(11, 12), code 5(7, 6), code 6(4, 12), code 7(3, 18), code 8(11, 12), code 9(4, 12), code 10(4, 12), code 11(3, 18)

Merge memory, code 0(8, 15), code 1(4, 15), code 2(3, 15), code 3(3, 15), code 4(8, 15), code 6(3, 15), code 7(3, 15), code 8(8, 15), code 9(6, 9), code 10(4, 15), code 11(3, 15)

Merging memories, code 0(9, 2), code 1(6, 12), code 4(9, 1), code 5(6, 12), code 6(5, 13), code 7(1, 12), code 8(10, 2), code 9(6, 12), code 10(1, 12), code 11(1, 12)

Merge memory, code 0(6, 0), code 1(6, 0), code 2(0, 17), code 3(0, 17), code 4(6, 0), code 5(6, 0), code 6(5, 17), code 7(0, 17), code 8(6, 0), code 9(6, 0), code 10(5, 17)

Merge memory, code 0(8, 4), code 1(3, 12), code 2(3, 12), code 3(3, 12), code 4(8, 4), code 5(3, 12), code 7(3, 12), code 8(8, 4), code 9(7, 14)

Merge memory, code 0(9, 4), code 1(1, 15), code 2(1, 15), code 3(1, 15), code 4(9, 4), code 5(1, 15), code 6(1, 15), code 7(1, 19), code 8(9, 4), code 9(1, 15), code 11(1, 15)

Merging memories, code 0(0, 12), code 1(0, 12), code 2(5, 10), code 3(0, 12), code 4(0, 12), code 6(0, 12), code 7(0, 12), code 8(0, 12), code 9(5, 10), code 10(5, 10), code 11(0, 12)

Merge memory, code 0(10, 4), code 2(0, 15), code 3(0, 15), code 4(10, 4), code 5(0, 15), code 7(0, 15), code 8(10, 4), code 9(0, 15), code 10(0, 15)

Merge memory, code 0(5, 18), code 1(5, 18), code 2(5, 18), code 3(1, 18), code 4(5, 18), code 5(5, 18), code 6(5, 18), code 7(1, 18), code 8(5, 18), code 9(5, 18), code 10(5, 18)

Merging memories, code 0(10, 13), code 1(6, 7), code 2(1, 13), code 3(1, 13), code 4(10, 13), code 5(1, 13), code 6(1, 13), code 7(1, 13), code 8(10, 13), code 9(6, 7), code 11(1, 13)

Merge memory, code 0(7, 16), code 1(7, 16), code 3(1, 16), code 4(7, 16), code 5(7, 16), code 8(7, 16), code 9(7, 16), code 10(1, 16)

Merge memory, code 0(11, 4), code 1(2, 13), code 2(2, 13), code 3(2, 13), code 4(11, 4), code 5(2, 13), code 7(2, 13), code 8(11, 4), code 9(2, 13)

Merge memory, code 0(9, 8), code 1(3, 16), code 2(3, 16), code 3(3, 16), code 4(10, 5), code 5(3, 16), code 7(3, 16), code 8(9, 8), code 9(3, 16), code 11(3, 16)

Merging memories, code 0(10, 1), code 1(4, 13), code 3(3, 7), code 4(10, 1), code 5(4, 13), code 6(3, 7), code 7(3, 7), code 8(8, 1), code 9(4, 13), code 10(4, 13), code 11(3, 7)

Merge memory, code 0(10, 14), code 1(6, 14), code 3(2, 14), code 4(10, 1), code 5(6, 14), code 6(2, 14), code 7(2, 14), code 8(10, 14), code 9(2, 14), code 11(2, 14)

Merge memory, code 0(11, 11), code 1(4, 7), code 2(4, 7), code 3(3, 11), code 4(3, 11), code 5(4, 7), code 6(3, 11), code 7(3, 11), code 8(3, 11), code 9(3, 11), code 11(3, 11)

Merge memory, code 0(9, 14), code 2(4, 14), code 3(1, 14), code 4(9, 14), code 5(4, 14), code 6(4, 14), code 7(1, 14), code 8(9, 14), code 10(1, 14)

Merge memory, code 0(2, 11), code 1(2, 11), code 2(2, 11), code 3(2, 11), code 4(9, 11), code 5(2, 11), code 7(2, 11), code 8(6, 11)

Merge memory, code 0(11, 5), code 1(0, 14), code 2(5, 14), code 3(0, 14), code 4(9, 6), code 5(5, 14), code 6(0, 14), code 7(0, 14), code 8(9, 5), code 9(5, 14), code 10(0, 14), code 11(0, 14)

Merge memory, code 0(7, 11), code 1(7, 11), code 2(0, 13), code 3(0, 13), code 4(11, 6), code 5(7, 11), code 7(0, 13), code 8(11, 6), code 9(7, 11), code 10(0, 13), code 11(0, 13)

Merge memory, code 0(6, 4), code 1(3, 14), code 2(3, 14), code 3(3, 14), code 4(6, 4), code 5(6, 4), code 7(3, 14), code 8(6, 4), code 10(3, 14), code 11(3, 14)

Merging memories, code 0(10, 6), code 1(5, 11), code 2(3, 10), code 3(3, 10), code 4(11, 7), code 5(7, 3), code 6(5, 11), code 7(3, 10), code 8(7, 3), code 9(7, 3), code 10(5, 11), code 11(3, 10)

Merge memory, code 0(7, 10), code 1(6, 10), code 3(0, 10), code 4(6, 10), code 6(0, 10), code 7(0, 10), code 8(11, 10), code 9(6, 10)

Merging memories, code 0(10, 7), code 2(1, 11), code 3(1, 11), code 4(7, 5), code 5(7, 5), code 6(1, 11), code 7(1, 11), code 8(7, 7), code 9(1, 11), code 11(1, 11)

Merging memories, code 0(2, 10), code 2(2, 10), code 3(2, 10), code 4(2, 10), code 5(2, 10), code 6(2, 10), code 7(2, 10), code 8(10, 9), code 11(2, 10)

Merging memories, code 0(8, 9), code 2(0, 11), code 3(0, 11), code 4(0, 11), code 5(0, 11), code 7(0, 11), code 8(0, 11), code 10(0, 11), code 11(0, 11)

Merge memory, code 0(9, 10), code 1(4, 10), code 2(4, 10), code 4(10, 10), code 5(4, 10), code 6(4, 10), code 8(4, 10), code 9(4, 10), code 10(4, 10)

Merge memory, code 0(5, 9), code 1(5, 9), code 2(5, 9), code 4(7, 9), code 5(5, 9), code 6(5, 9), code 8(9, 9), code 10(5, 9)

Merging memories, code 0(4, 6), code 1(1, 10), code 2(4, 6), code 3(1, 10), code 4(4, 6), code 5(1, 10), code 6(4, 6), code 7(1, 10), code 8(1, 10), code 10(1, 10), code 11(1, 10)

Merging memories, code 0(0, 9), code 1(0, 9), code 2(0, 9), code 3(0, 9), code 4(8, 7), code 5(0, 9), code 7(0, 9), code 8(8, 7), code 9(0, 9), code 11(0, 9)

Merging memories, code 0(6, 6), code 1(1, 6), code 2(4, 9), code 3(1, 6), code 4(4, 9), code 5(6, 6), code 6(1, 6), code 7(1, 6), code 8(6, 6), code 9(4, 9), code 10(4, 9), code 11(1, 6)

Merging memories, code 0(6, 2), code 1(6, 2), code 2(1, 9), code 3(1, 9), code 4(1, 9), code 5(6, 2), code 6(1, 9), code 7(1, 9), code 9(6, 2), code 11(1, 9)

Merging memories, code 0(8, 8), code 1(3, 6), code 2(3, 6), code 3(3, 6), code 4(8, 8), code 6(3, 6), code 7(3, 6), code 8(8, 8), code 9(3, 6), code 10(3, 6), code 11(3, 6)

Merging memories, code 1(2, 9), code 2(5, 5), code 3(2, 9), code 4(5, 5), code 6(5, 5), code 7(2, 9), code 8(2, 9), code 9(5, 5), code 10(5, 5), code 11(2, 9)

Merging memories, code 0(6, 3), code 1(6, 3), code 2(0, 6), code 3(0, 6), code 4(6, 3), code 5(6, 3), code 6(0, 6), code 7(0, 6), code 9(6, 3), code 10(0, 6), code 11(0, 6)

Merging memories, code 0(4, 8), code 1(2, 7), code 2(2, 7), code 3(2, 7), code 4(4, 8), code 5(2, 7), code 6(4, 8), code 7(2, 7), code 8(4, 8), code 10(2, 7), code 11(2, 7)

Merging memories, code 0(7, 8), code 1(7, 8), code 3(2, 6), code 4(7, 8), code 5(7, 8), code 6(2, 6), code 7(2, 6), code 8(7, 8), code 9(2, 6), code 10(2, 6), code 11(2, 6)

Merge memory, code 0(7, 4), code 1(7, 4), code 3(3, 9), code 4(7, 4), code 5(3, 9), code 6(3, 9), code 7(3, 9), code 8(7, 4), code 9(7, 4), code 10(3, 9), code 11(3, 9)

Merging memories, code 0(6, 8), code 1(0, 5), code 2(0, 5), code 3(0, 5), code 4(6, 8), code 5(6, 8), code 6(0, 5), code 7(0, 5), code 8(6, 8), code 9(6, 8), code 10(0, 5), code 11(0, 5)

Merging memories, code 0(10, 8), code 1(0, 1), code 2(0, 1), code 3(0, 1), code 4(10, 8), code 5(0, 1), code 6(0, 1), code 7(0, 1), code 8(10, 8), code 9(0, 1), code 10(0, 1), code 11(0, 1)

Claims

1. A decoder for decoding a low density parity check encoded signal, the decoder comprising:

a plurality of memories;

a plurality of multiplexers to:

selectively connecting the plurality of bit engines and the plurality of check engines to a first selected memory of the plurality of memories during a decoding process of a first low density parity check encoded signal;

and

selectively connecting the plurality of bit engines and the plurality of check engines to a second selected one of the plurality of memories during a decoding process of a second low density parity check encoded signal; and wherein:

the plurality of memories comprises a predetermined number of memories for representing a plurality of non-zero sub-matrices of a plurality of low density parity check matrices corresponding to a plurality of low density parity check codes;

the decoder is configured to decode the first low density parity check encoded signal corresponding to a first low density parity check matrix of the plurality of low density parity check matrices, wherein the bit engine and the check engine perform an iterative decoding process until a stopping criterion is met, after which the bit engine generates soft information to generate a best estimate of bits encoded within the first low density parity check encoded signal; and

the decoder is configured to decode the second low density parity check encoded signal corresponding to a second low density parity check matrix of the plurality of low density parity check matrices, wherein the bit engine and the check engine perform an iterative decoding process until a stopping criterion is met, after which the bit engine generates soft information to generate a best estimate of bits encoded within the second low density parity check encoded signal.

2. The decoder of claim 1, wherein a portion of the plurality of memories is determined by superimposing a plurality of non-zero submatrices of a plurality of low density parity check matrices corresponding to a plurality of low density parity check codes on each other.

3. The decoder of claim 1, wherein a portion of the plurality of memories is determined by performing a greedy, deep search of a superposition of non-zero submatrices of a plurality of low density parity check matrices corresponding to a plurality of low density parity check codes.

4. The decoder of claim 1, wherein a portion of the plurality of memories is determined by performing a greedy, deep search of a superposition of non-zero submatrices of a plurality of low density parity check matrices corresponding to a plurality of low density parity check codes; and is

The first greedy, deep search considers, at least in part, column affine metrics representing connectivity of a column in the first low density parity check matrix with at least another column in the first low density parity check matrix and a column in the second low density parity check matrix.

5. The decoder of claim 1, wherein a layout of the plurality of memories within the communication device is based on a merge pattern, the merge pattern being generated by considering, at least in part, a column affine metric representing connectivity of a column in the first low density parity check matrix with at least another column in the first low density parity check matrix and a column in the second low density parity check matrix.

6. The decoder of claim 1, wherein the plurality of memories comprises a plurality of merge memories, and wherein a merge memory of the plurality of merge memories corresponds to a first non-zero submatrix of the first low density parity check matrix and also corresponds to a second non-zero submatrix of the second low density parity check matrix.

7. A decoder for decoding a low density parity check encoded signal, the decoder comprising:

a plurality of memories;

a plurality of multiplexers to:

connecting a first selected bit engine of the plurality of bit engines to a first selected memory of the plurality of memories during bit node processing when decoding a first low density parity check encoded signal;

connecting a first selected one of the plurality of check engines to the first selected one of the plurality of memories during check node processing while decoding the first low density parity check encoded signal;

connecting a second selected bit engine of the plurality of bit engines to a second selected memory of the plurality of memories during bit node processing when decoding a second low density parity check encoded signal; and

connecting a second selected one of the plurality of check engines to the second selected one of the plurality of memories during check node processing while decoding the second low density parity check encoded signal; wherein:

the plurality of memories comprises a predetermined number of memories for representing a plurality of non-zero sub-matrices of a plurality of low density parity check matrices corresponding to a plurality of low density parity check codes; ,

the decoder is for decoding a first low density parity check encoded signal corresponding to a first low density parity check matrix of the plurality of low density parity check matrices, wherein the bit engine and the check engine perform an iterative decoding process until a stopping criterion is met, after which the bit engine generates soft information to generate a best estimate of bits encoded within the first low density parity check encoded signal; and

the decoder is for decoding a second low density parity check encoded signal corresponding to a second low density parity check matrix of the plurality of low density parity check matrices, wherein the bit engine and the check engine perform an iterative decoding process until a stopping criterion is met, after which the bit engine generates soft information to generate a best estimate of bits encoded within the second low density parity check encoded signal.

8. The decoder of claim 7, wherein the first selected bit engine of the plurality of bit engines is the second selected bit engine of the plurality of bit engines; and

9. The decoder of claim 7, wherein the first selected bit engine of the plurality of bit engines is all bit engines of the plurality of bit engines; and

10. A decoder for decoding a low density parity check encoded signal, the decoder comprising:

a plurality of memories;

a plurality of multiplexers to:

connecting the plurality of bit engines to a first selected memory of the plurality of memories during bit node processing when decoding a first low density parity check encoded signal;

connecting the plurality of check engines to the first selected one of the plurality of memories during check node processing while decoding the first low density parity check encoded signal;

connecting the plurality of bit engines to a second selected one of the plurality of memories during bit node processing when decoding a second low density parity check encoded signal;

connecting the plurality of check engines to the second selected one of the plurality of memories during check node processing while decoding the second low density parity check encoded signal;

connecting the plurality of bit engines to a third selected one of the plurality of memories during bit node processing when decoding a third low density parity check encoded signal; and

connecting the plurality of check engines to the third selected one of the plurality of memories during check node processing while decoding the third low density parity check encoded signal; wherein:

the decoder is configured to decode the first low density parity check encoded signal corresponding to a first low density parity check matrix of the plurality of low density parity check matrices, wherein the bit engine and the check engine perform an iterative decoding process until a stopping criterion is met, after which the bit engine generates soft information to generate a best estimate of bits encoded within the first low density parity check encoded signal;

the decoder is configured to decode the second low density parity check encoded signal corresponding to a second low density parity check matrix of the plurality of low density parity check matrices, wherein the bit engine and the check engine perform an iterative decoding process until a stopping criterion is met, after which the bit engine generates soft information to generate a best estimate of bits encoded within the second low density parity check encoded signal; and

the decoder is configured to decode the third low density parity check encoded signal corresponding to a third low density parity check matrix of the plurality of low density parity check matrices, wherein the bit engine and the check engine perform an iterative decoding process until a stopping criterion is met, after which the bit engine generates soft information to generate a best estimate of bits encoded within the third low density parity check encoded signal.