By Ed Sperling
Low-Power Engineering sat down with Naveed Sherwani, CEO of Open-Silicon; Amit Rohatgi, principal mobile architect at MIPS; Grant Martin, chief scientist at Tensilica; Bill Neifert, CTO at Carbon Design Systems; and Kevin McDermott, director of market development for ARM’s System Design Division. What follows are excerpts of that conversation.

LPE: How does cloud computing change the need for multicore and many-core processors?
Sherwani: Cloud architectures will evolve differently from mobile architectures. They will be homogeneous 8-, 16- and 32-core architectures. They knows a lot about what you are storing. You can put a lot of intelligence into what you’re storing, which is not the case in a mobile device.

LPE: So what does that mean for the mobile devices taking advantage of it?
Sherwani: It can certainly make mobile devices more efficient. You can store a lot more on the mobile devices. You can do a lot of streaming.
Martin: The application cloud interaction may change in character. People will write somewhat different apps in the future that will take advantage of what the cloud has to offer. This is why you’ll see cobwebs on the desktop in the future because no one is very interested in it anymore.
Sherwani: And if you look at video, with the cloud and a good wireless connection you don’t have to store the video. Video cameras will become a lot less expensive.
McDermott: This should be put into context. It’s amazing that people are so excited about a database. That’s all it is. I believe the vision for the mobile device is that you have access to all the data, and you selectively choose how to expose it. The browsing experience is different. You don’t try to replicate the desktop experience on a smaller screen. It’s a given. You take the appropriate content and you display it in a way that’s easiest to digest. I think the hardware on the mobile device will become smart enough to selectively show you the piece that you need on your mobile device. You don’t need an entire map. You just need to know where you are.

LPE: What’s interesting about databases, though, is that they’re one of the very few applications that really can do true parallel processing and scale effectively.
Sherwani: I’ve been saying for the last two years that we should stop giving people content. In five years all the content will be available. If you’re a mechanical engineer, everything you need will be on the Web. What we need to do, though, is teach people how to do something useful. This is the same thing with mobile devices. Whatever device will be useful will be the one that can quickly filter through what you’re looking for to get something done. It’s not about storing more information. Cloud brings that opportunity to people, devices and things. Our view of expertise will change. It won’t matter if you’re an electrical engineer. It’s whether you can get a task or series of tasks done. That will be more important than a Ph.D. We are 10 years from that, but this is how people of the next generation will think.

LPE: What you’re talking about is data mining for the masses?
Sherwani: Yes.
Martin: Before we get too carried away, there are a couple of issues that really need to be solved in this cloud paradigm. We do need to think a lot about privacy, security, and the ability of the infrastructure—both wired and wireless—to deliver all of this content off the cloud and onto the sea of mobile devices. We all know about the experiences of certain smart phones overloading networks and they’re still trying to improve the quality of the network. The wired infrastructure is not fault free. Security and privacy worry me more. If you upload all your data into some big infrastructure, you want your data secured.
Rohatgi: That’s the weakest link. Everybody’s pushing down this path. What worries me is the security and reliability. There are a ton of issues that need to be resolved. Creating a smart infrastructure for data mining can be done today. On the mobile side, there are probably some advances necessary to improve battery life, which is the No. 1 complaint I hear today. But the weakest links we hit are the communications channel, security, privacy and reliability. If those can be resolved then we can progress.
Martin: The technologies we’re all involved with are going to help in a big way. It just requires a bit of mobilization to focus on those issues.
McDermott: This reminds me of where we were with cell phones years ago when the processor went through certification with the carrier. The consumer doesn’t see all the certification on the network. The carrier loves new features. It’s more traffic for their store. It brings in a new wave of users. What they don’t want to see is something that disrupts their infrastructure. For the engineer, the certification is really intense and the field trials are difficult. The cell phone industry has to show a partition that you can certify your baseband and your protocol stack and that has to be isolated from other activity. That underlying security infrastructure is built into the certification. I think we’ll see that extended upward through commercial transactions to having trusted processes and transactions.

LPE: Will cores all be homogeneous or heterogeneous, and will some of them be virtualized?
Sherwani: All of the above. There will be homogeneous cores, heterogeneous cores and there will be virtualization. They all solve different problems. You need virtualization in data centers.

