The rationale behind Intel’s new book and why the company has taken its current approach.

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 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
Microsoft is looking for 16-core servers for future data centers using Intel’s Atom and AMD’s upcoming Bobcat processor lines in order to lower power consumption in data centers. The announcement, made at the Linley Data Center Conference in San Jose this week poses an interesting dilemma for Intel and AMD—as well as challenges for ARM and even Microsoft.

On the Intel and AMD front, the big question is how such a shift would impact revenues, given the fact that both companies have used the power-saving lite versions of their processors in much lower-cost devices such as netbooks. While some data centers are experimenting with Atom-based arrays for servers, the real savings have come from virtualization to improve server utilization, and cloud-based strategies to quickly ramp up and ramp down compute capacity as needed.

Virtualization has been extremely successful. Most large companies have adopted it to some extent because it costs money to power and to cool a server, whether it’s utilized at an optimal 60% to 85% or whether it’s running at 5% to 15% utilization, which was the industry average prior to virtualization. The problem for Microsoft was that the virtualization was done using VMware and Citrix software, not Microsoft software.

Without virtualization, it’s not entirely certain whether many applications will be able to natively take advantage of 16 cores, considering most currently don’t use more than one or two. In fact, the main applications that can be effectively parallelized are databases, graphically-oriented applications such as Adobe Photoshop, and highly computational scientific applications, where the biggest threat to Microsoft and Intel is Nvidia.

Microsoft’s approach will likely be a more effective management of virtualized applications across those cores so that cores can be turned on and off as needed, but it’s certainly not the only company that sees that opportunity. Virtualization currently uses all the cores indiscriminately, but much more intelligence is being added into the virtualization and middleware layer to cut energy consumption.

For ARM, that means even greater engagement with both Intel and AMD, where it will have to push lower power while defending its performance and the competitiveness of Linux. Given ARM’s grassroots type of ecosystem marketing, it remains to be seen whether it can rise up to the din of the marketing machines of its new competitors. Lower power consumption is a good story, but in the enterprise so are performance and deep relationships.

The old adage that no one ever got fired for buying IBM can now be applied to Microsoft, Intel, AMD and to a lesser extent VIA. Most IT departments have no history with ARM, except in handheld devices, and IT is one of the most conservative purchasing groups on the planet because the stakes of making a bad decision can be monumental. Breaking into the mobile market takes months. Breaking into the IT world can take years, and sometimes even decades. This isn’t a battle fought on technological merits. It’s like a medieval siege. And while ARM may meet the technology challenge, it remains to be seen whether it can meet the long-term marketing challenge.

In this part of the market, the adage about IBM is still true. IBM’s mainframe sales are up, in part because mainframes are still the most secure and effective virtualization environment. IBM invented virtualization in the 1960s, incidentally. And on its newest machines it’s offering water cooling once—which can further cut power consumption because it costs less to cool.

By John Blyler

Max Domeika, senior software engineer in the Developer Products Division at Intel, sat down with LPE Consulting Editor John Blyler to talk about the growing importance – and intersection – of both the multicore and embedded markets. What follows are excerpts of that conversation.

LPE: Intel’s software focus seems to be following its hardware processor drive into both multicore and embedded markets. What challenges does that bring for traditional software developers?

Max Domeika: Coming from a background in the desktop software application space at Intel I’m now spending more time working in the embedded multicore arena. This year I’ve been particularly focused on power issues, primarily on the Atom processor. My task is to see what sorts of tools are needed to help developers move to both embedded and multicore applications. Already I see a long term need for both power optimization and power measurement tools. The key is to monitor the power-related impacts of your application on the specific and overall system performance.

In the past, desktop clients and server users haven’t had to pay much attention to power. Desktop systems plug into the wall and their software applications use as much power as the processor wants to give them. Over the past several years these processors have incorporated features that help control the amount of power usage in both C (idle) states and P (operational) states.

How do these processor states affect the development of software applications?

In the past, processors either ran at full speed or idle. Several years ago hardware designers added features to the chips to control how deep of a sleep the processors are in. As you know, these features allow different portions of the chip and caches to be turned-off. One of the challenges is that while deep sleep saves more power, it often takes more power to wake up.

For the software developer, this means that you don’t want the application to enter the deepest C-state if you will have to wake up immediately. There needs to be some smarts as to how deep a sleep you go into, which is really an operating system issue. P states, or operational states, utilize varying frequency and voltage to balance the amount of the execution that the OS determines is needed. These states directly affect the performance of the system.

These states can have a big impact on the application, restricting how developers write the code. If your application causes the processor to perform poorly, that will have a negative effect on power utilization. Developer need more mature tools to help figure out which application processes result in effective use of the C-states.

I see a need for continued maturity of the power optimization and power measurement tools and methodologies. These power tools must also be tied to traditional performance analysis and optimization tools, because many of the techniques for mitigating power are the same techniques that you use for traditional performance optimization. The entire system must run as quickly as possible while using as little power as possible.

At the other end of the spectrum are the same issues of power optimization and performance analysis, but applied to a multicore environment. Tools and methodologies need to mature to include multicore development, too.

