FPGA Technology and Software IP in Power Electronics Applications

Impacts of an embedded software bug in power electronics applications

We all know software is a difficult skill to master and there are tremendous differences in developping software for:

  • PC/desktop applications
  • mobile/tablet applications
  • … and real-time embedded control applications such as power electronics applications

While in all cases a software bug may lead to important financial and human losses (directly or indirectly), the case of embedded software for power electronics application is special since it is meant to directly control the flow of energy from a source (battery, solar, etc.) to a load (electric motor, power network, etc.), not a flow of informations/signals/data is in a typical software application.

Impact #1: System component destruction

It means that a software bug may lead in the bad management of the flow of energy which can itself cause the destruction of components such as power stage (“shoot-through” faults), electric motor (“overcurrent” faults) or electric motor load (pump damage caused by cavitation for example).

impact of a bug power electronics software

Of course, proper installation of electrical equipement protection (i.e. fuses) can prevent most of the damage that may happen on the system components in case of a bug (overcurrent), but not all of them. For example, noise in a transducer may lead to torque ripple which may lead over time into electric motor bearing problems. This is the whole idea of electric motor “condition monitoring”, i.e. tracking over time the state of healt of the motor in order to : (1) detect faults (is there a fault, what component ?) and (2) diagnose faults (what is the cause of the fault, how severe the fault is). Those further interested in the subject may read this article.

Impact #2: Unique embedded motor control software development process

Hence, the development of motor control software needs not only software programming and digital signal processing skills, but it also needs deep “domain knowledge” experience related to power electronics, electric motors, transducers and the type of application where the software is going to run (in a home appliance or in an electric vehicle ?). More on this in a previous blog article. This point is not unique to power electronics software, the same could be same for embedded computer vision software (i.e. smart camera).

However, since motor control software bug may lead to component destruction, this has an impact on how the motor control software development and testing process is going to be made. Blowing a power stage is expensive and takes time to repair : it means you cannot afford to simply “develop some code and test” just like you would while developping a PC/mobile software application. It means you need to be sure that when you are going to turn the power switch on, you are not going to destroy your system.

How can you do that ? Well, you know my pitch on this.

The Virtualization of Embedded Computing


In September 2011, I have been contacted by CATA‘s Jean-Guy Rens who was doing a study regarding the embedded systems industry in Canada titled “The Other Computing : Is Canada ready for the Internet of Things ?“. You can freely access his full study here.

We had an interview together to get my insights regarding future development of this industry. He finally decided to place this interview as the foreword of his study and called it “The Virtualization of Embedded Computing”. Here are some parts of this interview :

Being fluent in embedded software engineering is not enough

“Embedded systems are a horizontal technology, but their applications scopes are vertical. Many people are studying the embedded system itself, but the real challenge is to apply this knowledge to vertical applications. That is why I introduce myself as a software engineer who migrated to energy applications. I speak both “electric motor” and “embedded software”. Too often, electric motors specialists are not knowledgeable about embedded software and vice versa. Alizem’s expertise is to translate the needs of electric motor-based system designers into embedded software solutions. It is not sufficient to be an expert in C programming to be able to design an application that will fully satisfy a particular need. Too often, developers think they are able to create all purpose applications. That’s why the cost of embedded systems software development is skyrocketing. For my part I tend to consider that software programming is an engineering core skill. It’s like reading and writing: it is not because someone can write that he is equally capable of writing novels, political speeches and pamphlets for department stores. For an engineer, the challenge is to design solutions that encapsulate application knowledge (complex, rare and expensive to develop), within a short time to market, but without compromising product quality and performance. The technology of embedded systems is known and accessible to all. The challenge is to quickly and efficiently integrate modules that work first time around.”

Software now comes first, electronics second

