Engineers' trouble: How to estimate the power consumption of the application when it is running

How do software application developers – and those sitting on their living room couches with their laptops – estimate the power consumption of their applications when running on the target device ? This is a big problem today (and one that is clearly a pain for iPhone and Blackberry users), and it will only get harder to solve in the future. Software engineers may think it is not their job. They just write the code and then push the problem to the hardware engineers, who are limited in their ability to solve the problem.

To be sure, hardware/software co-design environments will eventually become the 'new frontier' as higher and higher levels of abstraction are used - so engineers can simulate certain applications or functions. Of course, new tools will be needed to take these factors into account. But in general, it will probably still be a few years before these tools are available on engineers' workstations, let alone in the software development kits of developers working from home.

Ideally, if you could create a high-level model that breaks down the RTL description of the hardware down to the transaction level, you could capture the hardware information and pass it to the software application, whether it includes power consumption, software domain or something like that. Then the engineers can see the impact of the software and modify the hardware accordingly, said Vic Kulkarni, senior vice president and general manager of the RTL business unit at Apache Design Solutions. "But now it's the other way around: because hardware engineers use all sorts of hardware, and then software developers don't really understand what the hardware can do."

Pete Hardee, director of solutions marketing at Cadence Design Systems, points out that today’s smartphones are convergent devices, with computing power comparable to recent standalone devices. “Today’s smartphones have processing power comparable to mainstream PCs or laptops from four or five years ago”; they have video capabilities that set-top boxes only had two years ago; high-definition video and 3- to 5-megapixel cameras. At the same time, these capabilities are only possible because of the huge leaps in hardware technology that have made progress in the past (still clearly following Moore’s Law) and the leaps in software productivity that have actually surpassed Moore’s Law. What has not progressed is the ancient battery technology. So we are still using lithium-ion batteries. Designers do everything they can to squeeze the power out of the battery, but the basic expectation is that the phone will at least last a full workday and last until we get home and need to recharge it.”

Of course, it depends on what you do with your phone, but the bottom line is that it's all controlled by software. "When you analyze power, it's not just about characterizing the hardware. You also need to run a series of system modes that abstractly characterize the most workload - when all the apps are being used, and the less workload - when it's idle (not using multiple apps), and switch between these system modes so that I know when I can power down certain parts of the device and when I can't," Hardee said.

The challenge facing many chip companies today is the need to simulate 30 different system modes. They also have to painstakingly measure all of these modes, the bandwidth of various parts of the chip, and be very clear about how the power management system is actually handling them: which ones can be slowed down, which ones need to be accelerated so that they can be powered off longer. All of these different modes need to be measured. "Estimating the power of real systems running real software becomes a big problem, and there are very, very few solutions that can do that," he said. The prevailing wisdom is to use virtual platforms to do (power) measurements, but Hardee believes that virtual platforms are too abstract to measure power effects. "Once you really need to know the power mode implemented in hardware, then you need to run at a certain level of accuracy, and that slows down the virtual platform." To be fair, Cadence does include virtual platforms right up to its transaction-level simulator and integrates fast processor models from ARM and various other processors, but the company focuses on its hardware-based simulation system for power-sensitive simulation.

Engineers are already familiar with the concept of abstraction, starting with abstract gates-RTL and now abstracting higher-level RTL functions with SystemC (a system-level modeling language) and transaction-level modeling, according to Shabtay Matalon, ESL market development manager at Mentor Graphics. "People now realize that you can abstract timing by creating a model that doesn't have all the information but has enough information to get a sense of timing. But what people may not know is that we can create a model that can be used by software engineers that includes power abstraction all the way down to ESL or TLM." The model relates power to the flow through these transaction-level models. These models can be stitched together after they are created, Matalon said. These models can be peripheral device models, processor models or device models, and can be stitched together to produce a platform that can run application software.

Cary Chin, technical marketing director for the low-power solutions group at Synopsys, sees virtual platforms as the way to the higher-level layers. "There are a lot of very good ways to hook into the software stack through a virtual platform. But I still think the connection from the virtual platform down through the high-level RTL is still a little bit disconnected because there are a lot of elements that need to happen to connect these environments together." The big question that needs to be answered here, though, is how much we want to let software developers directly control the hardware, Cary Chin said. This is basically in direct opposition to the idea of ​​information hiding (modules communicate through their APIs, and one module does not need to know the internals of another module).

“In a software development environment, we try to hide things because there are some things we can’t really make better decisions about at a high level vs. low level. When you cross over from software to hardware, these concepts come with it, so it’s very hard to tell. You want to be able to write software that’s transferable between development environments or something like that, but if you’re tightly tying it to a specific hardware platform, it becomes very difficult.

Educational software developer

"With all of this, it's still possible to not write good software because data is used very inefficiently -- for example, maybe there are [cases] that keep refreshing the LCD screen unnecessarily," Hardee said. "How people get feedback really comes down to those app development kits that are provided by the phone manufacturer or the network operator (Sprint has an App Development Network). Phones that use Android have a development system. Feedback can be given to users about bad optimizations in those development kits, bad memory usage, and so on."

Part of the solution could be an industry chain or collaborative approach. “From the hardware side, the idea of ​​[EDA vendors] working with companies like Apple or Google in some way to really extend their development toolkits downwards might actually make as much sense as trying to build it because those guys have a lot of resources and they can meet up right in the middle to help out a lot,” Chin added.

But that still doesn't solve one of the big problems, which is the huge gap between software and hardware. "The gap between the hardware world and the software world is bigger than the gap between front-end design and back-end design. Hardware design and software design are not really connected well at the moment, and ultimately there are different levels of abstraction that people can think of in a sense, if you look at it from a software development perspective. There are high-level programming languages ​​C/C++, and there are low-level programming languages ​​assembly code," said Will Ruby, senior director of product engineering and applications at Apache Design Solutions. At least some of these (problems) can be handled in the short term using models, but some of them will require new technologies like smart compilers. "Assembly is actually closer to the hardware, but people don't usually program in assembly unless they're dealing with embedded programming. The concept of hardware needs to be transferred to a development environment like C/C++ or Java. That's where the patterns come in. We need models to characterize the hardware behavior, but I think we also need something like an intelligent compiler that can take advantage of some of these hardware hooks and understand that when you're programming for a mobile phone application, you need to make a trade-off between compiling for performance or power consumption. Hardware engineers have been thinking about this problem, but it's not an easy thing for software engineers. So the compiler may need to be involved in this direction. The compiler needs to be sensitive to the hardware and needs to understand what the hardware is doing," he concluded.