The last time I sent out a report, the schematics for the printed circuit board (pcb) version of our turbo/MAP decoder had just been completed. In the last four months, the schematics had to be captured by the local company making the pcb's (Electrocad in Technology Park), checked by myself, layed out on a four layer board, checked by myself, and then manufactured.
While this was going on I realised that the interleaver and deinterleaver addresses had to be delayed for each iteration. Thus, I had to design a new board to perform this task. Basically, I use 8Kx8 SRAMs to perform each address delay. Fortunately, all the parts to do this were available in ITR. Two boards will have to be built up for this task (each board produces four delayed addresses). I built up the first board and wired up the first delay. A test of the addresses that go to the SRAMs found one of the pins shorted to +5V, which was easy to fix.
Finally, the pcb's arrived, but I could not do anything to them for a while as I was busy with other things. After the pcb's had been sent off to manufacture I realised that I needed to make a modification. The mod was to allow the last deinterleaver SRAM to be used for deinterleaving the hard decision output of the final MAP decoder. This involved making three small changes to the pcb. I first tested the mod on the prototype decoder to make sure it would work.
I first built up the first MAP decoder. Needless to say, I was a bit nervous as to whether it would work or not. All the pinouts for the Xilinx chips had changed. Well, I downloaded the design and got all zero's out with PRBS in! Since I was worried about changing all the pinouts, I rechecked to make sure that I had the right bit files for each programmable gate array (PGA). I soon found that MAP4 was using the prototype pinout. In making the changes for allowing the deinterleaver to be used as the ouput, I had forgotten to update the pin constraint file. Recompiling MAP4 with the correct pinout gave zero errors with PRBS in and no noise.
The next step was to test the MAP decoder with noise. In rate 1/3 mode and an Eb/No of 1.0 dB the expected BER is 1.30e-1 which was very close to what I measured (1.31e-1). This output is equivalent to 1/2 a turbo iteration.
Next, I built up the second MAP decoder with the interleaver between them. This time the decoder worked first time, but with noise the BER was slightly higher than the expected 6.54e-2. I soon found the problem to be due to overclocking the noise generator (which is limited to 205 ksym/s). Reducing the clock rate fixed the problem and I was getting the expected BER.
Before going on test 1.5 iterations, I had to add a little multiplexer circuit, to select between the 18 possible decoder boards. Even this circuit gave me problems. I had to change some pullups from 10K to 1K and to my embarassment I wired up the ground pin of one the chips to +5V! The lesson here is to always check your supply pins before powering up. Fortunately, no damage was done and the corrections were easy to make.
I soldered up annother MAP decoder and tested 1.5 iterations with no noise. This would test the huge delay circuit for delaying the received data for the first time. I got the very strange error rate of 0.125! Since the delay circuit was new I checked the addresses to each of the delay SRAMs (I only had the most significant bit wired up). They were fine. I then went and rechecked the design and found that the addresses were changing on the wrong edge of SCLK. The hardware confirmed this. Recompiling MAP4 with the corrections produced zero errors. Things were looking up!
I soldered in the rest of the delay SRAMs, tested with noise and got a BER of 0.116 :-(. Oh boy! I went back to my schematics and soon realised that I had put a jumper in the wrong place. Moving the jumper produced a BER of 2.59e-2 which was indicating that the decoder was working!!!
I spent yesterday and today producing the kit for the rest of the five pcb's. They are now at Electrocad being wave soldered. Once completed I will have seven iterations. I'd like to buy more but my pockets are bare. Hopefully, ITR will be able to fund the rest of the codec to the full 18 iterations.
You can have a look at the pcb in
http://www.itr.unisa.edu.au/~steven/turbo/codec/
I also have another report from a French work experience student at
F. Malardel, "Simulation and optimisation of the turbo decoding algorithm," EFREI Final Year Report, Uni. of South Australia, Nov. 1996. fm.ps.gz (646k)
For those of you who may not be aware, ENST de Bretagne in France (home of Claude Berrou) is organising an International Symposium on Turbo Codes to be held in September 1997. You can get more information from
http://www-turbo.enst-bretagne.fr/
My next report will hopefully have some neat curves of the decoder's performance with seven iterations.