Are the two worlds of embedded and multicore coming together? After all, Intel’s Atom isn’t yet a multicore architecture, is it?

Well, some instances of the processor already support hyper-threading, a technology that dates back to the Pentium 4 processor. The key here is hyper-threading, which makes the environment look like two (or more) processors from the point of view of the operating system. That’s why the software techniques that developers use on multicore are starting to have an impact on embedded applications targeting the Atom processor.

Isn’t the low power push also affecting the high-end embedded and multicore processors like the Xeon?

Power is important across the board. We’ve seen power optimization become important in servers – especially with the “greening” of data centers.

Let’s talk about the actual tool environment for both power issues and multicore design. What’s happening there?

Today, I’d summarize the tool environment as consisting of a collection of separate tools and techniques. For example, if you want to do power optimization then you might use Power Top – an open source tool for doing power measurement. Conversely, if you want to do performance analysis – to count cache misses, branch mispredictions, memory fetches and the like – using performance monitoring counters, you might use another open source tool called OProfile. Intel also has a tool called the VTune Performance analyzer.

These tools show what performance issues are occurring on the chip, which in turn helps the developers to optimize their code. For example, if you see examples of high cache miss rates, you can investigate to see what portions of the code are causing this problem. This might mean that the data structure of the application needs to be changed to get better cache performance. Performance and power tools give the developer a means of getting valuable feedback from the hardware.

Most desktop application developers are well versed in Microsoft’s Visual Studio IDE. What tools are available for these developers as they move toward multicore applications?

Intel has the Intel Parallel Studio, which integrates well with Microsoft’s Visual Studio for multicore (parallel) code development. Parallel Studio is not targeted at embedded folks, but rather at the desktop client environment. Intel has tools that also help with the programming interface, compiler, libraries and more. With regard to debugging, we have a set of enhancements that integrate into the MS Visual Studio to help with parallel debug.

Debugging is a key issue. While developers could someday spawn 64 threads on a multicore chip – because they have 64 cores – that is not the best way to begin. In multithread implementations it’s best to start with one thread and make sure the program works, then we’ll move up to two and four, etc. Good debugging tools provide easy mechanisms to start debugging one thread then scale to more cores, i.e., they are serially consistent.

Another challenge in multicore development is in the area of configuration control. You may have multiple threads running on multiple cores, but you don’t want multiple version of the same code. Instead, you want one version of the code with a parameter that you can change that will change as your processor cores change. Again, good debugging tools have those configuration control features.

Tools work best when they are following a set methodology. You’re co-chair with David Stewart from CriticalBlue on the Multicore Programming Practices (MPP) Working Group – part of the Multicore Association for which Markus Levy is CEO. Please give the readers a quick update of the MPP.

As you know, our focus is on documenting best-known methods for multicore software development techniques. This year we are in the middle of documenting the best practices. Internal review of this document should begin shortly. We hope to have it ready for external review by the first half of next year.

This document will fulfill a need that is oftentimes overlooked, namely, what are the best practices using the technology that is available today. We have customers that are becoming more and more aware of the challenges of multicore software development. But we are still building awareness and educating the larger group of mainstream programmers. Even when mainstream developers identify the need for a multicore program, they are often stuck with their existing code. Not everyone has the resources, time or need to complete rewrite their legacy code. The MPP document will provide mainstream programmers with a workable set of best practices for multicore development throughout the typical life cycle development process: analysis, design-implementation, debug and the performance tune-up phase.

That’s the big vision. We just have to keep executing. This is all volunteer work, so it’s not something where I can say, ‘Hey, let’s meet this schedule in two weeks. You have to do it.’ Instead, we just have to keep the momentum going. I am pretty pleased with the progress. The feedback from our internal surveys is positive

The goal of your best practices working group is to use existing languages like C/C++ to develop multicore applications. Do you see the need to create new programming languages?

The Multicore Association has other working groups that are developing standards for new software approaches, such as those focused on multicore communications and runtime APIs. The overall plan is to incorporate best-known techniques using those APIs as we move forward. But it’s hard to predetermine the best-known methods before the APIs are available. We won’t know until we get there, but we can’t wait for one to proceed before starting the other.

Intel is working on several technologies both language extensions and new APIs so yes, there is a need for technology; I’m not so sure on new programming languages.  In embedded, C and C++ are going to be with us for sometime, so I’d say there’s probably less need in embedded.

By John Blyler

Intel’s Atom processor appears to be gaining ground in the prototyping world. A new survey by Extension Media asked respondents what embedded processors they were using, and 8% responded with the Atom.

What makes this interesting is that Atom wasn’t readily available last year. Most ASIC prototypes last year relied on the Intel dual-core processor.

By John Blyler

Most engineers would agree that developing products that use less power requires a balance of integrated hardware and software implementation strategies.

The challenges extend beyond just hardware and software issues, especially when you consider domain-specific variables such as increased device intelligence and network connectivity. Low-Power Design sat down with Jonathan Luse, director of marketing for the Low-Power Embedded Products Division of Intel, to talk about these challenges and how they might be resolved.

LPD: Let’s start with the high level, domain-specific trend in embedded, low-power systems. What do you see?

