Techniques and Architectures for Hazard-Free Semi-Parallel Decoding of LDPC Codes

4.1. System Notation

Without any lack of generality, let us identify a layer with one single parity-check node and focusing on the set of soft-outputs participating to layer , let us define the following subsets:

(i) , the set of SOs in common with layer ;

(ii) , the set of SOs in common with layer and not in ;

(iii) , the set of SOs in common with both layers and ;

(iv) , the set of SOs in common with layer and not in or ;

(v) , the set of SOs in common with layer but not in , , ;

(vi) , the set of SOs in common with both layers and , but not in or ;

(vii) , the set of remaining SOs.

In the definitions above the notation means the relative complement of in or the set-theoretic difference of and . Let us also define the following cardinalities: (degree of layer ), , , , , , , .

4.2. Equal Output Processing

First, let us consider a very straightforward and implementation friendly architecture of the node processor that updates (and so delivers) the soft-output messages with the same order used to take them in.

In such a case it would be desirable to (i) postpone the acquisition of messages updated by the previous layer, that is, messages in , and (ii) output the messages in as soon as possible to let the next layer start earlier. Actually, the last constraint only holds when does not include any message common to layer , that is, when ; otherwise, the set could be acquired at any time before .

Figure 4 shows the I/O data streams of an equal output processing (EOP) unit. Here, is the latency of the SO data-path, including the elaboration in the NP, the scrambling, and the two memory accesses (reading and writing). Focusing on layer , the set cannot be assigned to any specific position within , since the whole is acquired according to the same order used by layer to output (and so also acquire) the sets and . For this reason, the situation plotted in Figure 4 is only for the sake of a clearer drawing.

With reference to Figure 4, pipeline hazards are cleared if idle cycles are spent between layer and so that

(5)

with for and otherwise. This means that if is empty, then the messages in do not need to be waited for. The solution to (5) with minimum latency is

(6)

Note that (5) and (6) only hold under the hypothesis of leading within . If this is not the case, up to extra idle cycles could be added if is output last within .

So far, we have only focused on the interaction between two consecutive layers; however, violations could also arise between layer and . Despite this possibility, this issue is not treated here, as it is typically mitigated by the same idle cycles already inserted between layers and and between layers and .

4.3. Reversed Output Processing

Depending on the particular structure of the parity-check matrix , it may occur that the most of the messages of layer in common with layer are also shared with layer , that is, and . If this condition holds, as for the WLAN LDPC codes (see Figure 11), it can be worth reversing the output order of SOs so that the messages in can be both acquired last and output first.

Figure 5(a) shows the I/O streams of a reversed output processing (ROP) unit. Exploiting the reversal mechanism, the set is acquired second-last, just before , so that it is available earlier for layer .

Following a reasoning similar to EOP, the situation sketched in Figure 5(a) where is delivered first within is just for an easier representation, and the condition for hazard-free layered decoding is now

(7)

Indeed, when , one could output first in , and so get rid of the term . However, since is actually left floating within , (7) represents again a best-case scenario, and up to extra idle cycles could be required. From (7), the minimum latency solution is

(8)

Similarly to EOP, the ROP strategy also suffers from pipeline hazards between three consecutive layers, and because of the reversed output order, the issue is more relevant now. This situation is sketched in Figure 5(b), where the sets , , and are managed similarly to , and . The ROP strategy is then instructed to acquire the set later and to output earlier. However, the situation is complicated by the fact that the set may not entirely coincide with ; rather it is , since some of the messages in can be found in . This is highlighted in Figure 5(b), where those messages of and not delivered to are shown in dark grey.

To clear the hazards between three layers, additional idle cycles are added in the number of

(9)

where is the acquisition margin on layer , and is the writing-out margin on layer . These can be computed under the assumption of no hazard between layer and (i.e., is aligned with thanks to as shown in Figure 5(b)) and are given by

(10)

The margin is actually nonnull only if ; otherwise, under the hypothesis that (i) the set is output first within , and (ii) within , the messages not in are output last.

Overall, the number of idle cycles of ROP is given by

(11)

4.4. Unconstrained Output Processing

