For (1,2,3), there are a lot of standard/COTS products available so that you can quickly have a prototype ready using those components (while there is still innovation going on in each of these areas). However, for (4), this is less obvious and knowing that embedded software costs amount for a large part of electronic product design (>50% according to PwC), it has to be carefully planned.

Splitting software into components

Software inside an electronic product can be split into 3 important components: (1) commodity interfaces, (2) specialized interfaces and (3) application software (that may or may not run over an OS) – see image below (taken from my ebook on custom electric motor drive design).

Commodity interfaces are typically packaged with your chip bundle of tools or available at a very low price, unless you are using something that’s not standard. Applications software is the software that is specific to your product (a robot, a drone, a medical device, etc.), i.e. “your sauce”. Then you have the “specialized interfaces”: middleware/drivers meant to work with a “complex” peripheral like a power stage or a camera. Those drivers typically contains very “domain-specific” functions that need advanced knowledge and expertise to be developped.

This is where it becomes tricky because you need to source those interfaces from somewhere: i.e. (1) develop them ‘in-house’ or (2) get them from a third party IP provider. The sourcing of the specialized interface is influenced by available time, budget, talent and also the type of product you are developping:

In house development of specialized interfaces can be an option when you have the expertise and when the product value is highly defined by this interface, e.g. a standard industrial motor drive.

Third party IP sourcing of specialized interfaced can be an option when your firm do not have this specific expertise in house and when the product is not highly defined by this interface, e.g. a medical device equipment.

Either option may also be influenced by the pressure on anticipated costs/profits and time of development of your product: the higher the pressure is on costs and time of development, the higher the benefits of leveraging third-party IP sourcing (if available and making financial sense against in-house development).

However, the lines get blurred when ones uses a “reference design”. Those reference designs typically come from a third-party (chip vendor) and are a great start for a project. However, it is important to know that a reference design is not an IP: you need domain expertise to use them otherwise you may get troubles, especially in power electronics applications. This topic is so important that I will make it stand as a future blog post shortly. Stay tuned!

Some of you may have noticed, I have changed the title of this blog from “FPGA Technology and Embedded Software IP in Power Electronics Apps” to “Embedded Software IP & Technology Transfer in Power Electronics Apps” (check the top of the screen). What has happened?

This blog began while I was still doing my PhD. in the field of FPGA-based motor drives in 2008 and lots of time has passed since then. With the recent acquisition of Altera by Intel, we can now think that FPGAs are now “mainstream” chips and their particularity is not that distant with other chips used for embedded computing on the market (as it used to be), other that you have some logic fabric on which you can design custom VHDL functions to work as peripherals to a processor (soft processor like NIOS II on the FPGA fabric or hard processor such as ARM on the chip itself aside the FPGA fabric). Of course this makes them special and unique to develop new type of applications – that you can’t do with other chips like DSPs and MCUs – but from the point of view of the embedded system design, especially with SoCs, they are not the “bizarre” chips anymore only reserved to old electrical engineers thinking only in VHDL.

That being said, the continuity with this blog is still “embedded software IP”. This is still a passion for me because, I am still amazed how the complexity of embedded software design is still ignored in the process of designing electronic products. Embedded software development for mobile phones, i.e. the “apps”, is very well developped and organized but it is pretty much complicated in all other applications where the electronic part is custom. There is still a lot of “electrical engineering” mentality in the approach of designing software for those applications and this is especially true for industrial/power electronics applications.

Because embedded software is so linked with innovation, i.e. little/no value in the hardware and most/all the value in the software, I have shifted the focus of this blog on the other side: on process of getting true innovation from labs to market, also known as “technology transfer“. This is where it connects with “intellectual property”, i.e. invention, patents, etc. By learning the process of how to really leverage existing intellectual property, a designer can really improve his productivity in developping new products. The designer embracing technology transfer is like the software engineer that learns to reuse existing code and build his application on the top of it (very productive), rather than building everything from scratch (not productive). For me, technology transfer is like “code reuse 2.0”.

Hence, at that time of the year I used to write a review of what happened in the field of FPGA, especially for power electronics applications. I won’t do it this year. I may come back next year with a similar idea. Meanwhile, I hope you will like this blog’s “new flavor”. Feel free to let me know what you think !

Are you new to Intel FPGA-based embedded system design? Make sure to download my new ebook: it contains all steps to design a basic FPGA-based embedded system from scratch including a (1) NIOS II processor-centric system in Qsys, (2) MAX10 FPGA pins assigments and (3) software running on the processor.

While going through this ebook, you will be able to identify key steps in designing your own system using Intel FPGA free EDA Tools. This is a great way to save time and to quickly put your efforts in building your own FPGA-based embedded system! This ebook is great not only for people designing FPGA-based embedded control systems, but to any people planning to design a new electronic product with a Intel FPGA for the first time.

TABLE OF CONTENT

Starting things off. EDA Tools and MAX10 Development kit.

Basic concepts.

First Step: FPGA/hardware part

Second Step: Software part

Third Step: Program & Play !

Frequently Asked Questions (FAQ)

How Alizem can help you achieve your business and technical objectives ?

