A synthesizable IP Core for DVB-S2 LDPC Code Decoding
`
`Frank Kienle, Torben Brack, Norbert Wehn
`Microelectronic System Design Research Group
`University of Kaiserslautern
`Erwin-Schr¨odinger-Straße
`67663 Kaiserslautern, Germany
`fkienle, brack, wehng@eit.uni-kl.de
`
`Abstract
`
`The new standard for digital video broadcast DVB-S2
`features Low-Density Parity-Check (LDPC) codes as their
`channel coding scheme. The codes are defined for various
`code rates with a block size of 64800 which allows a trans-
`mission close to the theoretical limits.
`The decoding of LDPC is an iterative process. For DVB-
`S2 about 300000 messages are processed and reordered
`in each of the 30 iterations. These huge data processing
`and storage requirements are a real challenge for the de-
`coder hardware realization, which has to fulfill the specified
`throughput of 255MBit=s for base station applications.
`In this paper we will show, to the best of our knowledge,
`the first published IP LDPC decoder core for the DVB-S2
`standard. We present a synthesizable IP block based on ST
`Microelectronics 0:13µm CMOS technology.
`
`1 Introduction
`
`The new DVB-S2 standard [2] features a powerful for-
`ward error correction (FEC) system which enables trans-
`mission close to the theoretical limit (Shannon limit). This
`is enabled by using Low-Density Parity-Check (LDPC)
`codes [3] one of the most powerful codes known today
`which can even outperform Turbo-Codes [4]. To provide
`flexibility 11 different code rates ranging from (R = 1=4 up
`to 9=10) are specified with a codeword length up to 64800
`bits. This huge maximum codeword length is the reason
`for the outstanding communications performance ((cid:24)0.7dB
`to Shannon) of this DVB-S2 LDPC code proposal, so in
`this paper we only focus on the codeword length of 64800
`bits. To yield this performance, the decoder has to iterate 30
`times. At each iteration up to 300 000 data are scrambled
`and calculated. This huge data processing, storage and net-
`work/interconnect requirements is a real challenge for the
`decoder realization.
`
`A LDPC code can be represented by a bipartite graph.
`For the DVB-S2 code 64800 so called variable nodes (VN)
`and 64800 (cid:3) (1 (cid:0) R) check nodes (CN) exist. The connec-
`tivity of these two type of nodes is specified in the standard
`[2]. For decoding the LDPC code messages are exchanged
`iteratively between this two type of nodes, while the node
`processing is of low complexity. Within one iteration first
`the variable nodes are procesed, then the check nodes.
`For a fully parallel hardware realization each node is
`instantiated and the connections between them are hard-
`wired. This was shown in [5] for a 1024 bit LDPC code.
`But even for this relatively short block length severe rout-
`ing congestion problems exist. Therefore a partly paral-
`lel architecture becomes mandatory for larger block length,
`where only a subset of nodes are instantiated. A network
`has to provide the required connectivity between VN and
`CN nodes. But realizing any permutation pattern is very
`costly in terms of area, delay and power.
`To avoid this problem a decoder first design approach
`was presented in [6]. First an architecture is specified and
`afterwards a code is designed which fits this architecture.
`This approach is only suitable for regular LDPC code where
`each VN has the same number of incident edges, the CN
`respectively. But for an improved communications perfor-
`mance so called irregular LDPC codes are mandatory [7],
`where the VN nodes are of varying degrees. This is the case
`for the DVB-S2 code. In [8] we have presented a design
`method for irregular LDPC codes which can be efficiently
`processed by the decoder hardware. We used so called ir-
`regular repeat accumulate (IRA) codes [9] which are within
`the class of LDPC codes with the advantage of a very sim-
`ple (linear) encoding complexity. In general, LDPC code
`encoder are very difficult to implement due to the inherent
`complex encoding scheme.
`The LDPC codes as defined in the DVB-S2 standard
`are IRA codes, thus the encoder realization is straight for-
`ward. Furthermore, the DVB-S2 code shows regularities
`which can be exploited for an efficient hardware realization.
`
`CALTECH - EXHIBIT 2006
`Apple Inc. v. California Institute of Technology
`IPR2017-00219
`
`

`

`PSfrag replacements
`
`K information nodes (IN)
`
`N parity nodes (PN)
`
`f j
`
`f3
`
`f2
`
`Permutation P
`
`degree k
`
`CN
`
`Figure 1. Tanner graph for the DVB-S2 LDPC
`code
`
`These regularities are also the base for our methodology in-
`troduced in [8].
`In this paper we show how to exploit these regulari-
`ties and present an efficient mapping of VN and CN nodes
`to hardware instances. Memory area and access conflicts
`are most critical in this mapping process. Thus we used
`simulated annealing to minimize memory requirements and
`avoidance of RAM access conflicts.
`We present to the best of our knowledge the first IP core
`capable to process all specified code rates in the DVB-S2
`standard. We show synthesis results using a 0:13µm tech-
`nology.
`The paper is structured as follows: the DVB-S2 LDPC
`codes and the decoding algorithm are presented in Sec-
`tion 2.
`In Section 3 the mapping of nodes to hardware
`instances is explained. The overall decoder architecture is
`shown in Section 4. Section 5 gives synthesis results and
`Section 6 concludes the paper.
`
`2 DVB-S2 LDPC Codes
`
`LDPC codes are linear block codes defined by a sparse
`binary matrix (parity check matrix) H. The set of valid
`codewords x 2 C have to satisfy
`HxT = 0;
`
`8x 2 C:
`
`(1)
`
`A column in H is associated to a bit of the codeword
`and each row corresponds to a parity check. A nonzero ele-
`ment in a row means that the corresponding bit contributes
`to this parity check. The code can best be described by
`a Tanner graph [7], a graphical representation of the as-
`sociations between code bits and parity checks. Code bits
`are shown as variable nodes (circles), and parity checks as
`check nodes (squares), with edges connecting them. The
`number of edges on each node is called the node degree. If
`the node degree is identical for all variable nodes, the cor-
`responding parity check matrix is called regular, otherwise
`it’s irregular.
`By carefully inspection of the construction rules, the
`DVB-S2 parity check matrix consists of two distinctive
`
`2
`
`Rate
`1=4
`1=3
`2=5
`1=2
`3=5
`2=3
`3=4
`4=5
`5=6
`8=9
`9=10
`
`j
`12
`12
`12
`8
`12
`13
`12
`11
`13
`4
`4
`
`fj
`5400
`7200
`8640
`12960
`12960
`4320
`5400
`6480
`5400
`7200
`6480
`
`f3
`10800
`14400
`17280
`19440
`25920
`38880
`43200
`45360
`48600
`50400
`51840
`
`k
`4
`5
`6
`7
`11
`10
`14
`18
`22
`27
`30
`
`N
`49600
`43200
`38880
`32400
`25920
`21600
`16200
`12960
`10800
`7200
`6480
`
`K
`16200
`21600
`25920
`32400
`38880
`43200
`48600
`51840
`54000
`57600
`58320
`
`Table 1. Parameters describing the DVB-S2
`LDPC Tanner graph for different coderates
`
`parts: a random part dedicated to the systematic informa-
`tion, and a fixed part that belongs to the parity information.
`The Tanner graph for DVB-S2 is shown in Figure 1. There
`exist two types of variable nodes, the information (IN) and
`parity nodes (PN), corresponding to the systematic and par-
`ity bits respectively. The permutation P
`represents the ran-
`dom matrix part of the connectivity between IN and CN
`nodes, while the PN nodes are all of degree two and are
`connected in a fixed zigzag pattern to the CN nodes. The N
`check nodes have a constant degree k. The K information
`nodes consist of two subsets f j and f3, with f the number
`of IN nodes of degree j and 3. Table 1 summarizes the code
`rate dependent parameters as defined in the standard [2].
`The connectivity of the IN and CN nodes is defined by
`the DVB-S2 encoding rule
`
`p j = p j (cid:8) im;
`
`j = (x + q(m mod 360)) mod N:
`
`(2)
`
`p j is the jth parity bit, im the mth information code bit, and
`x, q, and N are code rate dependent parameters specified
`by the DVB-S2 standard. Equation 2 determines the entries
`of the parity check matrix. The mth column has nonzero
`elements in each row j, thus the permutation P
`generates
`one edge between every CN m and IN j.
`The fixed zigzag connectivity of the PN and CN nodes is
`defined by the encoding scheme:
`
`p j = p j (cid:8) p j(cid:0)1;
`
`j = 1;2; :::; N (cid:0) 1:
`
`(3)
`
`This is a simple accumulator. The corresponding part
`of the parity check matrix has two nonzero elements in
`each column, forming a square banded matrix. This type of
`LDPC codes with this simple encoding procedure are also
`called irregular repeat accumulate (IRA) codes [9].
`
`2.1 Decoding Algorithm
`
`LDPC codes can be decoded using the message pass-
`ing algorithm [3]. It exchanges soft-information iteratively
`
`

`

`a)
`
`CN0
`
`PN0
`
`CN1
`
`PN1
`
`CN2
`
`PSfrag replacements
`b)
`
`parity node update (parallel)
`
`check node update (parallel)
`
`CN0
`
`PN0
`
`CN1
`
`PN1
`
`CN2
`
`forward update (sequential)
`
`backward update (parallel)
`
`Figure 2. a) conventional message up-
`date scheme b) optimized message update
`scheme
`
`between the variable and check nodes. The update of the
`nodes can be done with a canonical scheduling [3]: In the
`first step all variable nodes must be updated, in the second
`step all check nodes respectively. The processing of indi-
`vidual nodes within one step is independent, and can thus
`be parallelized.
`The exchanged messages are assumed to be log-
`likelihood ratios (LLR). Each variable node of degree i cal-
`culates an update of message k according to:
`i(cid:0)1(cid:229)
`
`(4)
`
`l k = l ch +
`
`l;
`
`l=0;l6=k
`with l ch the corresponding channel LLR of the VN and l
`i
`the LLRs of the incident edges. The check node LLR up-
`dates are calculated according to
`
`tanh(l k=2) =
`
`i(cid:0)1
`
`tanh(l
`
`l=2):
`
`(5)
`
`l=0;l6=k
`For fixed-point implementations it was shown in [10]
`that the total quantization loss is (cid:20) 0:1db when using a 6 bit
`message quantization compared to infinite precision. For a
`5 bit message quantization the loss is 0.1-0.2 dB [7].
`
`2.2 Optimized update of degree 2 Parity Nodes
`
`The DVB standard supports LDPC codes ranging from
`code rate R = 1=4 to R = 9=10. Each code has one common
`property: the connectivity of the check nodes caused by the
`accumulator of the encoder. CN0 is alway connected to CN1
`by a variable node of degree 2 and so on for all CN nodes.
`A variable node of degree 2 has the property that the input
`of the first incident edge is the output of the second incident
`edge (plus the received channel value) and vice versa. For a
`sequential processing of the check nodes (e.g. from left to
`right in Figure 1) an already updated message can directly
`passed to the next check node due to the simple zigzag con-
`nectivity. This immediate message update changes the con-
`
`3
`
`Rate
`1=4
`1=3
`2=5
`1=2
`3=5
`2=3
`3=4
`4=5
`5=6
`8=9
`9=10
`
`q
`135
`120
`108
`90
`72
`60
`45
`36
`30
`20
`18
`
`EPN
`97199
`86399
`77759
`64799
`51839
`43199
`32399
`25919
`21599
`14399
`12959
`
`EIN
`97200
`129600
`155520
`162000
`233280
`172800
`194400
`207360
`216000
`180000
`181440
`
`Addr
`270
`360
`432
`450
`648
`480
`540
`576
`600
`500
`504
`
`Table 2. Code rate dependent parameters,
`with E the number of incident edges of IN and
`PN nodes and Addr the number of values re-
`quired to store the code stucture
`
`ventional update scheme between CN an VN nodes (Equa-
`tion 4).
`The difference in the update scheme is presented in Fig-
`ure 2. Only the connectivity between check nodes and par-
`ity nodes is depicted, the incident edges from the informa-
`tion nodes are omitted. Figure 2a) shows the standard belief
`propagation with the two phase update. In the first phase all
`messages from the PN to CN nodes are updated, in the sec-
`ond phase the messages from CN to PN nodes respectively.
`The message update within one phase is commutative and
`can be fully parallized. Figure 2b) shows our new message
`update scheme in which the new CN message is directly
`passed to the next CN node. This data flow is denoted as
`a forward update and corresponds to a sequential message
`update. The backwards update from the PN to CN nodes is
`again a parallel update. Note that a sequential backwards
`update would result in a maximum a posteriori (MAP) al-
`gorithm.
`This new update scheme improves the communications
`performance. For the same communications performance
`10 iterations can be saved i.e. 30 iterations instead of 40
`have to be used. Furthermore we need to store only one
`message instead of two messages for the next iteration,
`which is explained in more detail in Section 4.
`
`3 Hardware mapping
`
`As already mentioned only partly parallel architectures
`are feasible. Hence only a subset P of the nodes are instan-
`tiated. The variable and check nodes have to be mapped on
`these P functional units. All messages have to be stored dur-
`ing the iterative process, while taking care of RAM access
`conflicts. Furthermore we need a permutation networks
`which provides the connectivity of the Tanner graph.
`
`l
`(cid:213)
`

`