LPE: But will you need virtualization on your smart phone?
Rohatgi: We’re starting to see some of that. I don’t think the operating system wars are dead. And at the end of the day, there is some value to keeping RTOS access to legacy hardware and a high-level operating system like Android or Windows or IOS. From a security angle, it all depends on the use case. The mobile guys are really scared of virtualization of a single processor that has access to all memory. They want separate memory and separate everything.

LPE: This is similar to devices that have a partition between what’s used at home and at the office, right?
Rohatgi: Yes. It’s the same problem. And this almost ties into virtualization. On the privacy side, there isn’t a well-defined security layer with NFC (Near Field Communications Forum) and they’re talking about mobile payments. If you power on an Android phone and shut off all networking then your maps go haywire. Why? Because there’s a back channel that goes to some cloud that helps triangulate where you are. That information is stored to help applications of the future. I’m surprised people aren’t bothered by this. But to return to the question, we’re starting to see some effort down the path of virtualization even though it’s not widespread yet.
Martin: You won’t see virtualization down to the metal. In the dataplane layers it’s nice that processors can emulate other processors effectively, but close to the metal you want extreme efficiency and high performance.
Neifert: And that’s where I see the problem with virtualization. It’s the power. Virtualization is nice, but it’s an abstraction away, which is a power loss. At that point you need heterogeneous processing.
Rohatgi: Transmeta, about nine years ago when they started doing abstractions to hardware, had power numbers that were way down. It’s too bad that green energy wasn’t something that was important then. Still, the genesis of the Atom processor was entirely because of Transmeta..
Sherwani: A typical Bluetooth radio takes about 32 milliwatts of active power. At 65nm we have a Bluetooth radio that only uses 3.2 milliwatts. And there is a design on the board that will take it below 1 milliwatt. There are a bunch of engineers getting excited because over the last 100 years the basic design of a radio has not changed. What Marconi designed is essentially the same as we have today. But when you scale down the power needs to go down. It’s amazing how much lower you can go.
Rohatgi: There’s the other side of this, too. Battery technology has not evolved as much as we would like. For the analog components, it’s the switching characteristics that are governing it. That’s where you’re seeing a lot more intelligence. If you were to look at the power profiles of a mobile device, LEDs and LCDs were supposed to be the promise for low power. That hasn’t worked out. There are still 250 milliwatt drivers. The radio is probably No. 2 on the list after that.
McDermott: People’s expectations were that a screen would be a certain pixel density. Today that needs to be super high-definition. It’s beyond high-def.

LPE: So will we see more cores in the future or have we maxed out?
McDermott: As a programmer, how are you going to keep track of 100 cores? How are you going to program that intelligently? Either it’s going to be some array a programmer can visualize, or it’s going to be three or four very solid cores and let other cores do things like Bluetooth. You can’t keep 100 threads in your mind.
Rohatgi: There’s a limit to this. If you look at the desktop space, in 2006 when Intel began heading out on this multicore approach they found that success wasn’t nearly as fast as they thought. There’s probably a limit on mobile devices, too.
Sherwani: We did all this in the 1980s. nCube used to have a 16-core and 32-core machine. It works great up to 8 cores, but after that you lose it.
Martin: If you are trying to program a concurrent application and split it into different threads, there are inherent limits. Some very specialized applications may be very concurrent, but most are not.
Neifert: The programming model has a human in the center, and humans can only process so much. Until the fundamental programming model changes, you won’t see much advancement.

By Ed Sperling
For years, semiconductors have been getting more efficient. Desktop computers that used to peak out at 250 watts are now down to the 30- to 60-watt range. But set-top boxes, those inconspicuous little boxes that connect televisions to services provided by cable companies can consume even more.

The problem has become bad enough that the National Resources Defense Council issued a report last month saying digital video recorders, cable and other pay-TV boxes were costing U.S. consumers $3 billion a year.

So what went wrong? The answer actually has nothing to do with the semiconductors inside the boxes. It’s the back-end systems from the companies that offer pay-TV services—the use model into which chip designers had no visibility.

“The problem is that the MSO (multi-system operator) is querying the boxes regularly, which means they’re also spinning up the hard drives,” said Paolo Masini, principal architect for digital home at MIPS. “Over the long term, this problem will go away because functionality will be absorbed into the residential gateway. But in the short-term—meaning over the next few years—there will be a move of all these services into the cloud. That will offer huge power savings.”

How much savings? The starting target is 70%, and that’s the easy stuff. Add in more power-saving features and it can go significantly higher.

