December 7: A day most people know as Pearl Harbour day. It is also the day that I got my Ph.D. five years ago. In 1995 it is the day that Galileo hopefully goes into orbit around Juipter and the day that I got zero errors from my MAP decoder!!!!
Yes folks, with much effort I've extracted the bugs from my MAP decoder and it is now giving zero errors with no noise using a PRBS sequence. I've detailed the 10 separate bugs I found below. The MAP decoder is currently configured with a rate 1/4 512 state systematic convolutional code of block length N = 128. A 9 bit tail reduces the number of information bits per block to 119 bits. The maximum data rate is (1e7/(512+13))*119/128 = 17.7 kbit/s. The codec can be programmed with almost any systematic code (with g_0 = g_m = 1) using DIP switches.
The next steps are to try completely remedy the DCLK problem (see bug 7), reprogram the codec to a rate 1/2 16 state code with N = 4096, and test the codec with noise. My turbo code web page has slightly simplified. It is now
http://www.itr.unisa.edu.au/~steven/turbo/
My old address should still work though.
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/
Bugs found in MAP decoder.
(1) With all 1's input, the output BER was very close to 1.0. Inverted decoder output on MAPENC Xilinx chip output to obtain BER = 3.43e-2. The PRBS BER = 5.13e-2.
(2) The START signal from MAPENC to the decoder was grounded (from previous tests of the decoder). Removed ground. Errors still being produced.
(3) The START signal was resetting the decoder counter every N = 128 clock cycles, instead of every 2N clock cycles. Changed MAPENC to give correct signal. The BER from the decoder became worse!
(4) The state metrics in the MAP1 Xilinx chip were not being initialised correctly. Changed MAP1 to correct circuit. The BER from the decoder became even worser!!! All 1's BER = 7.41e-2 and PRBS BER = 1.04e-1.
(5) Found that old DCLK generating circuit was still connected on decoder board which was interfering with the DCLK signal from the encoder board. Removed old circuit. All 1's BER = 7.47e-2 and PRBS BER = 8.40e-2.
(7) DCLK was occasionally double clocking counter in MAP3 Xilinx chip. Suspect counter was being clocked on falling edge instead of only on rising edge. Have seen this same problem on my first Viterbi decoder, even though the clock speed is very low (15 kHz). Removed unused DCLK line from MAP3 to MAP4 Xilinx chip, put in extra decoupling capacitors, connected the three separate power planes on speedwire board more thouroughly, and connected together the power and ground pins on the Xilinx chips. This greatly reduced the frequency of double clocking. The problem also seems to depend on the frequency used. This problem is not totally eliminated. Will try and completely fix this problem once the other bugs have been fixed.
(8) Found major design bug. The state metric (SM) delay was one DCLK cycle short. Instead of the SMs being written into the SM delay RAM as they were computed, they should have been written after having being read from the dual- port RAM which temporarily stores the SMs. This greatly simplifies the address generation for the state metric delay RAM, as the SMs are written and read in the same order. The last SMs were also not being initialised (with SM 0 being set to 0 and the other SMs being set to 255). This is to allow the tail metrics to be calculated correctly. To correct for these errors, this required many changes to MAP1 and MAP3 and some wiring changes. I had to add two pins to MAP3. The designs for MAP1 and MAP3 actually became simpler. All 1's BER = 0.0 (although at low clock frequencies, there were some occasional errors which I believe due to the DCLK double clocking problem). PRBS BER = 7.62e-3. All 0's BER = 8.40e-3. The third bit was in error (along with a bit right at the end which is in the tail and thus doesn't get counted).
(9) Found that the least significant bit read address pin on the reverse SM dual-port RAM was stuck high. This was one of the address lines that had changed in fixing bug 8. I isolated the pin (P47) on MAP3 that was generating the signal. The signal from MAP3 was still high, although an unused pin (P48) next to it was slightly modulated (at +5V +/- 0.25 V). I confirmed that P47 was isolated by measuring the resistance to the other pins on the package (about 2-5 MOhm as expected) and measuring the resistance to power and ground with MAP3 removed (any shorts would have seen a measurable resistance which I didn't see). I tried another Xilinx chip and had the same problem. The strange thing is that the signal from P47 is used elsewhere in MAP3 and could be seen to work. In MAP4 P47 produced a low signal as expected. Anyway, I fixed the problem by moving the signal to P48. All 1's BER = 0.0, all 0's BER = 8.4e-3 and PRBS BER = 6.4e-3 (a slight improvement).
(10) I had forgotten to change the eccumulator control lines since the path metrics are now being calculated earlier (from fixing bug 8). The circuit in MAP1 was corrected and one wiring change made. All 1's BER = 0.0 and PRBS BER = 0.0!