Our turbo codes web page address has changed. It is now
http://www.itr.unisa.edu.au/~steven/turbo/
Please update your links.
Its been awhile since my last report, but I have been roped in to support two other projects (a turbo coding study for Inmarsat and a sequential decoder for Step Electronics in Victoria). The additions required to get the two MAP decoders working together has also been quite substantial.
The first change invloved adding the interleaver circuit to the encoder. I use two 64Kx8 EPROMs to store the interleaver addresses to form a 64K interleaver. I use the technique of writing into one 64Kx1 SRAM and simultaneously reading the interleaved data from another 64Kx1 SRAM. I then swap the addresses to the SRAMs (using four 20 pin programmable logic chips) and perform the opposite operation (read the data I've just written and write data from where I've just read).
Testing of the interleaver involved programming the EPROMs to simply reverse the addresses in time. I then checked the addresses to the SRAMs and they were performing as predicted.
The next step was much more substantial. This was the design of the interleaver between the two MAP decoders. This interleaver uses only two 64Kx4 SRAMs with separate I/O. What I do is write the first 8 bit MAP decoded data in each second half of a DCLK cycle. I do this for 64K DCLK cycles. I then change the address to read the interleaved data in each first half of a DCLK cycle, writing the new data in each second half of DCLK. This occurs for 64K DCLK cycles. For the next 64K DCLK cycles, I have to rearrange the addresses since the order of the data is already interleaved!
The above technique simplifies the interleaver (requiring only two 64Kx4 SRAMs instead of four 64Kx4 SRAMs as the encoder interleaving technique requires). However, the address generation is more complicated. The address has to be stored in SRAM and then interleaved to form the next set of addresses. Since the addresses are in SRAM, they have to be first initialised on startup. Also, if an an address in SRAM gets corrupted, it will propagate.
I took the challenge of using this more complicated technique since I can save four 64Kx4 SRAMs on each decoder board (2 SRAMs for the interleaver and 2 SRAMs for the interleaver) which is repeated 20 times. The address generator circuit is only implemented once, on the decoder board. Since I don't have an unlimited budget and I want to save wherever I reasonably can, I implemented this design.
On first powering up the design I noticed a liquid forming on top of the XC3020 I was using to initialise the address generator and form the addresses. I touched the chip and it was very hot. I immediately switched the power off and examined my wiring. Oh Oh! I had swapped two of the power supply pins on the chip! Needless to say, I was quite embarrased and quietly buried the chip in my rubbish bin. Since we have plenty of old XC3020's available, I got another one and fixed the wiring.
Examining the addresses I discovered that bit 12 was always zero. I got the voltmeter out and measured zero Ohms between ground and the pin. A ground wire passing close to the pin was causing a short. I took out the old ground wire and put a new one in, fixing the problem. The next problem was that the 16 bit address from the four 64Kx4 SRAMs (to the interleaver SRAMs) was not being interleaved, it was always reading 0 to 65535. This was caused by the SEL line to the initialising multiplexer being inverted. At startup, we load the SRAMs with addresses 0 to 65535, and then store the interleaved addresses into the SRAM (using the read followed by write technique). However, with SEL inverted, we loaded up garbage on startup and stored 0 to 65535 forever more!
With this problem fixed the correct interleaving was occuring (using the test EPROMs from the encoder interleaver). However, the last address was being corrupted! This was caused by the SEL line being high for less than one clock cycle, resulting in garbage being stored for the last clock cycle on startup. I modified my startup logic and voila, the address generator was working.
The last step involved adding the interleaver SRAMs to the decoder board. I also slightly modified MAP2 and MAP3 so that DCLK would now only go to MAP3 (the control logic Xilinx chip) and that DEN (a pulse synchronised to the 10 MHz internal clock and the rising edge of DCLK) would go from MAP3 to MAP2 (the branch metric calculator Xilinx chip). I also extensively modified MAP4 (the miscellenous logic that won't fit in MAP1, MAP2, and MAP3 Xilinx chip) so as to replace a 74HC74 chip I was using and generate the control signals for the interleaver. These modifications were successfully tested with rate 1/2 16 state MAP and rate 1/4 512 state MAP.
Yesterday, I tested the two MAP decoders together. The interleaver EPROMs were programmed only for a delay (i.e., no interleaving). Alas, the rate 1/3 16 state parallel concatenated decoder did not work. I was getting a BER of 1.22e-4 from the the first MAP decoder and a BER above 0.1 from the second MAP decoder using PRBS data. The first MAP decoder gave no errors with all zero's or all ones.
The PRBS error rate indicated one bit error every 8196 bits, twice the size of my MAP decoder block size. I tried recompiling MAPENC but no luck. I went back and re-examined all my timing diagrams and couldn't figure what was wrong. Getting close to 6:00 pm I decided to stop working on the problem and have a good night's rest.
This morning I thought about the problem some more and decided the problem must be in MAPENC (the encoder Xilinx chip) since MAP1 to MAP4 were identical to the rate 1/2 MAP decoder design which worked perfectly. Going through the schematic circuit by circuit, NAND gate by NAND gate, I discovered that the comparator signal from the divide by three phase locked loop counter was using the lsb instead of the msb! The lsb was counting 010 and the msb was counting 100 which caused the output of the encoder to be out of phase.
Fixing this problem (and waiting for the PRBS receiver to be freed from the sequential decoder project) the first MAP decoder now worked perfectly! Removing a jumper (not the wooly kind) from the decoder board for the second decoder output resulted in a BER = 1.21e-4 for PRBS, zero errors for all zero's and BER = 2.44e-4 for all one's. Obviously, one bit was being forced to zero. I suspected that the decoder output was being delayed by one extra clock cycle. This could result in one of the tail bits being selected by the PRBS receiver.
I checked MAP4 and sure enough, I had put in a delay which I shouldn't have done. Removing this delay fixed the problem and with great relief I finally managed to get zero errors in rate 1/3 turbo mode. I can't currently test the decoder with interleaving since I still have to construct the deinterleaver address generator and deinterleaver SRAMs. However, I have proved that the address generator technique works, giving zero errors after 2 hours and 250 kbit/s operation.
Our old 33 MHz 486 PC has also been upgraded to a 133 MHz 586 with an improved parallel port. This should hopefully speed up the noise generator. My next report should include a simulation curve of one iteration of a rate 1/3 16 state turbo decoder.
Steven S. Pietrobon, Satellite Communications Research Centre
University of South Australia, The Levels SA 5095, Australia.
steven@spri.levels.unisa.edu.au
http://www.itr.unisa.edu.au/~steven/