“There is a lot of synergy here with gaming consoles, too,” said Masini. “The companies making these devices have introduced reduced power versions, but they’re only slightly better. They’re now getting a lot of pressure to decrease their energy consumption, as well. The blocks and peripherals on set-top boxes and gaming systems are similar, and they use similar chips.”

Several companies compete in the set-top box chip market. MIPS is the current market leader, but ARM is competing with similar performance and power credentials. Intel has made some inroads, as well, but its primary focus is CPU and graphics performance rather than efficiency.

By John Blyler
It’s no secret that today’s market favors electronic products that use less power while providing ever-greater feature sets at higher levels of performance. These conflicting requirements have caused many embedded hardware and software developers to consider competing processor architectures for their next design iterations.

Architecture migrations are tricky because they involve taking software designed to run on one computer hardware and porting that software to execute on a totally different system. Migrating software to run on a new processing platform can be risky and time consuming. Many factors must be considered, such as the choice of an operating system (OS). Common concerns center on the best way to optimize both power and performance during the migration. Among other issues are the available tools for debugging in the new environment.

These questions and many others are addressed in a new book by Lori M. Matassa and Max Domeika, which was published by Intel Press. Titled “Break Away with Intel ATOM: A Guide to Architecture Migration,” the book obviously focuses on migration strategies from competing platforms to Intel’s embedded ATOM processors. Still, an interview with one of the authors reveals a variety of useful development tips that apply to architectural migration in general.

LPE: What motivated you to write a book on migration strategies?
Domeika: Lori and I saw a need to help embedded software developers and engineers migrate to the Intel Atom. Over the last several years, our customers have asked many questions about the details of things that they need to know to be successful in the migration. Lori and I wanted to document all of these questions and answers in one place to benefit a broad spectrum of people—from managers considering migration to the engineers that have to do the work.

LPE: Which competing processor platforms are covered in the book? Also, will the migration be to a single-core Atom or the new double-core version?
Domeika: We primarily cover migration strategies from the two big architectures of PowerPC and ARM. Many customers have experience on these embedded architectures, but now want to explore a move over to the Atom processor. Some developers want to know the low-level architecture details, such as the special features of x86 assembly language. Other details we cover include the pros and cons of an in-order processor instead of an out-of-order processor like our other, bigger processors.

Many questions center on the issue of porting existing software to a new platform. One common issue that we see from customers deals with byte order. How do you migrate from a larger processor architecture like PowerPC to a smaller one like the x86? The multicore question is a challenging one. Once the software is migrated to the Atom processor, it’s easier to take advantage of new multicore platforms. In general, embedded developers are still learning the advantages of multicore systems. One of the challenges is that no one roadmap exists for customers in the multicore space. We still have customers who are struggling with the same multicore issues that we were talking about two to three years ago.

LPE: The cover of the book has pictures of tablets, nettops, and smartphones. Do these different development targets have different migration strategies? Or are the differences minimal—confined to hardware-specific issues like display screen resolution and memory?
Domeika: Every migration has both common and unique aspects, which made writing the book a hard task. You don’t want to be so specific that you have things that only apply to one person. On the other hand, you don’t want to be so general that it applies to nobody. Lori and I have done our best to try to generalize and discuss the key topic areas. As I mentioned, some folks want to know about the low-level details. But many don’t need the low-level details. These developers don’t need to know the details of assembly language or the Atom architecture, especially if they’re application developers coding in a higher-level language like C++.

OS issues are common to most customers. Some use commercial-off-the-shelf (COTS) OSes that make certain tasks easier but other tasks harder. Other folks are bound by a proprietary OS that they need to port. Proprietary OSes bring in other system-level and assembly-language issues in terms of device drivers. So it really depends. We try to be general enough to suit the needs of many folks, but provide enough detail that it’s of some value.

LPE: Let’s talk about available migration tools.
Domeika: Historically, Intel’s tool focus has been on best performance (i.e., trying to get the most optimized performance). Our compiler engineers sit closely with the Atom architectures, so we’re able to design compilers that know the Atom internals and create very fast code. Similarly, our profiling tools are tuned to watch for events that have more or less impact on the processor. One of the big embedded tool areas is power optimization. How do you optimize the processor for power? There are tools available now and some coming out later. One of the currently available, common open-source tools is called PowerTop.