`tional unit a RAM is associated to hold the corresponding
`messages (edges). Please note that for each IN of degree
`8, 8 storage places are allocated to this VN, because each
`incident edge has to be stored.
`The check nodes mapping depends on the rate depen-
`dent factor q. For R = 1=2 the first q = 90 CN nodes are
`mapped to the first functional unit. The next 90 CN nodes
`are mapped to the next producer and so on. Again the CN
`number corresponds to CN degree storage locations.
`This node mapping is the key for an efficient hardware
`realization, since it enables to use a simple shuffling net-
`work to provide the connectivity of the Tanner graph. The
`shuffling network ensures that at each cycle 360 input mes-
`sages are shuffled to 360 distinct target memories. Thus we
`have to store EIN=390 = 450 shuffling and addressing infor-
`mation for the R = 1=2 code, see Table 2 for the other code
`rates. The shuffling offsets and addresses can be extracted
`from the x tables provided by [2].
`
`4 Decoder Architecture
`
`Based on the message mapping described in the previ-
`ous chapter, the basic architecture of the DVB-S2 LDPC
`decoder is shown in Figure 4. It consists of functional units
`which can process the functionality of variable and check
`nodes. This is possible, since only one type of the node are
`processed during one half iteration. The IN message memo-
`ries banks hold the messages which are exchanged between
`information and check nodes. Furthermore we have memo-
`ries for storing the exchanged messages for the parity nodes
`(PN message memories), which are all of degree two. The
`address and shuffling RAM together with the shuffling net-
`work provides the connectivity of the Tanner graph.
`As mentioned the decoder processes 360 nodes in par-
`allel so 360 messages have to be provided per cycle. All
`360 messages are read from the same address from the IN
`message memory bank. Though, for the information node
`processing we just increment the reading address. The func-
`tional unit can accept each clock cycle new data, while a
`control flag just labels the last message belonging to a node
`and starts the output processing. The newly produced 360
`messages are then written back to the same address loca-
`tion but with a cyclic shift, caused by the shuffling network.
`To process the check nodes we have to read from dedicated
`addresses, provided by the address RAM. These addresses
`were extracted from node mapping as described in the pre-
`vious chapter. Again 360 messages are read per clock cycle
`and written back to the same address after the processing
`via the shuffling network. This ensures that the messages
`are shuffled back to their original position.
`The processing of the parity nodes can be done con-
`currently during the check node processing, by using the
`update scheme described in Section 2.2. Each functional
`
`shift value
`
`0
`111
`304
`59
`3
`190
`219
`140
`0
`94
`...
`
`reading address
`48
`65
`113
`420
`330
`332
`399
`202
`280
`513
`...
`
`360 message RAM banks
`359
`2
`721
`362
`1079
`722
`1439
`1082
`1799
`1442
`2159
`1802
`2519
`2162
`---
`---
`32399
`32042
`
`1
`361
`721
`1081
`1441
`1801
`2161
`---
`32041
`
`0
`360
`720
`1080
`1440
`1800
`2160
`---
`32040
`
`VN
`
`VN
`
`VN
`
`VN
`
`Information Nodes
`message mapping
`
`VN functional
`units
`
`shuffling
`network
`
`32310
`32311
`32312
`32313
`32314
`32315
`32316
`...
`32399
`
`CN
`
`90
`91
`92
`93
`94
`95
`96
`---
`179
`
`180
`181
`182
`183
`184
`185
`186
`---
`269
`
`0123456
`
`---
`89
`
`PSfrag replacements
`
`Check Nodes
`message mapping
`
`CN functional
`units
`
`CN
`
`CN
`
`CN
`
`l ch + l
`
`iter
`
`Figure 3. Message and functional unit map-
`ping for R = 1=2
`
`We can split the set of edges E connecting the check
`nodes in two subsets EIN and EPN, indicating the connec-
`tions between CN/IN nodes and CN/PN nodes respectively.
`The subsets are shown in Table 2 for each code rate. Fur-
`thermore the q factor of Equation 2 is listed. The implemen-
`tation of EIN is the challenging part, since this connectivity
`(P
`) changes for each code rate. The realization of EPN is
`straightforward, thus we focus on the mapping of the IN
`and CN nodes.
`Due to the varying node degrees the functional nodes
`process all incoming messages in a serial manner. Thus a
`functional node can except one message per clock cycle and
`produces at most one updated message per clock cycle.
`A careful analysis of Equation 2 shows that the connec-
`tivity of 360 edges of distinct information nodes are deter-
`mined by just one value x, while q is a code rate dependent
`constant, see Table 2.
`These 360 edges can be processed simultaneously by
`P = 360 functional units. Within a half iteration a func-
`tional unit has to process q (cid:3) (k (cid:0) 2) edges. (k (cid:0) 2) is the
`number of edges between one check node and information
`nodes. For each code rate q was chosen to satisfy the con-
`straint
`
`EIN=360 = q (cid:3) (k (cid:0) 2):
`It guarantees that each functional unit has to process the
`same amount of nodes which simplifies the node mapping.
`Figure 3 shows the mapping of the IN and CN nodes for the
`LDPC code of rate R = 1=2. Always 360 consecutive VN
`nodes are mapped to 360 functional units. To each func-
`
`(6)
`
`4
`
`

`