Fewer idle cycles are expected if the orders used for input and output are not constrained to each other. This implies that layer can still delay the acquisition of the messages updated by layer (i.e., messages in ) as usual, but at the same time the messages common to layer (i.e., in ) can also be delivered earlier.

The input and output data streams of an unconstrained output processing (UOP) unit are shown in Figure 6. Now, hazard-free layered decoding is achieved when

(12)

which yields

(13)

Regarding the interaction between three consecutive layers, if the messages common to layer (i.e., in ) are output just after , and if on layer , the set is taken just before , then there is no risk of pipeline hazard between layer and .

4.5. Decoding of Irregular Codes

A serial processor cannot process consecutive layers with decreasing degrees, , as the pipeline of the internal elaborations would be corrupted and the output messages of the two layers would overlap in time. This is not but another kind of pipeline hazard, and again, it can be solved by delaying the update of the second layer with idle cycles.

Since this type of hazard is independent of that seen above, the same idle cycles may help to solve both issues. For this reason, the overall number of idle cycles becomes

(14)

with being computed according to (6), (11), or (13).

4.6. Optimal Sequence of Layers

For a given reordering strategy, the overall number of idle cycles per decoding iteration is a function of the actual sequence of layers used for the decoding. For a code with layers, the optimal sequence of layer minimizing the time spent in idle is given by

(15)

where is the number of idle cycles between layer and for the generic permutation and is given by (14), and is the set of the possible permutations of layers.

The minimization problem in (15) can be solved by means of a brute-force computer search and results in the definition of a permuted parity-check matrix , whose layers are scrambled according to the optimal permutation . Then, within each layer of , the order to update the nonnull subblocks is given by the strategy in use among EOP, ROP, and UOP.

4.7. Summary and Results

The three methods proposed in this section are differently effective to minimize the overall time spent in idle. Although UOP is expected to yield the smallest latency, the results strongly depend on the considered LDPC code, and ROP and EOP can be very close to UOP. As a case-example, results will be shown in Section 7 for the WLAN LDPC codes.

However, the effectiveness of the individual methods must be weighed up in view of the requirements of the underlying decoder architecture and the costs of its hardware implementation, which is the objective of Section 5. Thus, UOP generally requires bigger complexity in hardware, and EOP or ROP can be preferred for particular codes.

5.1. Local Variable-to-Check Buffer

The most straightforward architecture of a vectorized layered decoder is shown in Figure 7. Here, the arrays of v2c messages entering the CNUs during the update of layer , are computed on-the-fly as with , and both the arrays of c2v and SO messages are retrieved from memory.

Then, the updated c2v messages are used to refine every array of SOs belonging to layer : according to line 13 of Algorithm 1, this is done by adding the new c2v array to the input v2c array . Since the CNUs work in pipeline, while the update of layer is still progress, the array of the v2c messages belonging to layer is already being computed as , with . For this reason, needs to be temporarily stored in a local buffer as shown in Figure 7. The buffer is vectorized as well and stores messages, with the maximum CN degree in the code.

Before being stored back in memory, the array is circularly shifted and made ready for its next use, by applying compound or incremental rotations [12]; this operation is carried out by the circular shifting network of Figure 7, and more details about its architecture are available in [24].

The v2c buffer is the key element that allows the architecture to work in pipeline. This has to sustain one reading and one writing access concurrently and can be efficiently implemented with shift-register based architectures for EOP (first-in, first-out, FIFO buffer) and ROP (last-in, first-out, LIFO buffer). On the contrary, UOP needs to map the buffer onto a dual-port memory bank, whose (reading) address is provided by and extra configuration memory (ROM).

5.2. Double Memory Access

The buffer of Arch. V-A can be removed if the v2c messages are computed twice on-the-fly, as shown in Figure 8: the first time to feed the array of CNUs, and then to update the SOs. To this aim, a further reading is required to get the arrays and from memory, and so recompute the array on the CNUs output.

It follows that three-port memories are needed for both SO and c2v messages since three concurrent accesses have to be supported: two readings (see ports and in Figure 8) and one writing. This memory can be implemented by distributing data on several banks of customary dual-port memory, in such a way that two readings always involve different banks. Actually, in a layered decoder a same memory location needs to be accessed several times per iteration and concurrently to several other data, so that resorting to only two memory banks would be unfeasible. On the other hand, the management of a higher number of banks would add a significant overhead to the complexity of the whole design.