There were many demonstrations at the last Embedded Systems Conference (ESC) that relied on external electrical devices to measure power. These devices had external probes that would monitor the power on a chip or board. PowerTop is different. It’s a software tool that monitors the idle states of a processor—specifically, the C and P states—while the software is running. Idle processors use less power. PowerTop monitors the processor as it is transitioning between its C and P states. Knowing the transition timing allows the designer to figure out what part of the software is causing the processor to wake up. Too many interrupts may increase the system’s power consumption. The software developer can use this information to determine if all of those interrupts are actually needed. Perhaps fewer processor interrupts can be used. Sometimes, the solution is silly things, like insistent polling of the processor by an application. One solution may be changing the polling behavior or even moving to a different processing architecture.

LPE: How about chip power-management systems that are based on real-time operating-system (RTOS) software control (e.g., turning off specific sections of the chip as needed)?
Domeika: Those low-power techniques are certainly useful. However, my focus has been on the software-development side. Many developers don’t want to go to a deep level of detail. This has been an eye opener for me—a realization that has caused me to think in a new way.

While there are ways to micromanage the chip’s power usage, it’s usually more efficient to simply let the chip manage the power at that level of detail. A great many power decisions are controlled by the processor. We’ve found that application developers don’t have a big desire to manually tell the processor which sleep state to enter or when to wake up. Their interest is at a higher level, such as deciding how often to interrupt the processor.

This is analogous to threading issues in multicore processing. Multicore threading is considered the assembly language of multicore programming. Here too, questions arise as to whether it’s better to have libraries that address most levels of power and performance issues, so developers can focus exclusively on their software applications. Not surprisingly, mainstream developers want things to be easier.

LPE: Are there any third-party tools that can be used for multicore design?
Domeika: The book also covers some third-party tools. One such tool is called Prism by CriticalBlue. This tool supports multicore programming on embedded processors by allowing users to play “what-if” performance scenarios. For example, what if you were able to make a section of the code run in parallel? How much faster would the code run across four codes? What are some of the potential issues that you’d have to worry about if you’re going to make something run in parallel? Common issues include the use of shared variables and parallelism, concurrency concerns, and ensuring that the code runs correctly.

By Ed Sperling
In the past it was all about clock frequency. People bought the latest computer and frequently paid a premium because it could crunch numbers faster. But as computing moves from the desktop into handheld devices, that focus is radically changing.

Low-Power Engineering caught up with Mark Bohr, senior fellow and director of Intel’s process architecture and integration, to talk about this shift and what needs to be solved in the future.

LPE: How much of a performance gain and an energy reduction do you get using Tri-Gate?
Bohr: In the low-voltage range, which is around 0.7 volts, we’re achieving about a 37% speed-up. Or conversely, another benchmark is power savings. If we benchmark these against our 32nm planar devices using Tri-Gate, we reduce active power by about 50%.

LPE: Is there any advantage in dropping the voltage lower than 0.7 volts?
Bohr: Yes, that is the name of the game now—to provide the lowest possible active power. Reducing operating voltage is a way of doing that. When I use 0.7 volts as the benchmark, that does not imply it’s the lowest voltage we can use.

LPE: What’s the foreseeable limit in terms of how low you can drop the operating voltage?
Bohr: That’s an important question for both process technology and circuit design. There’s no simple answer, but we are pushing that from both sides. On the transistor process side we are trying to make them usable from the lowest operating voltage. We also are bringing in some circuit design tricks to better enable low-voltage operation.

LPE: What are the challenges with that?
Bohr: There are two factors that you limit you as you try to drive operating voltage lower. One is for state retention on memory elements, like a static RAM cell. The other is performance and how controllable the performance is at a low voltage level. You have to fight both as you push voltage lower.

LPE: We’ve evolved into a society of impatient people, but is the concern now performance or plugging in your mobile device every night?
Bohr: My impression is that a lot of delays we see are not so much dependent on the speed of the processor but the bandwidth to memory.

LPE: We’ve been struggling with bottlenecks for decades, whether it’s I/O or memory. What’s changed?
Bohr: It’s not so much a microprocessor chip that operates at a higher frequency, but one that provides the performance level we expect on our desktop computers but in our hand. That’s where the power reduction is important.

