Embedded Software IP & Technology Transfer in Power Electronics Applications

Why FPGAs are better than DSPs for Motor Control ?

That’s the main question I have been asked at last IEEE Energy Conversion & Congress Expo (ECCE2010) at Atlanta last month where Alizem had its booth demoing its COTS Motor Control IP for Pump and Fan Applications released last spring (see white paper and datasheet on Alizem’s website).

The answer to this question may be similar to asking if the latest Lady Gaga album is better on CD or as mp3 files running on an iPod. Technically, the IP performance (the music) is going the be the same on both platforms, the difference is the IP form factor and all its implications for the singer, the music platform manufacturer and the user. CDs need to be manufactured, delivered, may be scratched, stolen, etc. while mp3 files (whatever the format) are pure IP that can be easily dowloaded from anywhere at practically no cost, has higher margins, no degradation over time, etc. I already did that kind of exposé in by Motor Control IC vs Motor Control IP blog post.

On another perspective, if we strictly consider FPGA vs DSP chip for motor control (and in a general embedded system design perspective) it is obvious that DSP wins the battle. Why ? Because FPGAs are blank chips while DSP are chips having built-in processor & peripherals meaning that out-of-the box you can begin to develop your application software on a DSP while you cannot on an FPGA (you need to design the HW layer first then proceed to SW development). Hence FPGAs have one level of complexity higher than DSP and while this can become on one side an advantage (increased flexibility for new features bringing more value) it is on the other side a disadvantage because the same solution is going to cost more and take more time to develop (based on the same engineering methodology which to build everything in-house from scratch). We are not even talking about the fact that most motor control people are currently DSP/MCU users hence have not necessarily the skills for HW development.

Hence the strict FPGA approach doesn’t offer to motor control designer to have “more with less” compared to DSP. At that level, the only tangible advantage for FPGAs is to provide to motor control system designer a single design environment where the complete system – HW&SW – can be developped (as opposed to the conventional approach where each chip has its own tools that needs to be learnt and where lots of time is invested in component integration).

To overcome this problem, we need to consider “FPGA & IP” vs DSP. That is completely different. With an FPGA & IP approach, the HW development phase is reduced to its minimum which is to integrate IP components together (processor IP, motor control IP, communications IP, HMI IP, etc.). While this process can be a nightmare if not done correctly, it takes only a few minutes if done with the correct tools (e.g. using SOPC Builder in the case of Altera FPGAs – hence their slogan ‘from ideas to system in minutes’ – or using Xilinx’s Platform Studio).

Real gains over DSP approach are made by using system components around the processor that are application-specific (here’s a great blog article on application-specific intellectual property, ASIP): not only the designer has the freedom to select IP components that strictly fits its design (no more, no less), but his IP providers are continously working to improve them to specifically fit their needs (this goes beyond traditionnal processor peripherals) hence providing always more value over time (wheter functionnal features and/or reducing integration time).

For motor control systems, that means passing from one-fits-all/generic PWM blocks and transducer interfaces (to be configured by the system designer) to specific (pre-configured) motor control block that includes PWM, transducers interfaces and software drivers running on a FPGA embedded processor (read this white paper for more details). That processor can even be the same processor that you have always been using but integrated on an FPGA (I am refering here to Freescale’s ColdFire processor that’s available as IP for Altera FPGAs, there’s certainly more to come) !




Out-of-the-box experience








HW components (peripherals)




System components integration

Tedious (HW)

Easy (SW).

Easy (SW)

Requires Motor Control expert




Cost of HW/SW maintenance


Very High.


In this scheme, we can see a shift of the “secret” motor control sauce from the system designer to the (application-specific) IP provider. In reality, the real secret sauce is always in the hands of the motor control system designer which is to build the best machine for a targeted application. By leveraging motor control IP in his design, he can invest his time and ressources in doing a better sauce, quicker and cheaper.

All this happens by considering the FPGA chip as a system integration platform for third-party IP where gains (leading to lower TCO) come from ease of component integration (software integration) in a single design environment and leverage of outsourced domain expertise through IP procurement/reuse, especially in the case of very complex applications such as motor control.


  1. Przemek Klosowski says

    The article starts with a flawed analogy: MP3 files and CD music are not equivalent—while CD contains raw audio data (2 channels of 16-bit data sampled at 44 kHz, or 196 kBps), MP3 files are compressed by a ratio that’s typically around 10. As a result, a single 660MB music CD plays for nearly 60 minutes, while the same CD filled with MP3 data might contains 10 hours worth of sound. The discerning listeners will, however, be able to point to artifacts and distortion in the MP3-encoded music.

    Curiously, some elements of the corrected analogy apply to the DSP vs FPGA tradeoff: FPGA may be more flexible, but the DSP with a proven, fixed motor control algorithm may be more reliable and robust against real world deviations from the ideal design assumptions.

  2. Newer DSP’s and FPGA’s both share a common issue — soft errors


    Unless one is going to use something like an ACTEL RTAX, or anti-fuse architecture, or an older 3.3V core DSP, if the motor runs long enough or enough times it will go out in the weeds due to Single_Event_Upset. Thus you need a plan to fail and recover for both the DSP, and the FPGA approaches. This is often left out of canned software or IP– In the case of the DSP it means extra hardware, in the case of the FPGA it means extra logic.

Speak Your Mind