Jonathan Luse: The trend is twofold. First, you have intelligence being added to all kinds of devices. Second, you have the continuing trend of connectivity. By about 2013 or 2015 we expect to see about 15 billion connected devices worldwide—everything from mainframes and servers to cell phones and embedded devices. Some of these embedded devices will be seen, but many will be unseen or in the background.

LPD: Define connected, intelligent devices.

Luse: An easy example is the navigation system in your car, whether it’s integrated into you car or a portable unit. One standard feature of these devices is the capability to connect with traffic monitoring systems. If the navigation device was a bit more intelligent and connected, it could reroute you based upon traffic optimization. That’s just one example of adding connectivity and intelligence to a device. Another example is in the energy delivery mechanisms for power. Alternative energy sources are interesting and will add new forces of power to the grid. But you have a huge infrastructure of existing power generation plants and manufacturing plants that consume electricity. Intelligent low power and connected devices could really help make that entire infrastructure more efficient. Imagine the scenario if each consumer had a smart power meter at their home that could communicate back to the power station. That way, these smart meters could tell both the consumers and power generators how the energy was being spent. Studies have shown that if consumers just knew where they were inefficient in their power usage—regardless of taking any action—they could reduce their electricity bill by 10%.

LPD: Many technology pundits talk about the coming sensor swarm—the increase in the use of sensors in all kinds of connected applications. Such applications would be well suited for a micro-controller architecture rather than a general purpose processor. How do you see the intelligence being distributed in such a system?

Luse: I would see basic intelligence being added at the sensor level too, which might aggregate into a programmable logic controller (PLC), a computer used for automation of electromechanical processes. At the controller level you might need an embedded processor, like the Atom. Depending upon the number of interfaces or inputs/outputs, you might have some physically distributed activities that require a more traditional processor. Then you might have more massive programmable controllers that require a lot of power, so they would go to a dual- or quad-core processor. In fact, a lot of companies that use PLC technology have been using Intel inside their medium and high-end systems for the more intensive processing tasks. But we’ve never given them a 5-watt solution to put into their entry-level PLC applications. Now, with the low power embedded processors like the Atom, they have an entry-level product.

LPD: This is not the first time that Intel has entered the embedded market. What makes this time different?

Luse: Intel has had processors in the mobile, desktop and servers markets for a long time. One example in the embedded space is the xScale, which is a low-power device. The main difference now with the embedded Atom family is that it’s instruction-set compatible with the rest of our embedded roadmap. One thing I’ve heard our customers say is that the xScale is good if it’s used in an isolated application that doesn’t require scalability. But many companies want a good, better, and best strategy. From our perspective, the Atom is the good, the Celeron is the better and the Core-2 Duo is the best for these clients. The benefits that they see are design scalability, architectural scalability and software scalability. They can go top to bottom of their own software stack to include the right features at the right level of product offering and only have to do it once. These customers don’t have to manage multiple architectures, since the Atom and higher processors are all based on Intel’s IA architecture.

LPD: Are these software stacks changing? A lot of legacy software has been remarkably inefficient because it was developed to run on a general-purpose operating system that then runs on a general-purpose processor.

Luse: To answer that question, I need to explain my day job. I’m director of marketing for the Low Power Embedded Products Division, which includes the Atom processors. But in that role, I’m also responsible for the embedded software group. From that perspective, I see that the big trend in the last five to six years has been from proprietary to off-the-shelf systems. Let me explain. When times were good, companies were vertically integrating their stacks, their solution from hardware and hardware-aware Basic Input/Output Systems (BIOSs) to software operating systems and applications. Companies developed it all – homegrown and proprietary. After a while, though, the companies realized that they weren’t getting any real value for the middle portions of the stack – the BIOS, OS and some of the middleware. In addition, these companies understood that a proprietary OS or BIOS wasn’t where their core intellectual property resided, as opposed to an open OS or BIOS. The strength of these particular companies was in the creation of acceleration software that made the existing hardware run faster, e.g., packet processing or a user interface. From this trend I realized that the middle portion of the stack – from silicon to applications – largely moved from proprietary, homegrown OSs and BIOSes to commercial off-the-shelf versions that had become “good enough.” Today, few of these companies use proprietary OSes. Instead, they’ve moved from a completely vertical integrated stack to an off-the-shelf model.

LPD: Your example of the GUI developer or packet processing raises questions about whether we’ll soon see a multicore version of the Atom. You could run your embedded legacy code on one core and the new code – say, a GUI – on the other core.

Luse: Well, I’m not here to launch any new products, but consider Intel’s direction as a company. We’ve gone multicore with everything over time, as a way to extract more performance. The reason is the way that silicon substrates work. If you dial up the last 15% of a processor’s maximum frequency, then you basically double your power consumption. Conversely, if I dial back my frequency by about 15% of the maximum, then the power drops by about half. Further, if I have a second core, then the power decrease almost pays for the second core. Now I’m at 170% performance versus 100% performance for approximately the same power. I’m not trying to tip my hand, but you can see the direction of Intel’s processors. Multicore architectures are a very good way of getting more performance for the same power out, which makes for a very good low-power story.