LPE: It’s interesting how much power is now dominates Intel’s focus. What’s changed?
Bohr: It’s what the market wants. The market isn’t beating down our door for a 5GHz processor, even in a desktop solution. The fan noise is not going to be pleasant. People want high performance in their hand with long battery life.

By Ed Sperling

Portability Play
Synopsys is working with GlobalFoundries to deliver interoperable process design kits later this year at advanced nodes. iPDKs are particularly important for companies looking to use designs for multiple markets. A general-purpose process, for example, is critical for markets looking for higher performance, while low-power processes are important in applications where battery life is a differentiating factor.

The problem is that many of these designs are not always portable between processes, despite the fact that power and performance are considered tradeoffs in most designs.

The companies said the 65nm G and enhanced low power (LPe) kits are available now. Versions for other process nodes will be available later this year.

Stacked die demo
Imec, the Belgian research organization, demonstrated a stacked die with DRAM on logic at Semicon this week. The chip is a prototype of what is expected to become a mainstream approach as companies seek to re-use existing analog IP and subsystems from previous nodes, as well as to add flexibility and speed to complex designs.

What’s particularly interesting about the prototype is Imec’s description of how heat can be removed from the die. Logic generates a fair amount of heat, but the DRAM die acts as a conductor for some of that heat. Qualcomm observed similar effects in its own stacking research last year.

Imec’s work was done in conjunction with GlobalFoundries, Intel, Micron, Samsung, TSMC, Fujitsu, Sony, Amkor and Qualcomm.

By Ed Sperling

Faster throughput, but what about power?
The bottleneck in devices is always about throughput. In the mainframe days it was data read/write and retrieve speed on the enormous spinning magnetic disk platters, with all sorts of tricks ranging from faster rotation to striping across multiple disks. In the PC era it was about faster bus architectures and a chip’s ability to get data in and out of memory and/or storage.

Fast forward to the present and it’s about the ability to get data in and out of a device through a variety of I/O ports—mostly on a single chip but in the future potentially between chips using Wide I/O. The latest entry into this camp is Thunderbolt, which has a transfer rate of 10 Gbits/sec vs. 5 Gbits/sec for USB 3.0, the emerging standard. That’s pretty fast. It’s also pretty expensive, as in $50 for a cable that just hit the market.

So far, it appears that only Apple is selling these Thunderbolt cables. The technology was developed at Intel Labs, and Apple is pushing it as a slick differentiator for data-intensive applications such as video editing. According to Intel, Thunderbolt will transfer a full-length HD movie in less than 30 seconds and back up one year of continuous MP3 playback in less than 10 minutes.

What’s interesting is that it also can reduce the amount of power needed to drive these devices because it takes less time. Time is money in computing and in I/O, providing you can run the processor and the I/O at a low enough voltage. So far there’s no talk about the power savings, though, because no one wants to mention which computers and devices are actually going to use this transfer rate. But it should raise lots of questions beyond just the cost of the cable.

Atomic switches
The University of Southampton in the U.K., the Japanese National Institute for Materials Science and Hitachi are jointly developing a low-power logic system with instant on/off logic operations. The goal of the three-year research project is to build non-volatile logic systems based on “three-terminal atom transistors hybridized with nano-MEMS switches.

The university says the technology initially will become available as an integrated logic-memory chip for portable devices, and that ultimately the memory retention capacity will allow computers and mobile phones to shrink both in size and weight.

The big question is whether you’ll still have to plug it in every night.

By Ed Sperling

Rugged Low Power
A new notebook computer has hit the market, featuring low power and high resistance—as in resistance to shelling, armed assaults, and the kinds of things you never want to encounter. It’s made by General Dynamics, the military contractor.

The device uses a 5.6-inch screen, an Intel Ultra Low Voltage Core Solo processor, includes a GPS, and it weighs just 2.4 pounds. That’s less than most notebooks—the MacBook Air, in comparison, is 2.3 pounds for the 11-inch model. But unlike the Air, this one you can probably throw at your enemy in hand-to-hand combat and it will still work—at least for six hours, which is how long the battery lasts. The base model starts at $4,900.

One particularly nice feature is that you can read the screen in bright sunlight, which you don’t find in most portable devices. It even has WiFi and Bluetooth.

Superpower
The bragging rights for the processors that run the world’s fastest computers has always been about performance and scalability. This is one of the reasons Nvidia has done so well in this arena—graphics processors lend themselves nicely to sharing tasks for relatively low cost.

