Redefining Performance In Mobile Devices

Battery life, features and functionality are now intricately bound together, making for some tough design and market decisions.

popularity

By Ann Steffora Mutschler
While mobile product trends can be reliably unpredictable, devices are definitely moving towards supporting more software-based browsers, plug-ins for browsers, and downloaded codecs to go to browsers. This results in coming up with a best guess for performance targets. Throw power tradeoffs into the mix and things really start to get interesting.

In terms of defining performance today, one of the first considerations is the usage of the device. Josefina Hobbs, technical solutions architect in the low-power solutions group at Synopsys, said a lot of the challenge is understanding what the users are going to do with these things. “Even tougher, developers have to make some guesses, so of course the better representation they have a real usage model is going to help get them there. What it really boils down to is how is this thing going to be used and how well can you guesstimate how it’s going to be used. The minute you are off on your guesstimate you’re going to be negatively impacting your battery life.”

In terms of CPU considerations, Bill Orner, director of platform engineering at MIPS Technologies explained, “You have to start at the top and work your way down. What features are required for the device? From the features you’ll determine things like operating system that are necessary to fill those features. How much functionality trade-off do you want to do between things that are soft implementations versus dedicated hardware? Take, for example, an iPod where people want to watch video on it. Do you put in dedicated video decode hardware or are you going to expect that the CPU has to do the decode of all the compressed video? That has a massively significant impact on the CPU requirements.”

Another consideration is the fact that to achieve the same level of performance, implementing in hardware is almost certainly an order of magnitude more efficient in terms of power and potentially system cost because software doesn’t have to be developed for that particular function, saidf MIPS engineering director Darren Jones. “The tradeoff is that when you put it in hardware it’s built exactly once and you can’t upgrade it in the field. But it’s almost certainly much more efficient to put it in hardware.”

Latency is tied very closely with performance in mobile devices. “Can I keep up with this video stream? That is one key thing. The other key thing is not just power, which is how quickly you use your energy but energy itself: energy efficiency. If it’s a battery-powered device it’s not really how much power you use, it’s how much energy you use to finish your computation function. This is why MIPS decided to go the route of multithreading first and then multiprocessing. Multithreading gives a much more efficient use of the existing hardware whereas with a multiprocessor approach, you are replicating efficient hardware,” Jones said.

For example, a processor runs really well as long as it’s getting instructions and data from its caches. But when it gets a cache miss, especially on a mobile device where cost is certainly a factor, the memory subsystem tends to be pretty slow. It could take 100 or 200 CPU cycles to get the data from memory. The whole time the CPU is sitting doing nothing it’s probably burning power so it’s not really doing nothing, but it’s not doing anything good. Multithreading allows the chip, as soon as it gets that cache miss to switch to a different software thread whose data is in the cache. That means that while it’s waiting for those hundred cycles it’s actually getting some real work done.

Challenges in defining performance
The tradeoff between power and performance is the biggest challenge, according to Eyal Bergman, director of product marketing for CEVA. “We see that the same vendors, especially in wireless devices, give pretty much the same power budget that they gave a few years back and this is simply because battery technology has not progressed at the same pace that wireless technology has progressed and as applications have been developed. We need to put more functionality into a device that was originally designed to be powered by a battery. And we are using pretty much the same battery—maybe 10% or 20% better—but pretty much the same technology. And now we see that we need to do much more. It could be 10 times more when we talk about wireless communications.”

As power is directly related to voltage levels, moving to smaller manufacturing geometries helps here. He pointed out that the same chip is manufactured with today’s 40nm technology can be four times as fast as 10-year-old technology in terms of power.

Improving processor and overall system architecture is also a daunting challenge. “In the past, people used to run everything in CPUs or in other blocks. Now we see more optimized processors for communications, for multimedia and video, for graphics and when you move from a general processing unit to an optimized processor you can get a lot of power reduction because basically the processor is much more efficient for the target application. It can do more with less,” Bergman explained.

Companies that take this approach–MIPS, CEVA, ARM, among others—can offer flexibility in terms of having the ability to do a lot of things with software, although it is for a specific type of application. You cannot do video decoding for the wireless processor but you can do multi-standard communications processing very efficiently.

As such, system architects have a bigger challenge than ever. “When we talk with the system integrators that they want interfaces to the processors. What you have on the system is the power management unit that is becoming more complex than you want. To have interfaces to the system level gives you flexibility to shut down processors. For instance, you want to be able to lower the speed and the voltage of the processor per use case in order to decide which parts of the system need to be activated and which need to be deactivated. And all of these interfaces need to be defined very closely with the architecture in the early stages because once you integrate at the top and don’t have the interfaces you will limit the flexibility later on,” he said.

Paradigm shift in mobile
Given the dynamic nature of the mobile device market, Jones observed a paradigm shift occurring. “A few years ago when you got a phone it had a phone on it and maybe voicemail. Now the phone part is one-third or less of the functions and maybe holds less value because consumers desire to get iPads and smart phones. It used to be that the system designer would put as much functionality in [the device] as possible and it would take up all the power of the available CPU. Now we can give them more powerful CPUs, but the problem is if they used it their battery would last 15 minutes and that’s totally unacceptable–nobody is going to buy the iPhone if the battery only lasts 15 minutes.”

He noted that system designers such as Samsung and Apple now have to think of what feature set can be delivered with a certain battery size and energy budget. “So they are challenging us to give them the energy efficiency with good performance (meaning megahertz and delivered numbers of instruction), but they don’t want the bleeding edge because then they’ve got the 15-minute battery problem. They want something that’s good performance, but energy efficiency is actually the most important thing—more so than performance.”