Embodiments of the invention generally pertain to apparatus and methods for processing streams of user data for applications including data recording and data communication. In particular, embodiments of the invention pertain to apparatus and methods for encoding and decoding streams of data.
Linear block codes, such as Single Parity Check (SPC) codes, have found wide-spread application in areas such as magnetic recording and data communications in recent years. Such codes are often used with a Viterbi detector, which provides a coding gain by using a constraint associated with the code to remove certain data sequences from being considered as possible decodings of a received data stream. As used herein, the term “coding gain” refers to the ability of a code to lessen the occurrences of errors associated with communication and/or storage of information. The performance of such a detector generally improves when linear block codes with shorter input block lengths are used. However, codes with shorter input block lengths tend to require higher overhead, thus reducing the code rate and resulting in a performance tradeoff of coding gain versus code rate penalty. As used herein, “code rate penalty” refers to a measure (e.g., a ratio) of an amount of user data relative to an amount of extra coding information that is associated with the user data. Extra coding information may be used to detect and/or correct errors that may occur in user data. This extra coding information is commonly referred to as “redundant information/data” or “parity information/data.”
Tensor-Product Codes (TPC) allow the use of shorter input block lengths without the full code rate penalty typically associated with such block lengths. Accordingly, there is a continued interest in improving the performance of TPC-based encoding and decoding systems.
An embodiment of an encoder apparatus includes a receive module that receives a data stream, a parity generation module that generates a plurality of parity bits based on the data stream and a word of a tensor-product code, and a parity insertion module that combines the plurality of parity bits and the data stream to generate encoded bits.
An embodiment of an encoding method includes receiving a data stream, generating a plurality of parity bits based on the data stream and a word of a tensor-product code, and combining the plurality of parity bits and the data stream to generate encoded bits.
An embodiment of a decoder apparatus includes a detector receiving and outputting encoded data, a first decoder generating first log-likelihood ratios from the encoded data, an error recovery module generating second log-likelihood ratios from the encoded data, a second decoder that derives syndrome data from the first and second log-likelihood ratios, a post-processor that combines data from the first decoder with error events from the error recovery module to generate corrected data, the post-processor further identifying a plurality of parity bits in the corrected data and replacing each of those parity bits with zero.
An embodiment of a decoding method includes detecting and outputting encoded data, generating first log-likelihood ratios from the encoded data generating second log-likelihood ratios based on error events in the encoded data, deriving syndrome data from the first and second log-likelihood ratios, combining data with error events to generate corrected data, and identifying a plurality of parity bits in the corrected data and replacing each of the parity bits with zero.
Further features of the invention, its nature and various advantages, will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:
A tensor-product code (TPC) includes an inner code and outer code. One property of a TPC codeword is that the syndromes of multiple codewords of the inner code form a codeword of the outer code. For example, as shown in
In this example, the length of each codeword 110 in inner code 11 is five. A single syndrome bit 120 is derived from each codeword 110 and the syndrome bits 120 of six inner codewords 110 are used as the user bits of a single outer codeword 121 of user-length six. It will be recognized that other lengths may be used for both the inner and outer codewords.
This single-bit TPC example may be considered to be a special case of a more generic multi-parity TPC, and both single- and multi-parity codes can be used within a single channel. In a multi-parity TPC, two or more syndrome bits are derived from each codeword of the inner code.
Characteristics of the inner code may be described by a parity-check matrix. An example of parity-check matrix of a two-bit (“dibit”) inner code is the following:
This assumes that the block length is 12, but it is straightforward to generalize to other block lengths.
The two syndrome bits, s0 and s1, are obtained by multiplying this 2×12 matrix with a 12×1 block vector a11 . . . a0:
s0=a11+a9+a7+a5+a3+a1
s1=a10+a8+a6+a4+a2+a0
where, for two binary digits x, y, x+y represents an exclusive-OR of x and y.
An example of parity-check matrix of a three-bit (“tribit”) inner code is the following:
If this 3×12 matrix is multiplied by a 12×1 block vector a11 . . . a0 representing an inner code codeword, the result would be three syndrome bits s0, s1 and s2:
s0=a11+a7+a3
s1=a10+a8+a6+a4+a2+a0
s2=a9+a5+a1
The parity-check matrices H2 and H3 can be designed for flexibility in the length of the inner codeword. For example, the same matrix can be adapted for a 10-bit codeword by deleting the last two columns.
The matrices shown above are only exemplary, and any full-rank matrix can be chosen as a parity-check matrix of an inner code. Moreover, number of syndrome bits is not limited to 1, 2, or 3, but can be any number.
A data channel 30 in which the present invention can be implemented is shown in
Channel 30 includes an encoder write/transmit path 32, a channel medium 34 and a decoder read/receive path 36, which may be referred to as tensor-product encoder and decoder paths. Data is encoded via the encoder path 32, stored on or transmitted through the channel medium 34, and read or received and decoded via the decoder path 36.
The encoder path 32 may include encoder stage 320, zero pre-insertion stage 321, error-correcting code (ECC) encoder 322, an ECC parity interleaver 323 and a TPC encoder 324. Encoder stage 320 may be a run-length-limited encoder, which prevents long runs without transitions, and can enforce some other constraints, such as direct current (DC) limited constraints. Parity pre-insertion or zero pre-insertion stage 321 divides the data stream into concatenated segments, such as data1 and data2, respectively, by inserting dummy zeroes between them. The zeroes may be inserted into locations reserved for TPC redundancy bits, as discussed below. The stages through the ECC parity interleaver 323 may be located in the drive controller 301, while TPC encoder 324 may be located in the physical channel interface 302 itself.
The ECC encoder 322 may be an encoder operating under any suitable error correction encoding scheme, such as, e.g., systematic Reed-Solomon (RS) Code encoding. ECC encoder 322 may be followed by the ECC parity interleaver 323, which operates to interleave parity bits within the ECC-encoded data, as described in more detail below.
TPC encoder 324 may operate like that described in above-incorporated application Ser. No. 11/809,670, and is described in more detail below.
The decoder path 36 includes a read channel analog front end 360, a TPC decoder 361, an ECC parity deinterleaver 362, an ECC decoder 363, a zero-removal stage 364 and a decoder stage 365 which may be a run-length-limited decoder. Analog front end 360 and TPC decoder 361 may be located in the physical channel interface 302 itself with the remaining decoder stages being in the drive controller 301.
Read channel analog front end 360 may include an analog-to-digital converter, and a digital filter, such as a finite impulse response (FIR) filter. TPC decoder 361 may be that described in above-incorporated application Ser. No. 11/809,670, and described in more detail below.
Zero pre-insertion stage 321 inserts dummy bits into the RLL-coded data, to reserve locations for TPC parity bits to be inserted later. Although zero pre-insertion may not be necessary (with the TPC parity bits being inserted later), it may be advantageous to perform zero pre-insertion. Without zero pre-insertion, the block length of the TPC inner code may not be uniform, resulting in a decoder with higher complexity to compensate. And even with the more complex decoder, the block boundaries will not necessarily correspond to ECC symbol boundaries, thus affecting performance.
As stated above, the size of each RLL-encoded block 402 may not be same, so p may differ for different blocks. Moreover, the location of the inserted zeroes 403 may not be the same for every block. In the example shown, the location of inserted zeroes 403 alternate between the beginning and the end of successive blocks, but that is not necessary. However, the number and locations of inserted zeroes 403 are monitored if those numbers and positions are not always the same.
ECC parity interleaver 323, also described in above-incorporated application Ser. No. 11/809,670, spreads ECC parity throughout entire sector. As diagrammed in
The exclusive-OR operation just described works when a portion of the parity-check matrix is the identity matrix. That is true of both the first two columns and the last two columns of the dibit parity-check matrix given above. However, in a tribit case, this will be true in the case of an odd block length, but for an even block length it is not possible to have a full-rank parity-check matrix that has an identity matrix as a submatrix in the last three columns. Therefore, instead of a simple XOR, the tribit encoder may operate as follows.
For those symbols where the pre-inserted zeroes are at the beginning of the block, corresponding to a 3-by-3 identity submatrix in the first three columns of the parity matrix, the XOR operation as in
w=a7+s2=a3+p2
x=a5+a4+a3
y=a9+a5+s0=p0
z=a8+a6+s5+a3+s1=x+p1
In a case where the block length is 0 mod 4, and the ECC-encoded symbol, with three pre-inserted zeroes, is a11a10a9a8a7a6a5a4a3000, one can define the desired output as a11a10a9a8a7a6a5a4wxyz, where:
w=a11+a7+s0=a3+P0
x=a5+a4+a3
y=a9+a5+s2=p2
z=a10+a8+a6+a5+a3+s1=x+p1
For those blocks 813 where the pre-inserted zeroes are at the ends of the blocks, the calculations above for w, x, y and z provide four parity bits 805 to be substituted for four pre-inserted zeroes. User blocks 821 are unchanged by this process.
The TPC encoding process should insert parity bits only in blocks that have had zeroes pre-inserted because, as described above, it is desirable to maintain uniform block length. Where ECC interleaving has occurred after zero pre-insertion, ECC parity blocks 900 may be interleaved among both parity blocks 901 and user blocks 902 as shown in
As mentioned before, a typical choice for the TPC outer code is an LDPC code. For reduced complexity, a practical LDPC code may be a “structured” code, such as a quasi-cyclic code. For such a code, with multibit parity TPC, interleaving/deinterleaving the LDPC code may improve decoder performance. Because neighboring bits are processed similarly, any degradation of one parity bit might similarly affect the other parity bits, but if the parity bits are distributed by interleaving, it is less likely that they would all be affected.
As seen in
This interleaving/deinterleaving operation was described generally in copending, commonly-assigned U.S. patent application Ser. No. 11/933,831, filed Nov. 1, 2007, which is hereby incorporated by reference herein in its entirety. A particular interleaving/deinterleaving operation may be described with reference to
Although any interleaver (and corresponding deinterleaver) may be used, interleaver 1200 has low complexity and provides good performance. For simplicity, every eight bits are interleaved. There are 8! choices of interleaver functions having eight inputs and eight outputs, but, again for simplicity, four such functions n0 (1201), n1 (1202), n2 (1203), n3 (1204), may be used, and repeated as necessary. The number of interleaver function blocks may be equal to the number of LDPC computation units (e.g., 12) to simplify the decoding process.
Examples of the four interleaving functions are:
As described above and shown in
SOVA decoder 1315 may be that described in copending, commonly-assigned U.S. patent application Ser. No. 12/572,329, filed Oct. 2, 2009, which is hereby incorporated by reference herein in its entirety. Briefly, SOVA 1315, as described in
EEP 1402 may store the best n events, out of the eight events that it keeps, to post processor (correction block) memory 1403. n=4 may be selected, but a larger n, which provides better performance at a cost of greater complexity, also may be selected.
The trace-back unit initially provides a p-bit mask 1701: a12a11 . . . a0, but only q bits are sent to EEP 1402. p and q may be 13 and 9, 12 and 8, or any other combination that differs by 4 because the number of states of Viterbi detector 1304 is 24=16. A longer maximum error event provides better performance, but increases the complexity of the circuit. Most of the time, an error event is short and so in the 13-bit example, a12a11a10a9=0000. In this case, the 9-bit mask 1702 sent to EEP 1402 is correct and no adjustment of metric 1703 is needed. However, when an error event is longer than nine bits, the presence of a “1” in any one or more of a12 . . . a9, causes OR-gate 1704 to select, instead of the true value of metric 1703, a maximum metric value 1706 (63 in the case of a 6-bit number) at multiplexer 1705, to indicate that the 9-bit mask 1702 is not a true representation of the error event. If desired, performance can be improved by scaling the (6-bit) metric at 1707 and saturating the metric to five bits at 1708 before sending the metric to EEP 1402, to prevent all the values from being maxima or minima, or the scaling and saturation may be performed in EEP 1402 instead of trace-back unit 1401.
Details of an embodiment of EEP 1402 are shown in
LLRs are computed at block 1808 for LDPC decoder 1335 from NRZ syndromes 1809 and error event metrics 1802 as selected by blocks L1-L7 (in the tribit case). IF snrz denotes an NRZ syndrome 1809, and M(1), . . . , M(7) denotes the metrics of most likely events with syndromes 1, . . . , 7, respectively (for convenience, one can define M(0)=0), then the LLR is computed by:
L(x)=M(snrz+x)−M(snrz)
where x ranges from 1 to 7 and snrz+x denotes the XOR of 3-bit numbers snrz and x. In the case of a 5-bit error event metric, M ranges from 0 to 31. Therefore, L can range from −31 to +31.
ERC module 1325 may be explained in connection with
The role of ERC module 1325 is to recover data11932 in cases where syncmark11921 is missed, and also to generate part of the LLR that corresponds to data11932, for use by LDPC decoder 1335. To recover data11932, ERC module 1325 buffers Viterbi output to memory. Once syncmark2 is found, ERC module 1325 knows the start location of data11932 because the length of data11932 is fixed, and starts outputting data from that location. However, because data1 so recovered is not completely reliable, there is no point in making a precise LLR computation. Therefore, ERC module 1325 will not compute LLR as precisely as if syncmark1 had not been missed, thereby reducing complexity. ERC module 1325 also will not generate an error event for the data1 portion. This means that post-processor 1345 will not be able to correct any error in data1, again to reduce complexity.
The LLR may be computed as follows.
ERC module 1325 will only attempt to compute LLR that is consistent with NRZ data. To reduce complexity, the magnitude of LLR may be user-programmable. One can define:
s=the NRZ syndrome of the considered block
m=2n−1 where n is the number of syndrome bits.
LLR may be defined is a vector with a number of entries equal to the maximum possible value of m, which is 7 if the number of syndrome bits is 3 (tribit).
If s=0, then:
Li=x for i=0,1, . . . ,m−1
LDPC decoder 1335 and post-processor 1345 have to be able to receive data from both ERC module 1325 and SOVA decoder 1315 at the same time, because when syncmark1 is found, ERC module 1325 will output data and LLRs for data1, and SOVA decoder 1315 will output data, LLRs, and error events for data2.
The role of LDPC decoder 1335 is to receive LLRs from SOVA decoder 1315 and provide a hard decision to post-processor 1345. The hard decision will indicate the correct syndrome of the TPC inner code. Based on that hard decision, post-processor 1345 will select which error event to correct. In the example in
Post-processor 1345 also should zero out the TPC parity locations. If a tribit architecture is used with parity-check matrix H3 given above and the wxyz encoding scheme given above, then post-processor 1345 can zero out the TPC parity locations as follows:
For a symbol where the parity bits are at the beginning, the parity can simply be replaced with 0:
For a symbol where the parity bits are at the end
b9b8b7b6b5b4b3b2b1b0→b9b8b7b6b5b4x000
where x=b5+b4+b2.
The operation of a suitable LDPC decoder was explained in detail in above-incorporated application Ser. No. 11/933,831. A suitable LDPC decoder architecture (dibit-tribit decoder) was described in copending, commonly-assigned U.S. patent application Ser. No. 12/323,995, filed Nov. 26, 2008, which is hereby incorporated by reference herein in its entirety. A suitable method by which the post-processor could pick which error events to correct is explained in copending, commonly-assigned U.S. patent application Ser. No. 11/936,578, filed Nov. 7, 2007, which is hereby incorporated by reference herein in its entirety.
Thus it is seen that a data channel using a multi-parity TPC has been provided. It will be understood that the foregoing is only illustrative of the principles of the invention, and that the invention can be practiced by other than the described embodiments, which are presented for purposes of illustration and not of limitation, and the present invention is limited only by the claims which follow.
This is a continuation of copending, commonly-assigned U.S. patent application Ser. No. 12/604,558, filed Oct. 23, 2009, now U.S. Pat. No. 8,321,769, which claims the benefit of, and was copending with, commonly-assigned U.S. Provisional Patent Application No. 61/112,066, filed Nov. 6, 2008, each of which is hereby incorporated by reference herein in its respective entirety.
Number | Name | Date | Kind |
---|---|---|---|
4295218 | Tanner | Oct 1981 | A |
4601044 | Kromer, III et al. | Jul 1986 | A |
5537444 | Nill et al. | Jul 1996 | A |
5757821 | Jamal et al. | May 1998 | A |
5926232 | Mangold et al. | Jul 1999 | A |
5930272 | Thesling | Jul 1999 | A |
5933462 | Viterbi et al. | Aug 1999 | A |
5949831 | Coker et al. | Sep 1999 | A |
5974540 | Morikawa et al. | Oct 1999 | A |
5983385 | Khayrallah et al. | Nov 1999 | A |
6002716 | Meyer et al. | Dec 1999 | A |
6009549 | Bliss et al. | Dec 1999 | A |
6021518 | Pelz | Feb 2000 | A |
6023783 | Divsalar et al. | Feb 2000 | A |
6028728 | Reed | Feb 2000 | A |
6081918 | Spielman | Jun 2000 | A |
6145114 | Crozier et al. | Nov 2000 | A |
6145144 | Poehlmann et al. | Nov 2000 | A |
6161209 | Moher | Dec 2000 | A |
6182261 | Haller et al. | Jan 2001 | B1 |
6219817 | Holman | Apr 2001 | B1 |
6427220 | Vityaev | Jul 2002 | B1 |
6438180 | Kavcic et al. | Aug 2002 | B1 |
6539367 | Blanksby et al. | Mar 2003 | B1 |
6581181 | Sonu | Jun 2003 | B1 |
6634007 | Koetter et al. | Oct 2003 | B1 |
6691263 | Vasic et al. | Feb 2004 | B2 |
6708308 | De Souza et al. | Mar 2004 | B2 |
6715121 | Laurent | Mar 2004 | B1 |
6888897 | Nazari et al. | May 2005 | B1 |
6965652 | Burd et al. | Nov 2005 | B1 |
7000177 | Wu et al. | Feb 2006 | B1 |
7072417 | Burd et al. | Jul 2006 | B1 |
7099411 | Wu et al. | Aug 2006 | B1 |
7184486 | Wu et al. | Feb 2007 | B1 |
7765458 | Yang et al. | Jul 2010 | B1 |
7861131 | Xu et al. | Dec 2010 | B1 |
8019020 | Chaichanavong et al. | Sep 2011 | B1 |
8028216 | Yeo et al. | Sep 2011 | B1 |
8145983 | Chaichanavong et al. | Mar 2012 | B1 |
8181081 | Yeo et al. | May 2012 | B1 |
20070043997 | Yang et al. | Feb 2007 | A1 |
Number | Date | Country |
---|---|---|
2004-164767 | Jun 2004 | JP |
WO 9637050 | Nov 1996 | WO |
WO 0019616 | Apr 2000 | WO |
Entry |
---|
Shoemake, M.B., et al., “Computationally Efficient Turbo Decoding with the Bi-directional Viterbi Algorithm (BIVA),” Proceedings of the IEEE International Symposium on Information Theory, 1997, p. 228. |
Viterbi, A., “An Intuitive Justification and a Simplified Implementation of the MAP Decoder for Convolutional Codes,” IEEE Journal on Selected Areas in Communications, vol. 16, No. 2, Feb. 1998, pp. 261-264. |
Wolf, J., “On Codes Derivable from the Tensor Product of Check Matrices,” IEEE Transactions on Information Theory, Apr. 1965, pp. 281-284. |
Wolf et al., An Introduction to Tensor Product Codes and Applications to Digital Storage Systems, 2006 IEEE Information Theory Workshop, pp. 6-10. |
Wu, Z., “Coding and Iterative Detection for Magnetic Recording Channels,” The Kluwer International Series in Engineering and Computer Science, 1999, pp. 1-152. |
Wu, Z., “Coding, Iterative Detection and Timing Recovery for Magnetic Recording Channels,” A Dissertation submitted to the Department of Electrical Engineering and the Committee on Graduate Studies of Stanford University, Aug. 1999, pp. 1-143. |
Wymeersch, H., “Log-domain decoding of LDPC codes over GF (q),” IEEE Communications Society, 2004, pp. 1-5. |
Chaichanavong, P., et al., “A Tensor-Product Parity Code for Magnetic Recording,” pp. 1-3 Feb. 2006. |
Forney, G. David, “Codes on Graphs: Normal Realizations ” IEEE Transactions on Information Theory, vol. 47, No. 2, Feb. 2001, pp. 520-548. |
Gallager, R., “Low-Density Parity-Check Codes,” 1963, pp. 1-90. |
Hagenauer, J., et al., “A Viterbi Algorithm with Soft-Decision Outputs and its Applications,” IEEE, 1989, pp. 1680-1686. |
Kschischang, F., et al., “Factor Graphs and the Sum-Product Algorithm,” IEEE Transactions on Information Theory, vol. 47, No. 2, Feb. 2001, pp. 498-519. |
Lee, L.H.C., “Computation of the Right-Inverse of G(D) and the Left-Inverse of H'(D),” Electronics Letters, vol. 26, No. 13, Jun. 21, 1990, pp. 904-906. |
Li, Z., “Efficient Encoding of Quasi-Cyclic Low-Density Parity-Check Codes,” IEEE Transactions on Communications, vol. 54, No. 1, Jan. 2006, pp. 71-81. |
MacKay, D., “Good Error-Correcting Codes Based on Very Sparse Matrices,” IEEE Transactions on Information Theory, vol. 45, No. 2, Mar. 1999, pp. 399-431. |
Öberg, M., et al., “Parity Check Codes for Partial Response Channels,” Global Telecommunications Conference—Globecom '99, 1999, pp. 717-22. |
Richardson, T., et al, “The Renaissance of Gallager's Low-Density Parity-Check Codes,” IEEE Communications Magazine, Aug. 2003, pp. 126-131. |
Number | Date | Country | |
---|---|---|---|
61112066 | Nov 2008 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 12604558 | Oct 2009 | US |
Child | 13674512 | US |