Before going to the 16 state decoder design, the first thing I did was to move the wiring from the MAP4 Xilinx chip to MAP3. Previous design changes had allowed the possibility of some pins on MAP3 to be freed. This put all the control logic into MAP3, leaving MAP4 practically empty. Thus, my MAP decoder needs only 3 Xilinx chips, instead of the previous 4 chips.
The next step was to make the decoder more reliable. The 512 state MAP decoder would only work at certain frequencies. In previous tests I noticed that the DCLK counter in MAP3 would sometimes skip or repeat a count for some frequencies. MAP3 has the slow speed DCLK connected to ACLK and the high speed 10 MHz CLK connected to GCLK. I suspected that the use of ACLK was causing a problem (since it is not a true global clock) so I modified the DCLK counter so that it would now be clocked by CLK. This change resulted in the decoder now reliably working from 17.3 to 19.0 kHz (the maximum possible data rate).
DCLK has a mark to space ratio of 3:1. Thus when operating below 17.3 kHz (3/4 of 19.0 kHz), all the decoder operations occur when DCLK is high. For some reason, this would cause the decoder to not work. After messing around with putting series resistors on all the DCLK lines, I traced the problem to the startup signal in MAP3. This signal uses an asynchronous circuit which I suspected was causing the problem. I have used this exact same circuit in two previous decoders I built with discrete logic. I redesigned this circuit to be fully synchronous and voila, zero errors from 1 kHz to 19 kHz (the lower limit is due to the PRBS test receiver). However, when I exceeded 19 kHz, the decoder would go into a bad state and not work when I dropped the data rate below 19 kHz. A couple more changes in the startup logic and the decoder was working perfectly.
I could finally modify my Xilinx schematics to implement a rate 1/2 16 state code. The block length is 4096 and I set the DIP switches to the g0/g1 = 37/21 (g0 is the divisor polynomial) code. Downloading the code I got a BER of 1.16e-2 with no noise. Groan! I checked the encoder and that was fine. I then discovered that I had gotten my read/write address lines into the dual-port RAMs wrong in the decoder. I modified the MAP3 schematics and made a small wiring change to the decoder so that it could with a 4 state code. The changes worked and I got zero errors with no noise.
The decoder works up to 340 kbit/s as expected. However, testing my noise generator with an alternating sequence of 0's and 1's, the PC I used pooped out at only 34 kHz. This would imply a data rate of only 17 kbit/s. This also made suspect my previous rate 1/4 noise tests, since the data rate would be 8.5 kHz, much lower than the actual test speed of about 17 kHz.
I soon discovered though that holly (the name of the PC) was much slower than before when I tried to generate a noise sequence. The day before, holly had her RAM upgraded from 8 MB to 20 MB. The 20 MB comes from four 1 MB sims, and four 4 MB sims. Taking out the 1 MB sims (leaving 16 MB of RAM) resulted in holly returning to her former speed. Obviously, holly likes her RAM in one flavour only!
The maximum noise symbol rate is now 168 kHz, giving an 84 kHz maximum data rate. In the tests though, I ran at 80 kHz to be on the safe side. You can obtain a plot a these results from
http://www.itr.unisa.edu.au/~steven/turbo/codec/map24.ps
This time, I have plotted a software MAP decoder courtesy of Jean Yves Coulead. The hardware MAP decoder closely follows the computer simulation at high BER, loosing 0.08 dB at low BER. The sub-MAP decoder looses about 0.5 dB at high BER and closely follows the MAP decoder at low BER.
The next step is to implement the second MAP decoder onto the decoder board. Only one extra XC3190A, two dual-port RAMS, and four 64Kx4 RAMs are required. The second MAP decoder uses the same control logic as the first MAP decoder (the MAP3 chip). The branch metrics are also calculated in the same MAP2 chip as the first MAP decoder.
Since the second MAP decoder will terminate in an unknown state, I will have to modify MAP1. The technique I use will depend if I interleave only the information bits (of length N-m) or all the bits (information plus tail) from the first encoder. Adrian Barbulescu's work indicates that it is better to only interleave the info. bits. However, this was for the special case of a small interleaver size, helical interleaving, and Adrian's technique of terminating both info. sequences into the same state (so that only one tail is required). If anyone can provide further insight on which technique is better I would greatly appreciate it.
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/