The proposed solution is sketched in Figure 9 and is based on only two banks (A and B) but, to clear access conflicts, some data are redundantly stored in both the banks (see elements C1 and C2 in the example of Figure 9).

The most trivial and expensive solution is achieved when both banks are a full copy or a mirror of the original memory as in [11], which corresponds to redundancy. Conversely to this route, data can be selectively assigned to the two banks through computer search aiming at a minimum redundancy.

Roughly speaking, if we denote by the cardinality of the set of data (SO or c2v messages) read concurrently to the th data for , then the higher is (for a given ), the higher is the expected redundancy. So, a small redundancy is experienced by the c2v memory, since each c2v message can collide with at most two other data (i.e., ), while a higher redundancy is associated to the SO memory, since every SO can face up to conflicts, with being the degree of the th variable node, typically greater than (especially for low-rate codes).

Indeed, the issue of memory partitioning and the reordering techniques described in Section 4 are linked to each other: whenever the CNUs are in idle, only one reading is performed. Therefore, an overall system optimization aiming at minimizing the iteration latency and the amount of memory redundancy at the same time could be pursued; however, due to the huge optimization space, this task is almost unfeasible and is not considered in this work.

5.3. Storage of Variable-to-Check Messages

During the elaboration of a generic layer, a certain v2c message is needed twice, and a local buffer or multiple memory reading operations were implemented in Arch. V-A and Arch. V-B, respectively.

A third way of solving the problem is computing the array of v2c messages only once per iteration, like in Arch. V-A, but instead of using a local buffer, the v2c messages are precomputed and stored in the SO memory ready for the next use, as sketched in Figure 10. A similar architecture is used in [10, 16] but the issue of decoding pipeline is not clearly stated there.

In this way, the SO memory turns into a v2c memory with the following meaning: the array updated by layer is stored in memory after marginalization with the c2v message , with being the index of the next layer reusing the same array of SOs, . In other words, the array of v2c messages involved in the next update of the same block-column is precomputed. Therefore, the data stored in the v2c memory are used twice, first to feed the array of CNUs, and then for the SOs update.

Similarly to Arch. V-B, a three-port memory would be required because of the decoding pipeline; the same considerations of Section 5.2 still hold, and an optimum partitioning of the v2c memory onto two banks with some redundancy can be found. Note that, as opposed to Arch. V-B, a customary dual-port memory is enough for c2v messages.

As far as the complexity is concerned, at first glance this solution seems to be preferable to Arch. V-B since it needs only two stages of parallel adders while the c2v memory is not split. However, the management of the reading ports of the v2c memory introduces significant overheads, since after the update of the soft outputs by layer , the memory controller must be aware of what is the next layer using the same soft outputs . This information needs to be stored in a dedicated configuration memory, whose size and area can be significant, especially in a multilength, multirate decoder.

6.1. LDPC Code Construction

The WLAN standard [3] defines AA-LDPC codes based on circulants of the identity matrix. Three different codeword lengths are supported, , and , each coming with four code rates, , , and , for a total of different codes. As a distinguishing feature, a different block-size is used for each codeword length, that is, , and , respectively; accordingly, every code counts block-columns, while the block-rows (layers) are in the number of for code rates , , and , respectively.

An example of the base-matrix for the code with length and rate is shown in Figure 11.

6.2. Multiframe Decoder Architecture

In order to attain an adequate throughput for every WLAN codes, the decoder must include a number of CNUs at least equal to . This means that two thirds of the processors would remain unused with the shortest codes.

In the latter case, the throughput can be increased thanks to a multiframe approach, where frames of the code with block-size are decoded in parallel. A similar solution is described in [12], but in that case two different frames are decoded in time-division multiplexing by exploiting the 2 nonoverlapped phases of the flooding algorithm. Here, frames are decoded concurrently, and more specifically, three different frames of the shortest code can be assigned to a cluster of 27 CNUs each.

Note that to work properly, the circular shifting network must support concurrent subrotations as described in [24].

7.1. Latency and Throughput

The latency of a pipelined LDPC decoder can be expressed as

(16)

