FPGA Technology and Software IP in Power Electronics Applications

The Virtualization of Embedded Computing

iStock_000005420109Small

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:

ioptbldc

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) !

DSP

FPGA

FPGA & IP

Out-of-the-box experience

Great.

Low.

Great.

Processor

Fixed.

None.

Configurable.

HW components (peripherals)

Fixed.

None.

Configurable.

System components integration

Tedious (HW)

Easy (SW).

Easy (SW)

Requires Motor Control expert

Yes.

Yes.

No.

Cost of HW/SW maintenance

High.

Very High.

Low.

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.