Altera's Case for DSP in Industrial Control

dictate inactivate desperately contemporary retaliated foods untenable fong facilitators resultstable rabbit

pilot nominal resist share carp iiiakanshame luiz marchais destroyed manas weis

I would have to say that DSPs are probably not appropriate for most industrial apps. I base this statement on my experience that the typical industrial control engineer is severely mentally challenged (compared to the engineers doing SIGINT, Radar, Sonar, signal processing). About 95% of the apps you see in factory automation are simple sequencers, and the engineers in that segment use embedded commodity trashy PC technology (or some terribly antiquated PLC), a perfect match for their skill sets. Giving an FPGA with multiple DSP cores to an industrial engineer is like giving a hand grenade to a monkey. Given a little time, both will blow themselves up.

LOL. Did you pay for that FPGA ad? (if you want your kid to work in the FPGA industry, name him "Dave")? Just like driving a 4 ton SUV for your daily stop an go commute, YES, you can use a Stratix or Virtex to do DSP for industrial. You can also have your competitor stomp your product into the ground with a lower power, less costly solution. A Stratix or Virtex is "3 tons" of silicon when an energy-sipping Prius means no fan air filters for maintenance chimps to change on the factory floor. Industrial means non-stop, don't touch. That "Prius" analogy for FPGAs is the Cyclone and Spartan. Since most industrial processes run in the tens of hertz, arguably a few hundred or small thousands o'Hertz (St Paddy's day is coming up) is possible, the newer gen of cheap FPGA chips is MISSION APPROPRIATE. In fact, a good friend of mine has implement a full 6.1 acoustic beam steering system, chock full of parallel, multichannel, DSP - all in a 5k Cyclone III for less than $5. Then again, the paradigm has changed in microcontrollers to where a $1 dsPIC can now do DSP, albeit not a bazillion channels at 44kHz apiece. The argument for serial processing is also a bit lame - filters by their very nature are indeed serial PER CHANNEL and most industrial channel counts are less than a handful and LOW BANDWIDTH information. It's really the channel*bandwidth product that defines the transition from uC to DSP to FPGA, but sensible hard metrics or rules of thumb don't make for much of an FPGA market compared to exotic, and usually inappropriate, parallelism. You can do it, yes. For low pass filtering sensor signals, band limiting or bandpassing, or controlling a motor, a PIC, AVR, Cyclone, or Spartan is just fine. Put the uC's on a CAN or other bus, and now you have distributed your failure points. A basestation, on the other hand.....

And a coda. Multiple cores is *not* a solution to the CPU/DSP problem. It is merely another way to do parallel operations. And it is almost always not the best one. Multicore is driven by the desire of those owing CPU/DSP IP to extend the life of their products. But it breaks the mold. Machines and humans cannot take an arbitrary C program and break it into two pieces to run in parallel on two cores, let alone 8 or 16. To do parallel operations, you have to do parallel thinking. You work in terms of memory bandwidths (the staple of architecture), pipe-lining, data flow, split/merge, etc. These have nothing to do with CPUs and instruction sets, in general. They are big blocks that do well if they do lots of internal operations before passing data along. What is needed are small blocks (flip-flops, multipliers, buffer memories) that do one operation on the data and and passes it on. FPGAs work well here because they are a huge collection of small logic elements (flip-flops, memories, multipliers) that you can build up into your system. If you need to solve a parallel problem, it is often better to start with an FPGA rather than try to get multiple cores to sing together. But it depends on the problem.

A CPU/DSP uses serial (program counter driven ) logic to solve math problems. The serial approach uses the least hardware to get the job done. Because a small amount of hardware is involved, it can be race-tuned to run as fast as it can. But it is still serial. Its maximum performance is fixed by its clock rate. A DSP in its basic form a is a CPU with hardware multiply-accumulator. Still does things in serial, but with a little more parallelism (the MAC) to turbo-charge it. Still minimal hardware with fixed maximum performance. Complex DSPs just set the performance point higher at higher cost. The CPU/DSP is a point solution. It is not scalable. We have no single CPUs in volume production that can run at 4 GHZ since Moore's Law died in 2004. An FPGA is not serial by nature; it is parallel. That is the whole point: lots gates doing thins independently and in parallel. But your problem has to be capable of implementation on parallel hardware, and you have to design for parallel activities. Given these requirements, an FPGA *is* scalable. If the one you have is not fast enough, it is just not big enough. You can usually buy an interchangeable, upgrade device with twice the amount of logic in all dimensions. Now you have twice as many things going in parallel for the same clock rate and twice the speed. And you can keep doing it. As you continue on this roadway, you quickly outrun the conventional DSP of almost any flavor, both in raw performance and usually in performance/$. Run the numbers on your own spreadsheet, assuming your algorithms are a good fit for parallel operation. In my application, I found that a cheap FPGA would outrun a comparably cheap DSP by at least a 4:1 margin. And this was a few years ago.