Archive for the 'Uncategorized' Category

With this post, I would like to continue the topic of my earlier post “Can we stop power-hungry bugs from clawing their way through application software stacks?” In my previous post, I wrote about the difficulties software developers face with writing battery friendly software. I indicated that virtual prototypes (VPs) can address many of those challenges by providing visibility into the energy consumption of the software under development. Now, I would like to shed some light on how virtual prototypes can accomplish this.

In order to give software developers the ability to profile the impact of software changes on energy consumption, the underlying execution target needs to expose the energy consumed by the different components that make up the system – over time and ideally through the perspective of software activity. Therefore, the profiling environment needs to be able to quantify the energy contribution from the different platform components.  However, development boards with power measurement probes are only accessible for a handful of software engineers, and are typically made available too late in the design cycle to allow development and testing of the power management software functions.  Moreover, they are not available to the community of application software providers whose software has significant influence on a battery’s mileage.

The virtual prototypes that are typically used today by software developers have no notion of power. Their models are purely functional, abstract in their timing behavior and with no link to implementation or silicon process technology. If you claim that VPs can still be very helpful for software developers to get energy under control, it is likely that hardware engineers will view you as a charlatan since, from their perspective, gate-level simulation is a minimum requirement to gain a decent impression on the energy footprint of the system. This is somewhat true, but the hardware engineers have a different problem to solve. Software developers do not intend to optimize logic circuits. Instead, they need to make sure they utilize the system power management features in the best possible way. A debuggable, repeatable, deterministic, scenario-driven trend-based analysis of the system’s dynamic power consumption is more relevant for them, then the ability to derive the exact energy consumption of the system (uWh). This task is perfectly feasible with a VP.

Here, the characterization of the important power states and events in the system components is the most relevant task. For example, a CPU can switch to the lower power idle state if software synchronization is performed via a semaphore rather than a spin-lock style active wait. The LCD brightness can be reduced if no user interface interaction is required. A position update can be done via 3G or GPS with different power states and durations. Exposing the power states is of great benefit to the software developer, but even energy-trend estimation can be accomplished with coarse grain, state/event-based characterization from datasheets.

The question is will the incorporation of power data into system simulation simply increase the complexity of the modeling problem? In addition to making sure that we have all of the functional models, do we now also need all of the associated power models? The answer is no. Power and functionality can be orthogonalized. With VPs, power models can be provided as an overlay to the functionality of the VP.  Through the introspection capabilities of a VP, functional models can drive power model overlays through observable properties such as signals, registers or other instrumentation. This allows the user to create power models for only the aspects of the system s/he is interested in.

A single VP can be characterized to reflect the energy dynamics for very different system flavors. A functional Ethernet model can be characterized to mimic different hardware vendor parts and can be even characterized to mimic the dynamic power of a WiFi radio. A WiFi radio may transmit/receive in low power or high power state depending on the data rate requested by the software. Such a coarse grain WiFi power model can be driven by inspecting the data rate of the generic Ethernet model.  This is sufficient for many software design decisions and proven by the success of the Power Tutor Android Application. This Android application comes with power models for various hand-sets (e.g. HTC Dream/Magic), and implements such a WiFi model with surprising accuracy. In this case, the power models are driven by embedded software.

Here lies another big opportunity for VPs. We can use embedded software functions (e.g. driver suspend, resume, send) to realize power models for parts of the system that are not even functionally modeled in the VP. Now we are starting to use VP as an enabling tool for software developers, rather than a pure simulation model of a piece of hardware.

In the future, we expect that temperature will become part of the puzzle for the software developer. Power consumption is highly temperature dependent. Interestingly, this impacts the software developer in the choice of CPU idle management strategy (Run-Fast-Then-Stop or Dynamic-Voltage-Frequency-Scaling).

There is much more to say with regard to this topic, even going beyond the software perspective and how VPs can help to architect power friendly platforms. Also, there are a lot of imperfect aspects such as standardization of formats etc. However, already today, there is a great chance to get some aspects of the pest under control using virtual prototyping.

Have a relaxing christmas!

Identifying and describing power issues is tough, let alone trying to solve them. “Power” issues can be very diverse. It’s even more difficult to explain how virtual prototypes can help to analyze “power” consumption. We often approach it by introducing how power information can be reflected in virtual prototype models, but there are many different goals and conflicting views on accuracy, granularity, modeling approach, data sources, etc.