`PNmessagememory
`
`PNmessagememory
`
`PNmessagememory
`
`PNmessagememory
`
`INmessagememoryblock
`
`f
`
`CHRAM
`
`INmessagememoryblock
`
`f
`
`CHRAM
`
`INmessagememoryblock
`
`f
`
`CHRAM
`
`shufffling network P
`
`INmessagememoryblock
`
`f
`
`CHRAM
`
`addressRAM
`
`shufflingRAM
`
`PSfrag replacements
`
`buffer
`
`CH RAM
`
`Figure 4. Basic architecture of our LDPC decoder
`
`unit processes consecutive check nodes (Figure 3). The
`message which is passed during the forward update of the
`check nodes is kept in the functional unit. Only the mes-
`sages of the backward update has to be stored which re-
`duces the memory requirements for the zigzag connectivity
`to EPN=2 messages. The PN message memories are only
`read and written during the check node phase, while the
`channel (CH) RAMs delivers the corresponding received
`channel value.
`We use single port SRAMs due to area and power ef-
`ficiency. Hence we have to take care of read/write con-
`flicts during the iterative process. Read/write conflicts oc-
`cur, since data are continously read from the 360 RAMs and
`provided to the functional units, while new processed mes-
`sages have to be written back.
`The check node processing is the most critical part.
`We have to read from dedicated addresses extracted dur-
`ing the mapping process. Therefore, the IN message mem-
`ory block is partitioned in 4 RAMs which is shown in Fig-
`ure 5. Even if the commutativity of the message processing
`within a check node is exploited all write conflicts can not
`be avoided. Therefore a buffer is required to hold a mes-
`sage if writing is not possible due to a conflict. We use
`simulated annealing to find the best addressing scheme to
`reduce RAM access conflicts and hence to minimize the
`buffer overhead. This optimization step ensures that only
`one buffer is required which holds for all code rates. Per
`clock cycle we read data from one RAM, and write at most
`2 data back to two distinct RAMs, coming from the buffers
`or the shuffling network. The two least significant bits of
`the addresses determines the assignment to a partition. This
`
`allows a simple control flow, which just has to compare the
`reading and the writing addresses of the current clock cycle.
`The resulting decoder throughput T is
`
`T =
`
`(cid:1) fcyc;
`
`(7)
`
`I
`#cyc
`with I the number of information bits to be decoded and
`#cyc the number of cycles to decode one block including
`the input/output (I/O) processing.
`The number of cycles is calculated as C
`PIO
`Thus Equation 7 yields:
`
`+ It (cid:1)(cid:16)2 (cid:1) EIN
`P (cid:17).
`
`T =
`
`(cid:1) fcycle:
`
`(8)
`
`I
`+ It (cid:1)(cid:16)2 (cid:1) ( EINP + Tlatency)(cid:17)
`
`C
`PIO
`The part C
`is the number of cycles for input/output
`PIO
`(I/O) processing. The decoder is capable to receive 10 chan-
`nel values per clock cycle. Reading a new codeword of size
`C and writing the result of the prior processed block can be
`done in parallel with reading/writing PIO data concurrently.
`The latency Tlatency for each iteration depends on the pro-
`cessing units and the shuffling network.
`
`5 Results
`
`The LDPC decoder is implemented as a synthesizable
`VHDL model. Results are obtained with the Synopsis
`Design Compiler based on a ST Microelectronics 0:13µm
`CMOS technology. The maximum clock frequency is 270
`MHz under worst case conditions. The decoder is capable
`to process all specified code rates of the DVB standard with
`
`5
`
`

`