Intel’s newest approach brings in another element, though—power. The company says that the Chinese Tianhe-1A supercomputer would require 1.6GW of electricity to achieve the same amount of power as the new Many Integrated Core architecture using Tri-Gate 3D transistors. That’s about enough electricity to power 2 million homes, according to Intel’s calculations.

Exactly how much the power can be reduced in similar computers using 3D structures is unknown, but we’re about to find out when Intel starts turning out these chips over the next few months. There may not be any additional supercomputers, but you probably won’t notice them as much—providing you can screen out all the marketing noise that’s about to follow.

By John Blyler
It is no secret that today’s market favors electronic products that use less power while providing ever greater feature sets at higher levels of performance. These conflicting requirements have caused many embedded hardware and software developers to consider competing processor architectures for their next design iteration. Architecture migrations are tricky since they involve taking software designed to run on one computer hardware and porting the same software to execute on a totally different system.

Migrating software to run on a new processing platform can be risky and time consuming. Many factors must be considered, such as the choice of an operating system. Common concerns center on the best way to optimize both power and performance during the migration. Other issues deal with available tools for debugging in the new environment.

These questions and many others are addressed by a new book by Lori M. Matassa and Max Domeika published by Intel Press. The book is titled “Break Away with Intel ATOM: A Guide to Architecture Migration.” The book obviously focuses on migration strategies from competing platforms to Intel’s embedded ATOM processors. Still, an interview with one of the author’s reveals a variety of useful development tips that apply to architectural migration in general.

LPE: What motivated you to write a book on migration strategies?
Domeika: Lori and I saw a need to help embedded software developers and engineers migrate to the Intel Atom. Over the last several years, our customers have asked many questions about the details of things they need to know to be successful in the migration. Lori and I wanted to document all of these questions and answers in one place to benefit a broad spectrum of people, from managers considering migration to the engineers that have to do the work.

LPE: Which competing processor platforms are covered in the book? Also, will the migration be to a single core Atom or the new double-core version.
Domeika: We primarily cover migration strategies from the two big architectures of PowerPC and Arm. Many customers have experience on these embedded architectures but now want to explore of move over to the Atom processor. Some developers want to know the low-level architecture details, such as the special features of x86 assembly language. Other details we cover include the pros and cons of an in-order processor instead of an out-of-order processor like our other, bigger processors. Many questions center around the issue of porting existing software to a new platform. One common issue that we seen from customers deals with byte order. How do you migrate from a larger processor architecture like to PowerPC to a smaller one like the x86? The multicore question is a challenging one. Once the software is migrated to the Atom processor, it is easier to take advantages of new multicore platforms. In general, embedded developers are still learning the advantages of multicore systems. One of the challenges is that no one roadmap exists for customers in the multicore space. We still have customers who are struggling with the same multicore issues that we were talking about two to three years ago.

LPE: The cover of the book has pictures of tablets, nettops and smartphones. Do these different development targets have different migration strategies? Or are the differences minimal, confined to hardware-specific issues like display screen resolution and memory?
Domeika: Every migration has both common and unique aspects, which made writing the book a hard task. You don’t want to be so specific that you have things that only apply to one person. On the other hand, you don’t want to be so general that it applies to nobody. Lori and I have done our best to try to generalize and discuss the key topic areas. As I mentioned, some folks want to know about the low-level details. But many don’t need the low-level details. These developers don’t need to know the details of assembly language or Atom architecture, especially if they are application developers coding in a higher level language like C++.

Operating system (OS) issues are common to most customers. Some use commercial off the shelf OSes that make certain tasks easier but other tasks harder. Other folks are bound by a proprietary OS that they need to port. Proprietary OSes bring in other system level and assembly language issues in terms of device drivers. So it really depends. We try to be general enough to suit the needs of many folks, but provide enough detail that it is of some value.

LPE: Let’s talk about available migration tools.
Domeika: Historically, Intel’s tool focus has been on best performance, i.e., trying to get the most optimized performance. Our compiler engineers sit closely with the Atom architectures so we are able to design compilers that know the Atom internals and create very fast code. Similarly, our profiling tools are tuned to watch for events that have more or less impact on the processor. One of the big embedded tool areas is power optimization. How do you optimize the processor for power? There are tools available now and some coming out later. One of the currently available, common open source tools is called PowerTop.