Some engineers will care about power, but most will care about energy efficiency. Some engineers will look at just a single block, while others care about processor subsystems and entire platforms. Some software engineers focus on a single piece of software, others care about the entire software stack.

So instead, we need to approach it from the software engineers’ intent. For example, software stacks using Android with multiple tens of millions of lines of code implement various power-saving strategies on almost every software layer, starting at the OS kernel and ending up in the application layer. A software power inefficiency or malfunction can quickly cause a 5x drop in device standby time. A Google example shows that a simple RSS feed application that wakes up the phone every 10 minutes for just 8 seconds at a time to do some updates, via the Internet, can cut the standby time of the phone in half. An almost endless list of battery drain problems reported by end-users can be found here. Of course, the most prominent example is the recent iOS bug. Why is so difficult to get this under control? Let’s examine some of the key issues:

 1. Profiling the impact of software changes on energy. A software developer needs to be able to determine the relative impact of his implementation choices on energy. For example, is it “better” to use a spin-lock or a semaphore in the Android sensor poll function when waiting for accelerometer data from the hardware? A spin-lock is faster, but does not allow the CPU to go idle while waiting. The developer needs to find the right balance between responsiveness and energy consumption. While this example only looks at the CPU, most cases are concerned with the efficient use of the other HW components, too.

Here’s another example: In an application that requires location information, is it “better” to use coarse-grained updates from the GPS, or fine-grained updates for 3G? The data needed to compare the two options are as follows: 1) the time it takes to complete the task, and 2) the power level to compute the energy (e.g. GPS: 25 seconds * 140mA at about 1mAh, Network: 2 seconds * 180mA  at about 0.1mAh). Again, the decision cannot be made only by the energy savings. It also requires an understanding of the performance demands of the particular service. Are we looking at a driving navigation or a walking navigation? Both would have different requirements on the precision.

 2. Interference and side effects of local software changes on other modules. An application or service that requires a periodic network update can trigger a cascade. Other less important services may just be waiting for a connection to be established. So instead of doing a 1 second update every 10 minutes we may easily trigger a 1 minute online activity caused by waking up background applications. Here, the software developer needs to understand those cascades through an energy profile that shows an unexpectedly high peak and an estimation of the resulting standby time. Handset makers face this interference challenge when integrating multiple software modules from various suppliers.

 3. Ensuring that multiple concurrent power management frameworks collaborate. System-wide and runtime power management are just two examples in the Linux kernel that need to collaborate. The former turns the whole phone into a suspend state and wakes it up without loss of data. The latter controls power states of hardware components while the phone is used. A typical issue is when a component that has been shut down by the runtime power-management  prevents the device from going into a system-wide suspension because it needs to be woken up first. Power management debugging can easily become a nightmare, because even debugging and tracing services are impacted and may shut down during suspend/resume phases. Moreover, wrong settings in the constraints for the voltage regulator drivers can even result in lasting hardware damage.

 4. Many inefficiencies and malfunctions only appear in usage context sensitive scenarios. Energy inefficiencies or power malfunctions are highly context-sensitive. The context is defined by how the device is interacting with the environment. Next to the user, the device and the software stack are linked to the environment through network 3G, WiFi, NFC/Bluetooth, cameras and many other sensors (acceleration, orientation, magnetic field, proximity, temperature, etc.). When optimizing software for energy, the usage scenario that drives the stimuli to the device needs to be repeatable in order to get deterministic and comparable results. Testing requires automation of those scenarios along with a certain level of randomization. During testing, developers need to check that all applications/services are implemented according to the coding guidelines (e.g. for application using the sensors, the programming reference says: “Always make sure to disable sensors you don’t need, especially when your activity is paused. Failing to do so can drain the battery in just a few hours. Note that the system will not disable sensors automatically when the screen turns off.”)

 Looking at the above challenges, it becomes clear that to effectively debug and optimize power using virtual prototypes we have to look beyond it as just a way to instrument the models with power information. In my next blogs I will explain how the four important requirements mentioned in this blog can be successfully addressed using virtual prototypes. Maybe we can tone down those software bugs’ appetites.

In my last post I introduced the debugging challenges during porting, or developing native code, for Android.  This time I would like to outline how virtual prototypes can enable  software debugging and perform in an even better way. Before I describe what “better” refers to exactly, I want to shed some light on some prominent myths around the value of VPs for debugging.

Whenever VPs are mentioned in the context of debugging, it’s claimed that they offer many debugging advantages over real hardware. It is said that VPs have better controllability, visibility and provide determinism. But is this really true? And what does this really mean for a software developer?

