Where to begin! First of all, I'd like to let everyone know that we have set up a web page containing some of the theses produced here at ITR. The address is
http://www.itr.unisa.edu.au/~steven/thesis/
The paper that Mark Reed and myself submitted to Electronics Letters was rejected. Mark has added some new information to the paper and it will now appear at the 1996 IEEE Int. Symp. on Personal, Indoor and Mobile Radio Commun., Taipei, Taiwan, in October. You can get a copy of this paper at
http://www.itr.unisa.edu.au/~steven/turbo/PIMRC96.ps.gz
The first step in getting one stage of turbo decoding working was to implement the deinterleaver. This was done and the address generation from the deinterleaver address RAM appeared OK (using the reverse address interleaver EPROMs). I then replaced the reverse EPROMs with delay EPROMs and this produced an all 1's output from the turbo decoder! I rechecked the wiring, but it looked OK. I then recompiled the MAPENC Xilinx chip (the turbo encoder) which somehow fixed the problem. The decoder then gave a 0 BER using PRBS data and no noise.
The next day I realised that the addresses to the deinterleaver would have to be delayed by a delay equal to a MAP decoder delay. The previous decoder tests did not detect this becuase the deinterleaver was currently acting as a pure delay. With a random interleaver, the decoder would not have worked. I then modified the TURBO Xilinx chip (which produces the addresses for the interleaver and deinterleaver RAMs). MAPENC was also modified so that it could select either the deinterleaver output or directly from a MAP decoder. Both these modifications were successfully implemented.
The next big test was to try a random interleaver. The decoder was setup in rate 1/3 mode using two 16 state rate half codes with g0 = 17 and g1 = 11 (in octal notation). The MAP block size was 4096 and the interleaver block size was 65536. With PRBS I was getting a BER of 0.454 (the BER test set was not synchronising to the decoder output). With all 1's input the BER was 2.6e-4 and all 0's gave a BER of 0.0. I soon found that the select line that initialises the deinterleaver address generator RAMs was not going low. With the previous changes to TURBO to fix the delay problem, the select line now remained high. Thus, the deinterleaver address RAMs were always being initialised. I did not detect this before because I was using the delay EPROMs. This meant that the data was being interleaved, but not deinterleaved! I fixed the logic in TURBO but I was still getting errors with no noise.
I examined the code I used to generate the random interleaver and discovered a bug. Think of a hat with a bunch of numbers that you select randomly. You select a random number, and the numbers above the number you picked shift one place down. You then randomly select from the remaining numbers. My bug was that I was shifting only the number above the random number, instead of all of them. Fixing this bug and reprogamming the EPROMs finally produced zero errors from the decoder.
I had to stop there with my tests since the due date for the paper I am presenting at the 1996 International Symposium on Information Theory and its Applications, Victoria, British Columbia, Canada, in September was rapidly approaching. The paper is called "Efficient implementation of continuous MAP decoders and a synchronisation technique for turbo decoders." You can get a copy of the paper from
http://www.itr.unisa.edu.au/~steven/turbo/ISITA96pap.ps.gz
After making some changes to the paper (as suggested by an internal reviewer) I printed the paper and the last page refused to print correctly, and this was 15 minutes before the courier was due to arrive at the end of the day! I madly tried to find the problem (the paper was printing before) but too late, the courier arrived and had to go. Ten minutes later, I found the problem! It was caused by changing the postscript file in the document, without having a proper link to the postscript file. Anyway, I rushed down to the airport in the rain (nearly having an accident on the way) and managed to get it to the couriers in time. Phew!
After all that was done, I finally could get around to testing the turbo decoder with noise (don't forget this is for one iteration only). My first test would be at an Eb/No = 1.0 dB. I got a BER of 0.293 with PRBS data. Ahhh! Will the errors never cease! This is much too high. All 0's gave a BER of 0.759 and all 1's gave a BER of 1.95e-3. Something very weird was going on. That night I did a long term test of the decoder with no noise and got 9 errors, giving a BER of 2.6e-9.
Not worrying about this residual error rate I concentrated on the noise problem. I checked the soft outputs from the first MAP decoder and discovered they were limiting at +127 (for a 1 input) and -128 (for a 0 input). This led me to look at the circuits which could be causing a limiting problem. I soon discovered a problem in a circuit used in MAP1 to subtract the log-likelihoods from each other. I also found that the extrinsic information being fed into the first MAP decoder was left floating (which is -1 in two's complement arithmetic). I fixed both of these problems, but I was still getting the same errors from the decoder.
The next day was spent carefully re-examining my Xilinx circuits. In order to fit in the Xilinx chips, each circuit had to be designed from scratch, so it was very easy to make mistakes. After a few hours of looking I detected a very subtle error in the circuit that subtracts the extrinsinc information from the MAP decoder log-likelihood ratio. This circuit was limiting when there was an under or overflow, and not limiting when it under or overflowed! Fixing this error produced a BER of 0.106 with PRBS, but with no noise!!! I now got a BER of 3.51e-4 with all 1's and 0.0 with all 0's input. The soft- outputs from the MAP decoder were now only limiting to -128, while the positive values were all over the place.
Setting up a systematic plan of attack on the problem, I discovered that the branch metric calculator chip MAP2 (where the previous subtractor circuit is also located) was for rate 1/4 convolutional codes, not for the rate 1/2 convolutional code I am currently using. Configuration control, where are you! Changing this back to rate 1/2, I got 0 BER for PRBS and no noise. Good sign. The log-likelihood values from the first MAP decoder were +/-80. Another good sign. The BER at 1.0 dB was 6.54e-2 which compared very well with Adrian Barbulesu's computer simulations of the same code. So folks, it looks like we have a working turbo decoder!!! Well, the first stage only. We'll have to see how later stages go. An overnight test with no noise gave a beautiful BER of 0.0. The BER curve I measured can be found at
http://www.itr.unisa.edu.au/~steven/turbo/codec/turbo34a.ps
The interleaver I used is an S = 31 random interleaver as defined in [1]. The computer simulation curve is from [2] with an interleaver size of 3660. As shown in [2], increasing the the interleaver size for one iteration gives very little performance improvement. So the difference between the two curves should not be great. As can be seen, the hardware curve is slightly worse below 2.5 dB. This is probably due to implementation loss within the hardware decoder.
Now that the turbo decoder is working, the next step is to implement the design on a printed circuit board (PCB). Each board will perform one iteration. I will be re-arranging the pins on the Xilinx chips to simplify the board layout, as well as making some simplifications from the original prototype. I will also have to build up two extra boards that will delay the interleaver and deinterleaver addresses to take into account the MAP decoder delay. Fortunately, I have some 4Kx4 SRAMs I can use to build up one of these boards, sufficient for 4 additional iterations. One 6U high rack will now implement a total of 18 iterations (1 encoder card, 2 address delay cards, and 18 turbo decoder cards).
The PCB will also have included delay RAM for the extrinsic information and received data. These circuits still have to be designed in detail. The next detailed report will be awhile as all these tasks are being accomplished. I also have to write a report on all this work. This will probably start out as a paper I will submit to a major journal (hopefully to the IEEE Journal on Selected Areas in Communications issue on turbo codes).