You certainly know already a lots of things about IoT (if not, read this or this), but do you know about the Initial State’s IoT platform ? Briefly, that’s a web-based platform (SaaS) to which you can stream data out from your electronics devices. The platform is then going to store this data for you and enable you to visualize/report it quite nicely, always through your preferred web browser.

They have had quite success so far in the hobby/consumer space, enabling to easily pipe data out of a Raspberry PI for all sorts of cool applications. The need to pipe out informations from controllers is everywhere, especially in industrial electronics (that’s Industrial IoT, IIoT). Hence, this type of feature is a perfect fit with Alizem embedded motor control software products enabling to pipe out informations regarding electric motor’s states: temperature, currents, rotor position, speed, etc.

For those reasons, I am pleased to announce the release of Alizem IoT Interface software that’s meant to connect new and existing electrical equipment products to Initial State’s IoT platform. This new product is now available in two versions: standalone (great for existing products) and integrated into Alizem embedded motor control software (ideal for new products). Both versions include a reference design based on Altera MAX10 FPGA Development kit.

For electrical equipement manufacturers, that’s a great way to integrate IoT features easily and quickly and also to:

Accelerate product development by detection bugs early

Easily share data between development teams working at different locations

Remotely monitor critical performance data such as power consumption, load motion profiles, current shape and temperature

Build new value-added services by bundling their electrical equipment products with SaaS based monitoring services and provide peace-of-mind to your customers by having them access to all their equipment operation data

For more information, please visit www.alizem.com/iot and/or feel free to contact me over this blog.

If you are an electric motor drive designer, you might be interested in getting my brand new eBook:

This eBook provides guidelines to make the process of designing a custom electric motor drive faster and easier. Hence, whether you are a project manager, a system / mechanical / electrical / software engineer, you will find in this document relevant informations to help you achieve your objectives.

TABLE OF CONTENT

1- Why would you design a custom electric motor drive system ?
2- Reasons to use Commercial Off-the-Shelf (COTS) components

3- Anatomy of an electric motor drive system and COTS component selection

4- Bottleneck is software: how to plan the software development ?

4.1 – Application Software

4.2 – Commodity Interfaces Software

4.3 – Motor Control Software

5- Embedded Motor Control Software: Expertise needed !

5.1 – Developping from scratch

5.2 – Developping from reference design

5.3 – Developping from 3rd-party software

6- Development of a custom electric motor drive: A 5 steps process

6.1 – Step #1: Requirements

6.2 – Step #2: Design

6.3 – Step #3: Prototype

6.4 – Step #4: Product development

6.5 – Step #5: Production

7- How can Alizem help you achieve your business and technical objectives ?

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

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.

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.”

Time passes and it is now the moment to make a short review of what happenned, in my opinion, in the world of FPGA-based Motor Control and Embedded Motor Control software IP in 2013:

New FPGA evaluation kits

Lattice has started the year with the release of its new iCE40 LP384 development kit. While not being explicitely targeted for motor control but controllers in general, this FPGA is small and very low cost: less than 50 cents per unit in multi-million unit quantities. Even the evalutation kit is very low cost: both iCEblink40-HX1K Evaluation Kit and iCEblink40-LP1K Evaluation Kit are sold for 34.12$. Of course, those kits do not include any power stage, motor or transducers: you need to have your own.

A month later, Altera has annouced the release of its new Cyclone V SoC development kit. Built around a 800 MHz dual-core ARM Cortex-A9 processor and provided with all interfaces needed for maximum connectivity, this new device is clearly positionned in the same segment than Xilinx’s Zynq device (also built around ARM Cortex A9 dual-core processor) previously released in 2012. This kit interfaces with the FalconEye 2.0 motor control board.

Embedded Motor Control Software IP

In February, Texas Instrument (TI) has announced the release of their new INSTASpin-FOC sensorless motor control software. The pitch is “Identify, tune and fully control your motor in less than 5 minutes and eliminate the need for a mechanical rotor sensor” and meant to be used on TO C2000 Piccolo microcontrollers. According to TI, this helps saving months of design time which is inline with a topic previously addressed on this blog. To my knowledge, TI is currently the only motor control chip manufacturer offering such advanced motor control design tool. Note that this tool is meant to be used in sensorless applications, i.e. applications where near zero speed performance is not a requirement.

In October, my company Alizem has announced that our previously released Motor Control Software IP for Servo-Drives applications has reached a new level of performance on 100kW motors which has led into a licensing agreement with a major industrial OEM. At the same time, we have announced the signature of an agreement with the Canadian Space Agency regarding new motor control software technologies (stay tuned for the release shortly).

DesignNews Webinar

In May, I have had the pleasure of being invited to participate in a Webinar on the specific topic of FPGA-based motor control and sponsored by Altera. The discussion has been held around the following questions:

• What are the typical steps and challenges faced by system designers when designing motion controllers?

• From a motion control design point of view, how do FPGA/SoC devices and design flows compares to other devices?

• Communication networks are clearly critical: What are some of the challenges of Industrial Ethernet?

• What design tools and flows are needed to maximize system designer productivity?

• What is needed from device providers to enable designers to go further in their product innovation?

• What factors can reduce the overall cost of ownership of motion control development platforms?

The webinar is still available for off-line consultation if you are interested.

Is there anything else missing ? If you think yes, please let me know ! You can also contact me on any topic you would like me to address. Thanks for reading my blog!

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.