`0:13µm technologie
`
`RAMs
`
`Logic
`
`channel LLRs
`Messages
`Address/Shuffling
`Functional Nodes
`control logic
`Shuffling Network
`Total Area [mm2]
`
`AREA
`[mm2]
`1.997
`9.117
`0.075
`10.8
`0.2
`0.55
`22.739
`
`address
`
`decoder
`
`Table 3. Synthesis Results for the DVB-S2
`LDPC code decoder
`
`output
`
`7 Acknowledgments
`
`RAM 1 RAM 2 RAM 3 RAM 4
`
`input
`
`buffer
`
`IN message memory block
`
`PSfrag replacements
`
`Figure 5. Hierarchical RAM structure
`
`the required throughput of 255Mbit/s. 30 iterations are as-
`sumed.
`Table 3 shows the synthesis results for a 6 bit message
`quantization of the channel values and the exchanged mes-
`sages. The overall area is 22:74mm2. The area is deter-
`mined by different code rates.
`R = 1=4 has the largest set of parity nodes and defines
`the size of the PN message memories. While the rate R =
`3=5 has the most edges to the informtion nodes and hence
`determines the size of the IN message memory banks. The
`size of a functional node depends on the maximum IN and
`PN degree, respectivly (R = 2=3 and R = 9=10).
`The area is splitted in three parts: RAMs, logic and the
`shuffling network. Storing the messages yields the major
`part of the RAM area with 9:12mm2. It is important to note,
`that only an area of 0:075mm2 is required to store the con-
`nectivity of the Tanner graph. This shows the efficiency
`of our architectural approach. The logic area of the func-
`tional nodes with 10:8mm2 is a major part of the overall
`area. This is due to the required flexibility of the different
`code rates. We also placed and routed the shuffling network
`to test routing congestions. Due to its regularity no conges-
`tions resulted, its area is dominated by the logic cells.
`
`6 Conclusion
`
`Low-Density Parity-Check codes are part of the new
`DVB-S2 standard. In this paper we presented to the best
`of our knowledge the first published IP core for DVB-S2
`LDPC decoding. We explained how to explore the code
`structure for an efficient hardware mapping and presented
`a decoder architecture which can process all specified code
`rates ranging from R = 1=4 to R = 9=10.
`
`6
`
`The work presented in this paper was supported by the
`European IST project 4More 4G MC-CDMA multiple an-
`tenna system On chip for Radio Enhancements [1].
`Our special thanks goes to Friedbert Berens from the
`Advanced System Technology Group of STM, Geneva,
`Switzerland, for many valuable discussions.
`
`References
`
`[1] http://ist-4more.org.
`[2] European Telecommunications Standards Institude (ETSI).
`Digital Video Broadcasting (DVB) Second generation fram-
`ing structure for broadband satellite applications; EN 302
`307 V1.1.1. www.dvb.org.
`[3] R. G. Gallager. Low-Density Parity-Check Codes. M.I.T.
`Press, Cambridge,Massachusetts, 1963.
`[4] C. Berrou. The Ten-Year-Old Turbo Codes are Entering
`into Service.
`IEEE Communications Magazine, 41:110–
`116, Aug. 2003.
`[5] A. Blanksby and C. J. Howland. A 690-mW 1-Gb/s, Rate-
`1/2 Low-Density Parity-Check Code Decoder. IEEE Journal
`of Solid-State Circuits, 37(3):404–412, Mar. 2002.
`[6] E. Boutillon, J. Castura, and F. Kschischang. Decoder-
`first code design.
`In Proc. 2nd International Symposium
`on Turbo Codes & Related Topics, pages 459–462, Brest,
`France, Sept. 2000.
`[7] T. Richardson and R. Urbanke. The Renaissance of Gal-
`lager’s Low-Density Pariy-Check Codes. IEEE Communi-
`cations Magazine, 41:126–131, Aug. 2003.
`[8] F. Kienle and N. Wehn. Design Methodology for IRA
`Codes. In Proc. 2004 Asia South Pacific Design Automation
`Conference (ASP-DAC ’04), Yokohama, Japan, Jan. 2004.
`[9] H. Jin, A. Khandekar, and R. McEliece. Irregular Repeat-
`Accumulate Codes. In Proc. 2nd International Symposium
`on Turbo Codes & Related Topics, pages 1–8, Brest, France,
`Sept. 2000.
`[10] T. Zhang, Z. Wang, and K. Parhi. On finite precision im-
`plementation of low-density parity-check codes decoder. In
`Proc.International Symposium on Circuits and Systems (IS-
`CAS ’01), Antwerp,Belgium, May 2001.
`
`