For many people, a VP is nothing more than a piece of software simulating a HW/SW system. This software (the VP) can be debugged on the host PC of the user. Using the host’s software debugging tools, or VP vendor-specific tools, the user is able to inspect all aspects of the platform such as memories, registers and signals. Also, he/she can suspend the simulation in the host debugger, and above all has full control over the VP. The next time anyone executes the VP it is likely that it will perform the same functions in the same order as before, and that its behavior will be fully deterministic (as long as there is no interaction with non-deterministic external components such as the user). This all sounds great, but it does not consider the real needs of a software developer.

“Run-mode” software debugging using a VP

While a software developer is definitely thankful for inspecting the hardware beyond what is possible with a software debugger, in the first place he/she will still need to debug software.  This is of course also possible with a VP. Most VPs do contain virtualized interfaces such as USB, Ethernet or UART. Those interfaces allow a software debugger to connect to an embedded software agent. This agent establishes the connection between the debug target and the debugger. Now a VP can be easily combined with arbitrary software debug tools and even integrated into SDKs. As an example, the Google Android SDK connects to the debug target through Ethernet. This works perfectly with a VP.

Interestingly, this is not any different from the way it is done with real hardware. But unfortunately, also no real advantages exist. The praised controllability, visibility and determinism has to be re-evaluated. The control is now with the software debugger. When you suspend using the SW debugger, the VP will keep running. Timers, watchdogs and other SW processes continue to work (so called “run mode” debugging). In order to inspect the HW and correlate the platform state with the software state, you would need to suspend the VP. But, if you suspend the VP, then the debugger communication will likely time out. Remember, the embedded software agent is also halted.  Also, the agent itself influences the execution of the overall system and has side effects. Now, the determinism is also gone. But, there is a solution to combine the best of both worlds.

Virtual prototypes as debug servers

To marry the advantages of VPs and software debuggers, the VP simulation framework needs to take over the task of the software agent and act as a debug server. The debug server establishes the link between the software debugger and the VP simulation. Now we can take advantage of the VP’s “view from the top” and serve even multiple software debuggers with information from all over the platform. The debug server also orchestrates the control and makes sure all debug views are synchronized. The debug server itself does not interfere with the execution of the platform. Neither the hardware models, nor the software, can tell whether they are debugged or not. Now the VP can really play its hand and deliver all the advantages to the software engineers.  Summarizing, it is important to recognize that a VP is more than a model. A VP requires tooling to make it useful beyond simulation.

Coming back to Android and my previous post: The 21 steps to set up a debugger to debug native code can now be reduced to two. Using a VP with a debug server, you set a breakpoint at the address and process that you are interested in; afterward you simply connect the software debugger. No more worries about when and how to launch the gdb-server agent.  But VPs even help in the context of using run-mode debugging of Android native code libraries. The user of the VP can easily inject an endless loop within the start-up code of an embedded software process just by writing the instructions into the VP memories. No change and recompilation of the embedded software is needed, as required in the best practice.

Presenting at the first exhibitor forum session at DAC, during some difficult economic times, is always somewhat of a risk. It wasn’t clear how big an audience we should expect. Standing in front of the exhibitor forum seating area, I was waiting with my co-presenters without high hopes. The first 5 people started to get seated 20 minutes before the presentation. And eventually attendees filled the seats … I shouldn’t have worried. Over 100 persons attended our presentation on Addressing the Design Challenges of ARM-Based LTE Mobile Phone Designs Using System Virtualization. Together, with IP model partners ARM, Ltd. and Carbon Design Systems, CoWare explained how CoWare Electronic System Virtualization solutions address the design challenges that hardware and software engineers working on LTE mobile phone designs are facing. Based on the questions from the audience, it is clear that standards like SystemC are very important and that the complexity of their designs demand a fast and flexible solution for multi-core designs.

These items are exactly some of the key strengths of CoWare Electronic System Virtualization solutions. As recent customer success stories prove, not only has CoWare been consistently leading the industry with standards-based ESV solutions, customers are choosing CoWare ESV solutions for their complex multi-core designs. Since this type of design is becoming the de facto standard for today’s electronic devices, virtualization needs will only grow.

Looking back at the audience for the electronic system virtualization exhibitor forum session, interest in system virtualization is already growing and people are more than ever looking at CoWare to help pull in design time, lower costs and enable the supply chain. It is promising to be an interesting DAC.