There were many demonstrations at the last Embedded Systems Conference (ESC) that relied on external electrical devices to measure power. These devices had external probes that would monitor the power on a chip or board. PowerTop is different. It is a software tool that monitors the idle states of a processor – specifically, the C and P states – while the software is running. Idle processors use less power. PowerTop monitors the processor as it is transitioning between its C states and P states. Knowing the transition timing allows the designer to figure out what part of the software is causing the processor to wake up. Too many interrupts may increase the systems power consumption. The software developer can use this information to determine if all of those interrupts are actually needed. Perhaps fewer processor interrupts can be used. Sometimes, the solution is silly things, like insistent polling of the processor by an application. One solution may be changing the polling behavior or even moving to a different processing architecture.

LPE: How about chip power management systems that are based on RTOS software control, e.g., turning off specific sections of the chip as needed?
Domeika: Those low power techniques are certainly useful. However, my focus has been on the software development side. Many developers don’t want to go to a deep level of detail. This has been an eye opener for me, a realization that has caused me to think in a new way.

While there are ways to micromanage the chips power usage, it is usually more efficient to simply let the chip manage the power at that level of detail. A great many power decisions are controlled by the processor. We’ve found that application developers don’t have a big desire to manually tell the processor which sleep state to enter or when to wake up. Their interest is at a higher level, such as deciding how often to interrupt the processor.

This is analogous to threading issues in multicore processing. Multicore threading is considered the assembly language of multicore programming. Here, too, the questions arise as to whether it is better to have libraries that address most level power and performance issues so developers can focus exclusively on their software applications. Not surprisingly, mainstream developers want things to be easier.

LPE: Are there any third party tools that can be used for multicore design?
Domeika: The book also covers some third party tools. One such tool is called Prism, by CriticalBlue. This tool supports multicore programming on embedded processors by allowing users to play “what if” performance scenarios. For example, what if you were able to make a section of the code run in parallel? How much faster would the code run across four codes? What are some of the potential issues that you’d have to worry about if you are going to make something run in parallel? Common issues include the use of shared variables and parallelism, concurrency concerns and ensuring that the code runs correctly.

By Ed Sperling
Low energy consumption with minimal leakage has emerged as the most competitive element in an IC design, regardless of whether it involves a plug, a battery, or whether it’s powered by a gasoline engine.

While components on an SoC aren’t always power-aware, they’ll have to be in the future as consumers focus first on energy efficiency. With rising fuel costs, a concern over global warming and a steady reminder that smart phones have to be plugged in every night, car companies are shifting their strategy from efficient hybrids to even more efficient plug-in hybrids and electric vehicles, and California has gone so far as to mandate that one-third of all electricity sold in the state by the end of 2020 must come from renewable sources.

This shift in public awareness hasn’t been lost on the chip industry, which has been rolling out some very complex advances well ahead of schedule. Here are some of the most important:

Clouds
The push toward a cloud-based infrastructure is a way of centralizing computing—basically a return to the time-sharing model once perfected by the mainframe and then re-distributed with the advent of the commodity PC server. The data processing world is re-aggregating, but this time with a difference. It’s not just that the computing is being centralized. It’s that the centralization is taking place in proximity of cheap power sources such as hydroelectric power, nuclear plants (for now) and wind farms.

“Cloud leads to big efficiency gains,” said Chris Rowen, chief technology officer at Tensilica. “Now you can put the computing farm where the energy is available. It’s an arbitrage opportunity. It’s not hard to ship bits when you compare that to the difficulty in transporting electricity.”

There’s a clear business case to be made on this front. An estimated 6.5% of electricity is lost in transmission, according to the U.S. Energy Information Administration. That may not seem like a lot until you consider those are high-voltage transmission lines. Bits are cheap, in comparison—even trillions of them—which is why there is talk now of centralizing portions of even base stations. Those parts that do intensive computation with a high degree of redundancy are prime candidates for being located in a data center.

“There’s a lot of computation needed to reduce noise and create a clean signal,” said Rowen. “But there’s also some computing that has to be done locally because there are tough latency requirements.”

Adaptive Body Biasing
Adaptive body biasing has been under serious discussion for the past five years as a way of reducing current leakage by controlling a device’s body voltage, which in turn increases the voltage threshold. The big advantage here is less switching to the off state. The downside is this is has been difficult stuff to design and manufacture.

