LDPC Simulation With CUDA GPU

Transcription

1 LDPC Simulation With CUDA GPU EE179 Final Project Kangping Hu June 3 rd 2014

2 1 1. Introduction This project is about simulating the performance of binary Low-Density-Parity-Check-Matrix (LDPC) Code with AWGN channel. Since a lot of parallel computations are needed for the encoding and the iterative decoding algorithms, parallel GPU programming with CUDA is used to improve the simulation efficiency. This report will go through the encoding algorithm, decoding algorithm, channel model, simulation procedure, and simulation results. 2. Encoding algorithm The generator matrix and parity check matrix are generated by MATLAB before they are input to CUDA. Four sets of LDPC codes are used: Two (6,3) codes, one with random and one with structured parity check matrix. The random one: H = [ ] The structured one: H = [ ] = [ ] Two (15,10) codes, both with random parity check matrix. The generator matrix are produced by first convert the parity check matrix to standard form through Gaussian Elimination, then the generator and parity check matrix follow the relationship: where G is the generator matrix with dimension k x n, and H is the Parity check matrix with dimension n-k x n.

3 2 Then by multiplying each k-bit symbol with the generator matrix, the n-bit code words are produced. In this simulation, symbol -1 corresponds to 1, and symbol 1 corresponds to Decoding algorithm The decoding algorithm used for this simulation is hard decoding with Gallager A algorithm. It works as follows: a. Hard decoding is first performed on the receiving bits. Since 0->1, and 1->-1, any value larger than 0 will be interpreted as 0, and any value less than 0 will be interpreted as 1. b. Set up the receiving nodes and check nodes based on the parity check matrix. Suppose the parity check matrix with 3 check nodes and 6 receiving nodes is: Then the structure formed between the receiving and check nodes will be: where the upper nodes and the receiving nodes, and the lower nodes are the check nodes. (Reference from wiki: c. Once the receiving nodes receive the bits, they will forward their bits to the check nodes.

4 3 d. Each check node will calculate the sum of all the incoming bits. Since binary codes are used here, addition is performed as module 2. A sum of 0 means the check is valid, and the same bits will be transmitted back to check nodes. Otherwise, a sum of 1 means there is something wrong, and the check nodes will transmit the flipped bit back to receiving nodes e. Once having received the feedback from the check nodes, each receiving nodes will do a majority vote. If the majority of the feedback from check node is against its original bit, then it is likely that the original bit is wrong, and will be flipped. f. The receiving nodes will then send their bits to the check nodes and repeat the procedures. Once a valid code word is found, or some maximum iteration step is reached, the decoding will stop. 4. Channel model The channel model used for the simulation is the Additive White Gaussian Noise (AWGN) channel with received symbols yi, where: And from log(k)/n. is a Gaussian random variable with zero mean and variance = 1/(2REb/No), where R is calculated

5 4 5. Simulation Procedure Below is the flow diagram for the whole simulation process:

6 5 LDPC code usually has huge generator and parity check matrix filled with a lot of zeros and few ones. So my first step is to generate and store all the possible code words based on dimension of generator matrix (2^k of them) using CUDA kernel functions. Then I generate some index arrays for the receiving nodes and check nodes to form the decoding structure. Stepping into the simulation process, I first generate n Gaussian Distributed noise based on the desired Eb/No variance. Then I use kernel functions to add the noise to the selected symbol, and perform hard decoding. After that, the receiving node buffers will update the code that was just being hard decoded, got rearranged based on the indexes generated before, and stored in check node buffer. Each thread would be responsible for one receiving nodes in the arrangement. After receiving the bits from receiving nodes, each thread will perform on behalf of each check node to validate the sum of all bits to that node. The updated bits will be rearranged and transmitted back to the receiving nodes. Each thread will then perform as a receiving node to make a majority vote to decide if it should change its original bit. Once updated, each thread will perform a search in the code word list to see if the updated code is found in the code word list. This process will continue until the maximum iteration is reached, or a code word is found. Finally, the percentage of wrong code words and symbols will be recorded.

7 6 6. Simulation Results Total 4 sets of LDPC codes are simulated, two (6,3) codes and two (15,10) codes, with iteration steps of 3 and 10. The symbol-error-rate and word-error-rate figures are plotted by MATLAB scripts: In theory, I should expect some waterfall features where the error probability reaches error floor due to the low weight words. However, this doesn t show up since the number of simulation samples is only 10^4. For the (6,3) codes, it seems that the structured parity check matrix is slightly better than the random ones. The symbol error rate is lower than the word error rate, which is expected. Several things can affect the decoding accuracy of LDPC. The iteration steps for (6,3) codes are set to 3, and for (15,10) codes are set to 10. This may turn out to be not sufficient. Also the majority vote process is set to be half-half. If optimal decoding is used, the error rate could be further reduced.

8 7 7. Advantage of GPU for this simulation The reason that GPU helps here is that this encoding and decoding algorithm requires a lot of repeating simple arithmetic operations. For the encoding side, each symbol (an array) will need to multiply a generator (a matrix) to generate valid code words. The test case only contains up to 2^10, which is 1024 code words. However, for an actual ldpc code that is being used today, it typically has thousands of bits length, thus a lot of matrix multiplication will be needed. And here each thread can produce one code word. As for decoding, there is a lot of communication between the receiving nodes and the check nodes. Each thread can operate on behalf of either a receiving node or check nodes, either for memory rearrangement and majority vote. For the channel model, Gaussian Noise needed to be added to a code for each simulation sample to ensure the randomness, thus the fairness and reliability of the simulation. In this project, the Gaussian noise is added through CURAND Device API. Each thread is responsible for adding noise to one bit of the code word, and the following hard decoding of the code word. After each decoding iteration, we need to check if we already have a valid code word. If so, further iteration is not needed. This code work loop up operation can also get speed up, with one thread checking the word with one code word in the pre-generate code word list. And find out the original symbol, count the bits difference in the code word and symbol for further statistical analysis. For memory consideration, I tried to avoid unnecessary movement of memory between device and kernel. The code list and symbol list are pre-generated and stays in device memory throughout the simulation. The encoding, decoding and word loop up operations all happen in the kernel. The only data that moves in and out between device and host are the randomly selected code word s index, and the record of symbol and word error bits. Four relatively small ldps codes are tested for this project, and they each takes about half an hour to finish, which would otherwise takes much longer for a multi-core CPU to run. This ldpc code was actually invented back in 1960s, and it was ignored for a while because of its impossible computation demands at that time. Until recently it caught people s attention because we now have the computation power to use the code, and it turns out to be the best code in terms of channel capacity. In this project, using GPU to simulate the performance of this ldpc codes does meet my expectation. The parallelism that can be exploited is on the order of n or k. Since the decoding algorithm operates the same on each single check node and receiving nodes. With a typical ldpc code of length 1000, ideally, we can improve the efficiency by File Submission I submit two folders for this project. The one with name LDPC_Simple_Check has the decoding algorithm in it. You can test its correctness by changing the H, G Matrix, n and k value, iteration steps, and the input word. The other folder named LDPC_Simple_Check has all the CUDA file, MATLAB files, and simulation results in it. The make files are configured for compiling with Minuteman or Polaris machine located ANB Instruction Lab.

9 8 To run, change n and k in LDPC_main to 6 and 3 for G63_random.txt and G63_structured.txt. Or change n and k to 15 and 10 for G_1510random1.txt and G1510_random2.txt. The input file name will also needed to be changed Sorry for making it not that user friendly. Then type make and LDPC_main. After completion, run the MATLAB script plotresult.m.