“It is possible to compare the embedded system to a home. For centuries, it is the people who were makers of brick and cement that built the houses. The design, modeling and decoration of the house came as an afterthought. This process has changed beyond recognition when we started asking architects to make plans for our houses – or to program them virtually, if we are to continue our analogy. Even decorators – more often referred to as interior designers – are consulted from the start of the house project. It is they who define the plans of the house – the contractor comes later, to handle the actual construction.  Everything happens exactly the same way in the embedded world. The engineer in microelectronics is the contractor with the bricks and mortar. If a microelectronics firm persists in programming an embedded system application from ‘a’ to ‘z’, it behaves like the ancient contractor who made himself the bricks with which he built a house, then would seek the aggregate of the mortar on the side of the river and so on. Such behavior was probably justified for the early embedded systems when devices had limited computing power and range of applications. Developers who all belonged to the world of electrical engineering approached their various projects from a hardware perspective: they had to practically invent their work tools as well as the final product. The rudimentary software used, a few hundred lines of code, was a detail they did not care about too much. But times have changed and electronics has become a commodity: the bulk of the value is migrating towards the software side. Today, embedded systems are software-driven. It is up to the software engineer to be both the architect and the decorator – he is the natural project manager. This role reversal is hard to accept by traditional electronic engineers. The result is a culture shock.”


EDA Tool in the cloud: A web-based IOPT Petri Net Editor

A few weeks ago, I have been pleased to attend IECON2013 in Vienna and had the chance to meet my friend Luis Gomes from the University Nova of Lisboa, Portugal. While discussing together, he took some time to give me some details about a web-based framework that he designed with his team. This framework is called “IOPT-Tools” and this is a on-line Petri Net editor. Petri nets are useful to modelize any type of process and are used in many different applications (e.g. workflow management or UAV fault diagnostics).

What’s cool about this tool (other than being web-based, i.e. not having to install it on your desktop computer) is that once your have modelized your system, you can run all sorts of analysis to validate system behavior and even automatically generate VHDL code or C code to embed your model inside a controller. Here is a screen shot of a model used for BLDC motor commutation:


This tool in totally in line with current discussions in the EDA community regarding the migration of EDA tools in the cloud (see Cadence blog or Synopsis blog on this). EDA in the cloud in the idea of having tools for chip/embedded system design being offered as Software-As-a-Service (SaaS) and running on powerful servers so that even small teams could leverage important computing power they could not afford otherwise. With the rising complexity of chip design, it is well known that always more computing power is needed to compile designs and the solution won’t come from the standard computing solutions.

Congrats to the team of Dr. Gomes for their vision in developping this new tool ! You can access it and use it right now for FREE by following this link.

For more information regarding this tool, you can also consult some publications on the IEEE Explore. If somehow you use this tool and want to publish an article at the next IEEE IES IECON2014 conference in Dallas, TX, watch for the Call for Paper here.

Why developing power electronics embedded software is so hard ?

Here is a figure I did use in a recent presentation explaining why power electronics software is so hard to develop:

Hence, in order to create quality embedded software for power electronics applications, one must have advanced knowledge on :

  • the load (motor type, dynamics, etc),
  • the electrical source (topology of the power converter, devices technologies, etc.),
  • the electronics, i.e. the device on which the software is going to run and also transducers that are going to interface with the device and the system,
  • and embedded software development, of course.
Each of those topic is in itself a speciality and represent very different branches and cultures of electrical engineering (EE), i.e. ‘power’ vs ‘software’. Those cultures are so different that the following situation arises:
  • the ‘power engineer’ doesn’t know about software development and often minimize its importance (this most of the time leads to bad software development practices which makes the situation worse),
  • the ‘software engineer’ doesn’t know about power applications since this is way out of his traditionnal type of applications (web, internet, applicative) and neglect to consider that he is working with energy (i.e.  error is not leading to a blue screen but to a damaged system or to personel injury).
In a recent interview, I made an analogy with this situation naming embedded software for power electronics applications as the triathlon of electrical engineering. The best triathlete is not the perfect swimmer, the perfect cyclist or the perfect runner: he is the best at maximizing performance in those three sports.
It is the same with embedded software for power electronics applications and this is why it is so hard.

FPGA-based motor control – A Review of 2011

To begin 2012, let’s recap major events/announcements that have been made in the exciting world of FPGA-based motor control during 2011:

FPGA vendors