“This was not seen as a mainstream approach, but now it’s showing up almost everywhere,” said Aveek Sarkar, vice president of product engineering and support at Apache Design Solutions. “This was seen as a challenging technique to implement, but now TI and Samsung are using it. If you change the body bias voltage, you impact the threshold voltage. You can increase or decrease leakage, as needed, and boost performance.”

Consultant Bhanu Kapoor, president of Mimasic, noted that for some high-performance applications the alternatives such as power gating may be impractical because it simply takes too long to turn on and off sections of a chip. In those cases, body biasing is the only choice.

Atomic-Level Changes
Another technique that has been particularly difficult to master is atomic-level control of channel doping on the manufacturing side. And while most experts don’t expect the process and manufacturing side to offer any huge gains, this one may be the exception.

Scott Thompson, chief technology officer at startup SuVolta, said that by improving the doping technique, both dynamic and static current leakage can be reduced with regular bulk CMOS.

“The problem is that the wall around the channel is leaky and it’s hard to control the shape,” said Thompson. “Strain engineering helps to control the atomic-level analysis. But there has been no other breakthrough other than changing the transistor, and we don’t see a need for that for all architectures.”

At its unveiling last week, SuVolta had lined up support from Fujitsu, Cypress, ARM and Broadcom. The company claims the technology is an alternative to FinFETs, which are more difficult to manufacture.

3D Transistors And Packaging
Nevertheless, the major foundries have committed to building FinFETs at advanced nodes. Intel’s announcement of a Tri-Gate three-dimensional transistor at 22nm has been a major topic in the semiconductor industry. The question is now that Intel has publicly committed to the technology, can it really be manufactured with sufficient yield? And can it be built effectively using the disaggregated foundry model in the near future?

These kinds of questions will remain unanswered at least for the next couple years. TSMC is planning to use FinFETs at 14nm, and GlobalFoundries has been working on the same technology. Nevertheless, the big advantage of FinFET technology is a sharp reduction in leakage while providing a significant performance boost.’

Creating stacks of die also has a huge effect on power, in part because the distances between logic and memory can be shortened significantly. A system-in-package version of stacked die, using interposer technology, is expected to begin widespread production over the next 12 to 18 months, bolstered by the new Wide I/O standard that increases the size of the pipes between logic and memory.

New Materials
Fully depleted SOI, silicon on sapphire, as well as new ways of putting them all together in stacks connected by low-cost interposers that can be made of glass have turned into major research efforts as companies seek to knock costs out of the bill of materials for new chips.

While the FD SOI has been well tested for years by the Common Platform participants, the others have only been used on a very limited basis. One approach now being considered is actually designing chips to run hotter rather than trying to keep the power down. While there are limits to this approach—no one wants to pick up a hot phone—there are times when performance is more important than heat.

Taken as a whole, all of these changes can have a significant reduction in power, particularly when coupled with efficient software code and more customized user controls—and end devices that actually use the power-saving technology that is being built into these chips.

By Ed Sperling

Going Vertical
Now that everyone has gotten the energy-efficiency message down pretty well, the next step is to apply that to specific markets. That’s beginning to happen, too.

A leaked product roadmap from AMD shows machines with all-day battery life and a focus on everything from ultra-mobile notebooks to tablets.

Intel is refining its own message to go after specific markets, as well. The company has created a small-business cloud platform on a pay-as-you-go basis. Given the amount of energy consumed by underutilized servers, this is a huge efficiency play—as well as a way of Intel sidestepping the PC OEM for its share of the profits. 98

Companies such as Tensilica, meanwhile, have been focused heavily on low-power communications, most recently in the LTE and LTE Advanced space. And ARM and MIPS have been divvying up targeting a variety of specific markets. ARM has been focused on mobile devices and a slew of vertical applications ranging from medical devices to other consumer electronics is well documented. Likewise, MIPS has focused on set-top boxes and Android-based devices.

Lowering Carbon Dioxide
The International Energy Agency issued a report today that carbon dioxide emissions must be eliminated from electricity generation to limit the rise of global temperature to 2 degrees Celsius.

The report noted that total output of electricity and heat grew 55% between 1990 and 2008, but corresponding CO2 emissions grew 64.5% in the same period. The report recommends greater efficiency in lighting, heating, cooling and information technology, and powering with renewable sources of energy, nuclear, and carbon capture and storage.

This is good news for the electronics industry, in general, and the low-power engineering portion in particular.