The FPGA meets the Radio Amateur

This month the technology issue of CQ Ham Radio magazine features an article about a single-chip repeater controller on an FPGA, by yours truly. For all my contacts out there who are amateurs, I have put up a site "www.ve6vh.org" if you want to download the files and work with it yourself, they are available free of charge. You will also need the web edition of Altera's (Intel) Quartus tools, which are also free. The hardware that I used is an inexpensive demo board available from Arrow Electronics for about $30.

The thrust of this article was not only the state machine but to illustrate that these devices have now matured to the point where even a small inexpensive one can hold fairly complex circuits, and that design automation has now come to the point where high level languages can be employed to design the logic, rather than the old-fashioned methodology of schematic entry. The price of the tools has also come down so that the 'crippled' versions that are freely available are sufficient for the average hobbyist to construct something quite useful.

The idea for the controller is not new, it actually came to me about 20 years ago when I built a discrete version using CMOS logic and an EPROM. The essence of the concept was to envision a repeater as a Moore-Mealy Finite State Automaton, and implement it using a 'nanoprocessor', which is a smaller version of processor with less instructions, in this case there were two, a jump to another state if something happened and a I/O instruction to turn something on or off. Timing was accomplished by stepping through a sequence of instructions, with each step representing about 50 ms. CW generation was also possible by turning a tone off and on, using a single instruction for a 'dit' and three for a 'dah'. The cadence sounded quite good.

The FSM was simple to implement in logic as it requires only a few latches and counters, but also requires a memory to hold the instructions. Modern day FPGA's have had blocks of memory available that can be connected together to form many different aspect ratios and depths, in this case there were sufficient blocks available on the device to make up an 8Kx8 memory, and the device also has on-chip flash memory that can automatically initialize it. To develop the 'code' for the FSM, I wrote a simulator/editor as a windows program, which can also be downloaded from the site.

The difference between this go around and the previous implementation is the level of integration that the FPGA can achieve. In the discrete version I also had a tone generator and audio mixing circuit, and a Mitel DTMF decoder. In the FPGA world, this is now done in the digital domain using a sine lookup table to generate the tones, and a Goertzel algorithm tone detector to replace the external device. The FPGA even has an A/D on board that can be used to digitize the audio, but, alas, no D/A! However, the evaluation platform that I used supplies this functionality on the board.

The complex part of this project that is not easily accomplished by automation was the DTMF decoder. There is a plethora of information available on the web about how the algorithm works, even with some code examples using floating point, but the steps to get it onto an FPGA are still somewhat of a secret sauce. Given that what you have in front of you is a 'blank canvas' of logic, it is possible to implement the algorithm on the FPGA using floating point arithmetic, there are library functions available that will create multipliers, adders and the like, but the operation time may be not be that predictable. A better approach is to used fixed point, which requires a conversion process, which, even in this day and age, is still somewhat manual and labour intensive. The most popular tool for mathematical modelling, Matlab, does have an add-on to turn it code into an FPGA-freindly implementation, but this is by no means optimum and, the way some code is written it is hard enough for a high end processor to achieve any kind of real time performance, let alone have it automatically translated. Not to mention that it has a hefty price tag that is beyond the average hobbyist. However, the good news is that once a fixed point version can be made it is a relatively straightforward step to migrate to the FPGA. This algorithm was modeled using the C language, first in floating, then fixed point, and finally in verilog. By dumping all the intermediate values in the model and using Modelsim to simulate the verilog, it was possible to do a step-by-step verification of the implementation, however a few trees had to meet their maker to dump all the data, so this is where a dual-monitor computer is definitely a better development environment, instead of my usual laptop.

Putting it all together and migrating to the hardware was not a difficult step. Once functionally simulated and if there are no errors during synthesis, most of the time it will run on the hardware. If is does not, this is usually because of incorrect assumptions that were made during the simulation phase. To make this as accurate as possible the manufacturer supplies models of the chip functions, including the A/D converter, but simulation of even a couple of milliseconds can take several hours. In this case, just to simulate the DTMF detection took over 12 hours on a core I3 processor, which would have been a lot faster in real time. For real-time debugging manufacturer also supplies a capture and display module that can be included with the design, but it does eat up a lot of logic and on chip memory, which can be significant on the smaller parts. It turned out that in this case there was just enough left to squeeze it in, however the utilization jumped from less that 30% with just the design to well over 85% with it included.

In summary, the FPGA and its tools have evolved to the point where the parts and tools are inexpensive enough that the hobbyist can produce some meaningful designs and unleash the power of this technology. So why is it not plurific? The answer lies in the thought processes that are required to be successful. We are so ingrained to think in the Von Neumann style of computing where instructions are always executed sequentially, that we cannot take the step back and realize, 'what if all this executed at the same time?'. Therein lies the skill, and unfortunately, the barrier to overcome.