Extending Battery Life of a Mobile SoC

Introduction

"How much is your Antutu score?" This used to be a relevant question for mobile SoC developers, but not any longer!

Over the last few years, the application processor domain, has seen a race with respect to the number of cores in a system-on-chip (SoC). You will easily recall marketing for "dual core", then it was "quad core", followed by "octa core" (8), big.LITTLE, and even up to 10 cores. A similar story applies for GPUs, which has been mainly fueled by the smartphone mobile market.

However, the landscape is changing in several ways and increasing numbers of cores isn't necessarily the goal. Power considerations are gaining relevance as a factor for chipset makers to select an application processor chipset from a supplier, due to the following:

1. Battery life, especially for consumer devices, which is further accentuated by the recent diversification of handheld products/gadgets like smartwatches.
2. Thermal is another consideration, as it directly impacts the performance, and cost of the PPA (Performance Power Area of a SoC). In addition, heat issues are impacting the ease of silicon implementation and the durability of the chip itself.

Power Optimization and Power Estimation

Power optimization and power estimation are two different approaches, but aim towards the same goal: reducing the overall power consumption. They differ in the way they look at the problem.

Power Optimization techniques can be applied during the implementation of each part of the SoC hardware and software. Techniques vary depending on the nature of the part being implemented and optimized. For instance, EDA tools focus on RTL and gate level optimization.  Whereas, software profiling tools focus on the optimization of runtime libraries. Power measurement metrics for these kinds of optimizations require accurate knowledge of each component being optimized.

Power Estimation techniques are applied before the implementation; or as a way to compare between different implementation options, followed by selecting the most appropriate. As such, power estimation does not require deep detailed knowledge of each component of the SoC (like implementation details about the hardware block or the software module) but just the component power characteristics. It turns out that this block level is good enough to compare alternative implementation options.

This article focuses on power estimation at the SoC block level.

SoC Level Power Estimation

There are two constituents for power estimation: Static constituent as the characterization of the power number and dynamic constituent as the simulation of scenarios.

1. The static constituent covers characterizing the power consumed by a hardware block in a given state. For SoC level power estimation each major hardware block (CPU and GPU) has an associated power state, with each block able to be in one state at a given time. Each state also has an associated power mW (milliwatt) number based on a 'static' characterization.
2. The dynamic constituent covers the power estimation for a given scenario of state changes. A scenario reproduces the condition under which the SoC is performing, of which there can be many. The scenarios cover the typical situations in which the product is expected to be used. Each scenario will drive the hardware SoC block to jump from one power state to another.

For handheld battery operated product, managed upon a 'best effort' strategy, these two constituents are key factors for the power estimation.

Producing Scenarios with Virtualizer

Virtual prototyping, using Virtualizer, is the best approach to produce these scenarios, as it enables:

• execution of realistic scenarios based on actual software performing in near-real conditions
• preparation of the software before the hardware implementation options have been fixed, and,
• modeling clock variations for power on/off states.

For a general introduction of Virtualizer, please click here.  For detailed explanation of other use cases, refer to the Better Software. Faster! virtual prototyping book.

For this virtual prototyping customer, prototyping using Virtualizer is an established flow. The ability to enable power estimation is a simple extension to the existing Virtualizer prototyping flow.

Virtualizer enables an incremental prototyping flow, which can be initiated very early in a new SoC development process:

• Starting with the CPU subsystem to enable the porting of the Linux kernel.
• Followed by an incremental extension of the prototype to multiple software teams. This extension can happen in parallel. Below are typical stages when extending the prototype scope:
  • adding support for simple PMU (Power Management Unit) and Storage (eMMC) for boot sequence
  • adding display in KMI (keyboard and mouse interface) for Android
  • adding support for Interface I/O IP for Linux driver upgrade and integration
  • adding support for GPU (or large image processing engines) in a hybrid emulation system for driver integration and testing
  • adding trustzone security feature and brushing up the boot loader and runtime security libraries
  • adding power model for Linux power framework bring-up
  • adding benchmark and full stack testing of Android level application.

It is important to notice that even the initial VDK, shown in Figure 1, is making use of the latest ARM Cortex application processor version that only exists as a simulation model but not as stable RTL. This is important for power estimation as the software stimuli should be as close as possible to the final multicore reality.

Linux Power Management Software Bring-up

The bring-up of the Linux software layer that manages the power is the first important step towards enabling the power estimation flow. This requires the availability of models for the PMU and CMU blocks (Power and Clock Management Unit). These SystemC models are either developed or can be reused from existing examples or previous projects.

Once the software is working functionally correct a power model overlay can be attached to these models (see Figure 2). One capability of the power model overlay is to provide warnings when the model is in a state in which the IP block cannot be accessed (i.e. if a hardware is in retention mode or power down, then the software cannot read a status register).

The platform extension with the power overlay model makes it is possible to execute and test various corner cases related to power.

Link to Power Estimation

Once the power overlay model is available the different scenarios for the power estimation can be prepared.

These scenarios must be driven from the application level and capture the behavior of the end-user interacting with the smart phone like one would do in the real world. For performance scenarios, there are a plethora of benchmarks (BBench, Antutu, etc.). However, these scenarios are not really covering the full spectrum of real world user interaction and thus need to be complemented by other scenarios, such as web browsing, music planning, navigation, etc., (Figure 3).

Now these realistic scenarios together with the power overlay model can be used to estimate the duration each hardware block is in a certain power state. This is the dynamic part of the power estimation.

Let’s now go back to the static characterization part of power estimation.

Power Characterization for SoC Level Power Estimation

Each power state is characterized by an estimated mW value. RTL is not available early in the design and thus estimation based on actual or gate level power estimation technologies (e.g. based on switching activities) cannot be done. The selected alternate approach is to gather information from the ASIC teams based on last generation SoCs.

The approach to setup this flow has been to apply the characterization on a known already implemented design in silicon and compare results: simulated power model vs. real silicon (see Figure 4).

Information from ASIC teams came as basic power equations separating dynamic power and leakage.

First Design Power Estimation

To compare the measurement results, various Android benchmarks were executed on the VDK version of the SoC and on the final silicon.

The screenshots below (Figures 5 and 6) show the measurements and correlation of the various tests.

Comparing the VDK versus the real silicon has shown a strong correlation between silicon and the VDK for most of the test scenarios.

However, the absolute power figures were quite off:

• Comparing the relative energy consumption between each SoC block (cores) shows a relatively low error (ratio error margin <5% for 11 cases; ratio error margin <20% for 2 cases).
• Comparing variations between each cases also shows low error (overall divergence <7%).

Conclusion

The project represented a breakthrough for the customer and proved the ability to use virtual prototyping tools to setup a consistent and sustainable power estimation flow. Using Virtualizer enabled the customer to:

1. Create realistic scenarios to drive the simulation and perform dynamic power estimation
2. Collect information and knowledge from the ASIC team to further calibrate the power model and improve the next generation SoC.

Looking forward, the customer plans to expand the scope of this methodology to better cover certain hardware accelerators, revisit leakage and possibly investigate thermal analysis.

Also, now that IEEE 1801-2015 Unified Power Format (UPF) 3.0 has been announced as a standard, the ability to more easily exchange information for the characterization from ASIC and third-party IP suppliers is much anticipated.