Real-time Embedded Linux and POSIX RTOSs For Microcontrollers (MCUs)

Tuesday, May 29, 2007

All Those Pesky DSP Functions

As DSP becomes mainstream and we incorporate it into all systems, we are left with a dillema: "how can we make this functionality simple enough for all to use effectively?" In short, we can't.

Signal processing is difficult by its nature. It can be done in fixed point, floating point or double precision floating point. It involves many different algorithms. Often at the front end, processing is data independent, while at the back end it is data dependent. Different array sizes are passed between modules, concepts are abstract and require deep mathematical understanding, and time constraints on processing make all this more difficult.

One might say: "Oh, well we'll use a graphical tool and it will solve all our problems" but this is not the case even though it might help in special cases where processing is always regular and data dependent processing is not done. As soon as branching is involved and interrupt processing is required, the need for better tools becomes apparent. In general, if the problem is more limited then this can work, but if it is complex and demanding it tends to be less than optimal.

Or does it? You tell me. How would you recommend people solve these problems?

Friday, May 25, 2007

DSP and FPGA Implementations

Hi All;

How many of you have looked at the rapidly dropping cost of fpgas and wondered how this is going to change the world of signal processing? I'd like to know too. I have some ideas summarized as follows:

  • FPGAs offer competitive advantages in hardware implementations of signal processing algorithms with the cost and difficulty of implementation being a barrier
  • DSPs offer competitive advantages where the algorithms are experimental and subject to rapid change or the ultimate idea is to push the processor to the limit by adding as many features as possible for the same hardware price.
  • DSPs offer integrated A/D and D/A support - something not included in FPGAs to date.
  • Serial D/A and A/D components can offer greater flexibility to designers of FPGAs.
  • Drivers for PWM are generally integrated into DSP's including dead band timing - lots of work might go into recreation of the wheel in the FPGA world.
  • FPGA prices relative to DSP prices are falling - this means that the cross over point from DSP to FPGA for development is changing - but how?
FPGA implementations are now cheaper but development is more expensive. And it is still not entirely clear what algorithms are possible with an FPGA compared to a DSP. For example, neural nets are computed on DSPs without difficulty even if it is time consuming. In comparison, this same algorithm would be extremly difficult to run in an FPGA if it was even possible.

How do we decide how to partition these problems? What thoughts to others have on this?