In March, Microsemi announced its new Industrial Ecosystem for SmartFusion Intelligent Mixed Signal FPGAs. This ecosystem is intended to specifically address the following markets/applications: Power Metering and Smart Grid, Motor Control (PMSM, BLDC, Stepper), Human-Machine Interfaces, Displays and Field Devices. A week later, Microsemi announced their comprehensive product portfolio for solar power applications which includes computing devices (SmartFusion) but also analog and switching components (IGBT, diodes, etc.) – which is the logic result of the Microsemi’s acquisition of Actel during fall 2010 (on this thread read this). Unfortunately, no news on the announced SmartFusion-based motor control development kit during the year, but those who did attend APEC 2011 at Forth Worth, TX, have had the chance to have a look at Microsemi’s SmartFusion FPGA-based motor control development kit at Alizem‘s booth:

Microsemi's SmartFusion FPGA-based Motor Control development kit

On Xilinx’s side, 2011 has been an important year with the release of their new ARM-based Zynq devices and also the release of a new Xilinx Spartan6 FPGA-based motor control development kit. The big news regarding Xilinx’s Zynq for FPGA-based motor control designers is that it has integrated A2D converters, an element that’s crucial to advanced motor drives systems. Except Microsemi’s SmartFusion, no FPGA vendor had a device with integrated A2Ds and this was certainly one important point missing against conventionnal devices (DSPs & MCUs) which all have integrated A2Ds for control system applications. According to Xilinx, this new Zynq device is going to be in production by the end of 2012 and it is positionned as a device that’s more than a processor, more than an asic and more than an fpga.

On Altera’s side, a new Motor Control development kit has been released during the summer and based on Arrow’s BeMicro low-cost form factor (145$). This platform is intended as an introductory platform for new comers in FPGA-based embedded system design which may then proceed to more advanced system design using already available Arrow’s MotionFire and EBV’s Falcon Eye Altera FPGA-based motor control development kits. Regarding devices, Altera has also made a move toward ARM-based system with their SoC FPGA and released a specific white paper for motor control using SoC FPGA. On a more educationnal side, Altera has released many publications this year intended specifically to FPGA-based motor control system designers such as 4 reasons why FPGA are right for Motor Control.

While we haven’t hear very much about Lattice in motor control / power electronics apps for a while, 2011 has been an exception with the release of a new LatticeECP3 Versa Development Kit in April. This kit is intended to be used in many computing intensive applications including Solar Panel Controllers and Data Acquisition & Control and also Video Transmission and Repeaters, Video Image Signal Processing, Camera Controllers, Network Traffic Management and Resilient Network Construction.

Motor control “apps” / subsystem IP

Over the years, this blog has published some articles explaining why the concept of “Motor Control IP/apps” – as a way to externalize/outsource motor control expertise – is an innovative and interesting option to motor control system designers to achieve their system performance while reducing cost and time to market (read Motor Control IC vs Motor Control IP and Why FPGAs are better than DSPs for Motor Control ?). I did present a synthesis of those ideas as invited speaker at the e-Drive’s Motor, Drive & Automation System conference in San Antonio, TX, in March and the presentation has now been viewed online more than +1300 times. Those ideas are inline with the concept of “Subsystem IP” which is now perceived as a key part in “Imminent EDA Transformation” and the “Core of Modern Semiconductor Design“. The whole idea of an “apps-store” for embedded systems is now taking reality with the recent launch of the ARM/Avnet Embedded Software Store and also the D&R Embedded: this is probably only the beginning. Hence, ideas from only a couple years ago are definitely taking place and are changing ways to approach the difficult task of embedded system design.

What to expect in 2012?

This is always a tricky question to address but if you follow this blog regularly, you can see a momentum building toward greater adoption of FPGAs as electronic system platform for motor drive systems design and “IPs/Apps” as building blocks for motor drive system designers. Having now the major FPGA companies aligned on this market is definitely a good indicator. Regarding this blog, you may expect some change toward more content on the “IPs/Apps” side (i.e. pure motor control algorithms/software) not only oriented toward FPGA, but also toward other electronic devices on the market. More on this later in 2012…

Meanwhile, thanks for your interest and I wish you success in your power electronics system design in 2012 !

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.