with being the clock period, being the number of iterations, being the number of nonnull blocks in the code, being the number of idle cycles per iteration, being the cycles to empty the decoder pipelin and finally, being the cycles for the input/output interface. Among the parameters above, is set for good error-correction performance, is a code-dependent parameter, and is fixed by the I/O management; thus, for a minimum latency, the designer can only act on , whose value can be optimised with the techniques of Section 4.

Focusing on the IEEE 802.11n codes, Table 1 shows the overall number of cycles for 12 iterations ( ), the number of idle cycles per iteration ( ), the percentage of idle cycles with respect to the total (idling %), and the throughput at the clock frequency of  MHz.

Code lenght
Code rate
Original		2299	1763	1779	1486	2106	1715	1886	1653	2107	1775	1752	1603
		91	46	47	22	81	46	60	43	77	47	48	41
	idling %	47%	31%	31%	17%	46%	32%	38%	31%	44%	31%	32%	30%
	(Mbps)	101	176	197	262	74	121	124	157	111	175	200	243
EOP		1927	1691	1575	1462	1819	1643	1527	1377	1855	1691	1538	1352
		60	40	30	20	57	40	30	20	56	40	30	20
	idling %	37%	28%	23%	16%	37%	29%	23%	17%	36%	28%	23%	17%
	(Mbps)	121	184	222	266	85	126	153	188	126	184	228	288
ROP		1308	1216	1290	1403	1223	1168	1239	1330	1283	1228	1243	1305
		8	0	6	15	7	0	6	16	8	1	5	16
	idling %	7.3%	0%	5.5%	13%	6.8%	0%	5.5%	14%	7.4%	1%	4.8%	14%
	(Mbps)	178	256	271	277	127	178	188	195	182	253	282	298
UOP		1308	1216	1243	1380	1187	1168	1195	1260	1259	1216	1195	1164
		8	0	2	13	4	0	2	10	6	0	1	4
	idling %	7.3%	0%	1.9%	11%	4%	0%	2%	9.3%	5.6%	0%	0.9%	4%
	(Mbps)	178	256	282	282	131	178	195	206	185	256	293	334

The latter is expressed in information bits decoded per time unit and is also referred to as net throughput:

(17)

where is the number of frames decoded in parallel. For this reason, the figures of Table 1 for the short codes are very similar to those for the long codes ( ); on the contrary, the middle codes do not benefit from the same mechanism (i.e., ) and their throughput is scaled down by a factor 2/3.

The results of Table 1 are for every technique of Section 4 as well as for the original codes before optimization. Although EOP clearly outperforms the original codes, better results are achieved with ROP and UOP for the WLAN case example, where at most 14% and 11% of the decoding time are spent in idle, respectively. On average, the decoding time decreases from 7.6 to 6.7 ns with EOP and even to 5.3 ns with ROP and 5.1 ns with UOP. This behaviour can be explained by considering that for the WLAN codes the term found in (6) for EOP is significantly nonnull, while comparing (8) to (13), ROP and UOP basically differ for the term , which is negligible for the WLAN codes.

7.2. Error-Correction Performance

Figure 13 compares the floating point frame error rate (FER) after 12 decoding iterations of a pipelined decoder using EOP, ROP, and UOP with a reference curve obtained by simulating the original parity-check matrix before optimization, in a nonpipelined decoder. Two simulations were run for each strategy, one with the proper number of idle cycles (curves with full markers), and the other without idle cycles and referred to as full pipeline mode (curves with empty markers).

As expected, the three strategies reach the reference curve of the HLD algorithm when properly idled. Then, in case of full pipeline ( ), the performance of EOP are spoiled, while ROP and UOP only pay about 0.6 and 0.3 dB, respectively. This means that the reordering has significantly reduced the dependence between layers and only few hazards arise without idle cycles.

Similarly to EOP, no received codeword is successfully decoded even at high SNRs (i.e., ) if the original code descriptors are simulated in full pipeline. This confirms once more the importance of idle cycles in a pipelined HLD decoding decoder and motivates the need of an optimization technique.

Considering the same scenario of Figure 13, Figure 14 shows the convergence speed, measured in average number of iterations, of the layered decoding algorithm. The curves confirm that HLD needs one half of the number of iterations of the flooding schedule, on average, and show that the full pipeline mode is also penalized in terms of speed.