Why use FPGAs for data acquisition systems?

Why would you want to purchase an ADC (analogue to digital convertor) or DAC (digital to analogue convertor) for use with an FPGA module?  This is an important question.  The choice of FPGA (Field Programmable Gate Array chip) over say a conventional CPU or DSP, or even a GPU (Graphics Processing Unit) means for many people a leap into the unknown.  We move away from the familiar world of programming in languages such as C/C++ or .NET (C#, VB etc) and have to deal with more esoteric means such as VHDL or Verilog.  There are of course new tools to simplify the programming of FPGAs but they have their limitations and are often prohibitively expensive.

Two FPGA cards and two FMC I/O cards

So, I return to my question, why move to FPGAs?  No one decides out of the blue one day that they want an FPGA based system.  What we want is a means to process our data and in the context of this article we’re assuming real world data being received from sensors and/or being generated and transmitted (ADCs and DACs respectively).  Say we want to acquire a number of channels of data, for example radio signals from a variety of positions.  We can connect our antennas to ADCs.  Then what?  We need to do something with the digitized data.  We could store this to disk for off line analysis.  We could monitor the data for specific signatures and alert a user.  In either case once we go above a certain sampling frequency and number of channels the sheer quantity of data is likely to prove a handful.  We’re going to have issues with:

·         Transfer speed

·         Storage speed

·         Storage space

·         Processing

Transfer speed would be the bandwidth from the ADC over the data link to a disk, CPU or network card.  Storage speed would be the speed at which we can write data to a hard disk or solid state disk.  Storage space refers to the fact that disk space is finite and keeping the quantity of data for off-line processing manageable.  Processing here refers to real-time processing – this should keep up with the rate of data acquisition.

A single modern ADC module can easily produce in excess of 5GBytes/second.  The fastest links typically found in a computer can handle around 6GBytes/second sustained.  But that is only the beginning of our problems.  Once the data has arrived at the CPU what do we do with it?  The fact is that such a data stream will easily saturate the capabilities of even a powerful CPU especially if we must re-order the data and do complex digital signal processing.

Tools such as NVIDIA’s CUDA have allowed simpler programming of GPUs for non-graphics purposes (read general purpose processing) and these add in cards are often quite suited to the purpose of signal processing.  But even here we are taxing our system considerably, relying on predictable data transfers, introducing latency with every step and on top of it all we should expect relatively high power consumption.  A GPU can easily require in excess of 200W and a high end CPU can require more than 125W.  So our reasonably low cost, easy to program system is going to be relatively large, need considerable cooling and will consume a fair bit of power.  And what happens if we have many more sensors and therefore more ADCs?

It is when we hit these issues that we start looking at alternatives and we learn about FPGAs.  We learn that these little marvels can outperform any CPU and even GPU for the typical signal processing tasks and at a fraction of the power consumption.  We then figure that we do not want a discrete ADC card with its own application programming interface (API) that would still need to transfer data to the FPGA via the host CPU.  We realize that the ADC should interface directly with the FPGA module.  We then read about FMC – FPGA Mezzanine Card and the many very high performance ADCs (faster, higher resolution can be more insight to your data) available in this form factor and the many FPGA modules supporting these daughter cards.  Just mount the ADC directly on the FPGA module, what could be easier?  Then we remember that we’ve left the world of our favourite programming languages and we need to learn a whole new approach.  It’s a step into the unknown for many, a steep learning curve, complex and expensive tools, but the performance benefits are clear as day and the allure of greater depth of analysis is irresistible and game changing.

Now the blurb – Hybrid DSP has the experience to advise on and supply some of the highest performance ADCs, DACs, video and other input/output cards on the market.  All these I/O products are available exclusively as FPGA daughter cards.  You may choose to configure the FPGA card as a simple glue-logic interface to a host computer, or you may elect to have the FPGA card perform the complete processing chain, or you may choose any number of steps in between.  A hybrid or heterogeneous system may use the FPGA card for re-organizing the data, some simple pre-processing that will not tax your FPGA skills too highly nor require too large and expensive an FPGA.  You then may do the complex signal processing (e.g. FFTs) on a GPU card.

As I said no one wakes up one day and decides to go with FPGA and FPGA I/O daughter cards.  We just end up here.  And that’s where Hybrid DSP comes in with our fairly unique approach to advising on and putting together systems that meet requirements while balancing cost, development time, skills, power consumption and size.