ARM spec chips are known to consume less power and are suitable for resource-constrained applications. At the recent ARM TechCon, the main theme was low-power computing. But a chip alone cannot accomplish that. Low power means less computing power and less memory and storage. Utility, middleware, and application software must be designed for and tailored to that kind of environment. I interviewed four software companies at the conference and one of them was IAR Systems. After all, I am a software guy. And one thing I like about embedded systems is that they use C and C++ predominantly, with some Java, which I can still read (but not write anymore).
I sat down with some IAR folks to find out more about their power debugging. When I interview a company, it is usually one or two people who come to see me. This time it was a bargain. I got four of them who cover CEO, marketing, technology to international market functions as a group. Because of this, I got a pretty good insight into the company and its products.
From left: Kiyofumi Kamimura, Thomas Sporrong (standing), Fredrik Medin, and Stefan Skarin.
IAR is headquartered in Uppsala, Sweden. This city sounds familiar because MySQL was headquartered there before its move to the US. Kiyofumi is a country manager for Japan. We could have used Swedish, English, or Japanese, but because my Swedish is rusty, they were nice enough to agree to conduct an interview in English.
IAR has been around for 30 years, so we cannot call it a startup anymore, for sure. The total number of employees is around 160 and 70 of them are developers. Turnover is extremely low. Over the years, only three people have left the engineering development team. Most of the developers are gray haired after many years of experience with the company. Some have been with the company for thirty, twenty, or fifteen years. They are still doing basically the same job. It is quite a contrast to Silicon Valley. Large Japanese companies are known to have very low turnover, although that is rapidly changing. Even though people may not leave their company, they move around within the company in Japan. If you are a programmer and with your company for decades, you tend to be promoted to manager and no longer touch programming.
This is one of the strong points of IAR. Their clients are happy because the same guy works on their project for many years and it is easy to communicate with the programmers. Also, internally useful know-how and knowledge of how to produce efficient and high-quality code accumulate over the years. That is a great asset for them. They focus on delivering products but not services. Thus, this vast amount of software development knowledge is kept inside the company.
From the green IT point of view, measuring hardware energy consumption and comparing its energy efficiency with that of other hardware are fairly straightforward. We could measure power consumption and compare multiple hardware platforms based on the measurement. What we do is to put a probe into a circuit board and measure signals and power. But when it comes to software, it gets more complex and difficult. Given a specification, there are many more ways to implement a solution with software than with hardware platforms. Even using the same algorithm, we could still fine-tune it and adjust data structures. For software performance, we have used something like profiling. I was a software programmer once and used it myself. By now my programming skill is so rusty that I do not want to mention that I earned my living by writing programs in the past.
The difficulty of software is code itself. Code is a static entity, and it is very hard to predict software behavior in action. That is why profiling is very effective. We can gain dynamic behavioral information, such as how many times a particular section is exercised in a run. With that information, we could modify and improve software to run more efficiently. Although that is very useful information, it is still logical information. Profiling is mainly used to speed up software but not necessarily to reduce power consumption. If we are on a platform that has plenty of computing power, memory, and storage, then speed is very important. But in a resource-constrained, embedded world, sometimes power consumption reduction may be more important than speed.
What if we can get more precise information about what each section or statement of software consumes in terms of electrical power? That would be very helpful for programmers in fine-tuning their software, and it is what power debugging is all about. As shown in the picture below, as in a typical debugger you can see the program execution at the source code level along with the assembly code equivalent and power consumption information at the statement level. By observing how power consumption changes as the execution proceeds and how much power each statement consumes, the programmer can modify the code to reduce power consumption. Of course, that information alone would not show how to change the code. As you know, a software modification tends not to be localized except in very simple cases. One change may have multiple impacts within the same function but sometimes also in other functions. That is up to the programmer.
The overall system power consumption is shown as a graph in the Timeline Window. Double-clicking on any part of that graph will take you to the corresponding location in C source and disassembly views above.
The setup seems to be fairly straightforward and easy. What you need is a circuit board, power debugger probe (I-jet), and GUI software on a PC, as in the picture below. I-jet has an interface to a circuit board and provides power to the board via a host computer, the PC. I-jet is connected to the PC via USB. By the way, IAR’s product works with C and C++ code, which is dominant in the embedded world.
GUI on a PC connected to a circuit board via I-jet (yellow box).
In addition to tuning software performance, a power debugger like this can be used to fine-tune a circuit board. If we find higher power consumption than expected, we may want to lower clock speed or reduce the RAM size, sacrificing speed. On the other hand, if we find that the program does not require as much memory as installed, we could replace it with less memory.
This is very interesting. What will they do next? They told me that the current version allows putting a probe into the entire circuit board. The future version should allow measuring only a particular micro-controller rather than the whole board.
Speaking of the future, I asked them about the applicability of their solution to the server environment in a data center. Most attention has been given to the facilities and hardware side of IT for energy efficiency. Even power usage effectiveness (PUE), the most used data center metric for energy efficiency, only considers the total power consumption of the data center as a whole and IT as a whole. People are starting to shift their focus to software for energy efficiency. It is far more difficult to deal with software because it is more complex than hardware.
They are currently focusing on embedded systems and pointed out a couple of things to me. One is that in the embedded world, each software is pretty unique and developers probably need to write 90% of the code, with the rest coming from libraries and such. So power debugging makes sense. In contrast, in the enterprise environment, programming is minimal and the rest is done by integrating existing code. Because of that, its relevance in the enterprise environment may be minimal. That may be true, but we can use power debugging to pick the most energy efficient libraries and utilities/middleware when we have the freedom to choose. The other point is that ARM is entering the server world, in addition to the embedded world. For example, AMD, HP, and others are planning ARM-based data centers. AMD acquired SeaMicro, an ARM-based server vendor, earlier this year. HP and Calxeda are working on an ARM-based server named MoonShot.
If ARM-based chips become prevalent in the data center environment, many software packages will have to be rewritten to run on the new ARM platform. If that happens, IAR’s power debugging idea can be used.