Intel Smartphone Atom Platform and IP Subsystems

Intel gave an in-depth look at their Moorestown platform aimed at Smartphone designs to selected analysts on Monday the 4th of May. My colleague, Tony Massimini, is dealing with the particulars of Moorestown as a platform in a separate Semico Spin article. My article is going to deal with looking at the Moorestown architecture and its implications for SoC designs going forward.

One of the very interesting features of the Moorestown platform is in how it deals with power consumption in Smartphone applications. Intel is competing with ARM-based SoC solutions in this market and is being measured over several parameters that are important to Smartphone designers – not the least of which is power consumption. Intel has done a very good job in abstracting the X86 architecture and instruction set into its Atom CPU core, which is used in the Moorestown platform. This has also meant reducing the power consumption of an Intel-based processor and chip set. However, Intel is thinking a little bit beyond simple comparisons between one SoC and another to comparing the power consumption figures of one Smartphone platform to another. True, this is being done to put Intel in the most favorable light possible, but the idea does have some merit since consumers do not care about the specs of individual parts but rather about metrics that are meaningful to them like ‘talk time’, ‘standby time’ and total battery life.

An area of possible concern in Intel’s architecture is the fact that according to their diagram of how the power management is being accomplished, commands to the platform to reduce power consumption of the various blocks is being done through directions issued to occur through the OS. A reasonable assumption would be that these commands would be issued by the main CPU, which further entails that some part of the main CPU must be active to issue these commands. This is an acceptable means of controlling these functions, but probably consumes somewhat more power than would otherwise be necessary with an alternative scheme.

(In all fairness, the briefing ran overtime and the Q&A session planned by Intel was not able to happen, so questions requesting more explanation of this part of their architecture were not able to be asked. It is entirely possible that I am misreading the control mechanism employed to manage these functions, but I don’t think so).

Intel spoke about the use of ‘subsystems’ in their platform and that each subsystem contains ‘power islands’ which allows for fine grained power management. If so, then the degree of control possible through this method is considerable and allows for a good level of fine tuning the power consumption based on responses to external events. This is all to the good. However, this also requires a good deal of software to control the different subsystems so that when they are requested to power up or power down, the sequencing of these operations occurs in the proper order to sidestep any possible problems. As the industry is starting to become aware, the cost of software development is now outstripping the cost of designing the silicon itself – with no end in sight. This is not good.

One of the reasons for the escalation in cost of both the silicon and the software to run on the silicon is the fact that we are putting more complexity (both silicon and software) on the design to manage the complexity (mainly silicon) we put there to manage issues like power consumption in the first place.

A more straightforward approach would be to ‘virtualize’ the software functions that are responsible for the ‘power sequencing’ of the different subsystems into IP blocks that would then be attached to each subsystem. This would allow bypassing the main CPU completely, saving the power required to keep the main CPU active until the OS issues the proper commands. Conceptualized the right way, the scheme briefly outlined above could be configured to control each individual IP block within the subsystem itself giving a very high level of control over the activity and power consumption of each IP block in the entire platform. It is likely that as SoCs are designed using the IP subsystem concept in the near future, many will include an IP block manager as outlined in this article. A step forward for the IP industry and the SoC market.

It would not be surprising for Intel to adopt something of this sort when they roll out the next generation Medfield in 2011. Since Intel is already using the subsystem concept to some degree on SoCs like this, along with some other IDMs and OEMs, an evolution along these lines could be expected. At the end of the day it is all about evolution of functionality and competition in the market to employ that functionality in the most efficient manner. Intel seems headed in the right direction to accomplish this.