Ray Andraka - President and owner, Andraka Consulting Group Inc.
I’ve had an interest in electronics as far back as I can remember. I was building electronic kits in grade school, as well as discovering that the projects published in Radio Electronics and Popular Electronics often did not work without changes. I suppose that was where I acquired a lot of my debugging skills. By the time I got to high school I had a repair business fixing TVs and small appliances. I used the money from that and a paper route to build my first two computers while still in high school, The first was using the brand new Motorola 6800 and boards from Ohio Scientific, the second was a wire-wrapped Z-80 based system I designed from scratch. By then I knew I wanted to design digital electronics as a career. I went through Air Force ROTC to pay for school and then while on active duty got myself reassigned to a lab developing signal processing methods to automate TEMPEST testing, which exposed me to digital signal processing algorithm development. While I greatly enjoyed the algorithm development, I was really missing the digital hardware design. I left shortly after my commitment was up to take a job with Raytheon Missile Systems doing signal processing with digital hardware. There I worked mostly with radar signal processors, got introduced to FPGAs and soon started using FPGAs for signal processing. I quickly found that I had to tailor the algorithms to make them work within the tight confines of those early FPGAs. I was hooked. Later that year, I published my work on implementing a FIR filter in an FPGA, and began to make a name for myself in the industry. That set the seeds in my mind to become an independent expert on using FPGAs for DSP applications.
These days, my primary tool is the PC and the FPGA. Most systems I work on feed data to a processor, which I can capture and examine with Matlab. I do use the on-chip logic analyzer tools such as Xilinx’s Chipscope when there is enough room left on the chip to track down problems I can’t reproduce in simulation. This gives me far more visibility into the design than I could ever get with a physical analyzer. As a result, there is very little test equipment in my lab. The key though, is getting a good functional simulation before the design is in the FPGA so that I have confidence it will work right to begin with.
I use Matlab extensively for developing algorithms as well as for verification of the designs. For the digital design work, I mostly use VHDL and occasionally Verilog under the Aldec ActiveHDL design environment. I prefer the strong typing of VHDL over Verilog because it catches problems such as signed vs. unsigned early that could be very subtle and difficult to to find once in the hardware.
Well, not really a hard one, but nevertheless one that sticks out in my mind as the most interesting. Back in my Raytheon days we had a design that was misbehaving that I tracked down to a TTL octal register. When I looked at it, I could see one of the bits most of the time changing with the clock, but every once in a while that bit would instead output a perfect gated pulse that began and ended on the 12 MHz clock edge, but in between was very nice looking sine wave somewhere around 300 MHz. When shown the scope picture, my supervisor said “how did you do that? You wouldn’t believe how hard we have to work to do that on purpose for radar”. I found that the timing on one particular path was just right so that the input was changing right in the middle of the metastability window: a very graphic example of why that is a bad thing. A minor design change to shorten the timing path corrected the problem.
My technical library is mostly DSP texts. Some of the more frequently consulted books are Digital Signal Processing in Communications Systems by Frerking, Handbook of Real Time FFTs by Smith and Smith, Isreal Koren’s Computer Arithmetic Algorithms, Skolnik’s Radar Handbook, and Understanding Signal Processing Algorithms by Lyons. I’ve also got a shelf dedicated to flying and maintaining my airplane. I like science fiction for leisure reading , although I admittedly haven’t been doing much pleasure reading lately.
I go to the basics. I look at the application and what it is trying to do then look for all the different ways to solve it, many times looking at things such as approximations or algorithms I’ve learned in other disciplines. Often the most obvious solution is not the best for a hardware implementation. That’s a big part of the secret to obtaining the high performance I get using FPGAs in DSP applications.
There are several that have been quite enjoyable and rewarding. The most challenging so far is a beamforming antenna array processor, with 224 Xilinx Virtex4 FPGAs, each one connected to an antenna and sampling at 500 MS/sec. Each FPGA is a 10 channel receiver with independently set bandwidths, decimation, and tune frequency for each channel. The receiver outputs had to be phase shifted and summed with all the other receivers. One of my favorite designs has to be the floating point FFT design for an imaging application that had to perform Fourier Transforms up to 2048 points at a sustained sample rate of over a Giga-sample per second. That design presented an opportunity for some clever engineering to optimize the FFT algorithm for the Xilinx Virtex4 architecture, enough so that it would fit into one FPGA. I also have a fondness for an earlier FFT design that is currently in Low Earth Orbit in the space qualified version of the Virtex 1000. That design offered unique challenges in the form of upset detection and recovery and minimizing power consumption without degrading performance.
I try hard not to damage equipment. I did let the magic smoke out of a Xilinx 4025 on a customer’s board, not because of anything I did wrong in the lab, but because the design was too fast. It was a Gaussian noise generator that used the central limit theorem to obtain a random variable with a Gaussian distribution from the sum of a whole lot of uniform random generators implemented as linear feed back shift registers. The shift registers used the memory capability of the logic cells, so I had nearly every flip-flop and memory cell in the device changing state on every clock. The design was carefully designed for one layer of logic between flip-flops and carefully laid out to minimize the interconnect lengths so that I could run it run it on a 2x clock (so that it would fit in the device). As a result, it was capable of being clocked at close to the published maximum flip-flop toggle rate for the FPGA. That makes it dissipate a lot more power than the chip was designed to handle without a heat sink. Lets just say that the magic smoke doesn’t smell so good, and you can’t put it back into the chip once it is let out.
More projects than I probably should be at any one time. That’s the nature of this business though, the work seems to come in waves. Right now, I’m designing an FPGA based digital radar receiver targeted mainly at weather radar applications, although it is intentionally flexible enough for other radar applications as well. For example, I am looking at adapting that for a SAR radar application. I’m also designing the signal processing FPGAs for an industrial beamforming ultrasound inspection system, and am just finishing a 192 channel digital HF receiver for a signals intelligence(Sigint) application. All of these are rather exciting projects. In my spare time I am restoring a Karman Ghia convertible for my wife, tinkering with an antique Gravely tractor, and trying to keep up with our six children.
The biggest plus is the wide variety of projects I get to work on. This is experience that you just couldn’t get working at one place. The variety of disciplines from medical to radar to imaging to communications lets me bring together ideas from different communities that often let me solve problems in novel ways. Being able to pick and choose the work is a nice benefit too. The flip side of that of course is the work is always there so it is difficult to take time off. The often competing demands of multiple customers is like having several bosses that don’t talk to each other. There is also all the other non-technical stuff that goes with running a business. On balance though, I don’t look back on my decision to strike out on my own. It has been a fun ride and it is hard to believe I’ve been in business doing pretty much nothing but DSP in FPGAs since 1994.