Intel Unveils Moorestown and the Atom Z600, The Fastest Smartphone Platform?
by Anand Lal Shimpi on May 4, 2010 11:54 PM EST- Posted in
- Smartphones
- Intel
- Atom
- Mobile
- SoCs
Clock Speeds: 1.2GHz - 1.5GHz for Smartphones, 1.9GHz for Tablets
Intel isn't announcing individual Atom Z600 SKUs just yet, but we do know that all versions of the chip will support Hyper Threading (likely due to maintain a performance advantage compared to upcoming dual-core ARM offerings). There will be two versions of the Atom Z600 chips, one for smartphones and one for tablets.
The smartphone SKUs will run between 1.2GHz and 1.5GHz, while the tablet version of the Z600 will run at up to 1.9GHz.
Power Management: Clock Down or Turbo Up
Eleven years ago Intel demoed a technology it called Geyserville for mobile CPUs. The technology simply ran the CPU at a lower frequency when running on battery power and a higher frequency when plugged in. Intel eventually called this SpeedStep.
Four years later we got EIST, Enhanced Intel SpeedStep Technology. This allowed a mobile (and eventually desktop) CPU to run at any frequency depending on the performance demanded by the OS and the running applications.
On today’s Atom processors this usually means the chip will run as low as 600MHz when idle and at 133MHz increments all the way up to 1.66GHz under load. You don’t normally drop below 600MHz because that falls into the inefficient range of CPU performance scaling for a netbook/nettop. In a smartphone though, the majority of time your CPU isn’t being used. The SoC and accessory processors have enough custom logic offload a lot, even when your phone isn’t idle.
Lincroft, or the Atom Z600 series, supports even lower frequency modes. The CPU can clock itself down well below 600MHz.
When you need performance however Lincroft has something similar to Turbo Boost on Intel’s desktop CPUs. On the Atom Z600 series it’s called Burst Mode and unlike Turbo, it is more tightly integrated with the OS.
EIST and other dynamic clocking technologies rely on OS P-states to determine what frequency the chip should run at. If an OS requests P0, the CPU simply runs at its highest frequency.
On the Core i5 and i7, if the OS requests the CPU be in P0, then as long as the chip doesn’t violate any current or TDP limitations it will run at a higher turbo frequency instead of the default maximum clock speed the OS is requesting. P0 will always return the highest possible frequency given the thermal conditions of the chip.
The Atom Z600 doesn’t work like this. All potential burst mode frequencies are enumerated as P-states by the BIOS. An OS with proper support for Moorestown will be able to request any specific clock frequency, even burst frequencies. Loading a web page for example might result in the OS asking for the highest possible burst mode frequency, but while you’re reading the page the OS might request a slower P-state. The chip will run at whatever the OS requests, but it will exit burst mode if the chip’s temperature gets too high.
The FSB speed also scales with clock frequency. Once you reach a certain clock speed threshold, the Atom Z600 will automatically double its FSB frequency to help feed the CPU faster. The goal isn’t just to deliver peak performance, but it’s also to complete tasks faster so that the SoC can return to an idle state as soon as possible. The hurry up and go idle approach to mobile CPU performance has been one of Intel’s basic tenants for well over a decade now. And it does work. This is the reason we’ve generally seen an increase in battery life from each subsequent version of the Centrino platform.
The software management of burst mode puts more emphasis on the OS and platform vendors to properly tune their devices for the best balance of performance/power consumption. You can see why Wind River’s Android platform and Moblin are necessary to get the most out of Moorestown.
Facebook
Twitter
RSS
67 Comments
View All Comments
teohhanhui - Thursday, May 6, 2010 - link
But they'll be showcasing it on their Moblin/Meego which is Linux. Won't shoot themselves in the feet, will they?rahvin - Thursday, May 6, 2010 - link
And if it only runs on Moblin, only with specific kernel versions, uses a binary blob driver and isn't maintained it will be the same story as GMA500 all over again.strikeback03 - Thursday, May 6, 2010 - link
As pointed out, plenty of other Android phones are using the same graphics. And I haven't heard a lot of complaints about lack of drivers for the Droid/N1/etc.elisha.pan - Wednesday, May 5, 2010 - link
GMA500 has nothing with the Intel GMA series, but name. It is exactly the same with PowerVR SGX 535.DanNeely - Wednesday, May 5, 2010 - link
This is the same GPU used in almost every other smart phone on the market, except that it's designed to be clocked up to twice as fast. It's not going to run Crysis *rolls eyes* but it's more than capable of doing everything a smart phone/internet tablet will need to do.ekul - Wednesday, May 5, 2010 - link
exactly. without open source drivers for the graphic any development of meego outside of intel will never go anywhere. One of the reasons I bought my current netbook is the gma 950 has excellent open source drivers that just work.Open source development moves fast. Closed source binaries get left behind because they can't keep up with the release schedule. The current gma 500 drivers already need a kernel several versions old as well as an old X server. How many releases is meego going to miss?
ViRGE - Wednesday, May 5, 2010 - link
I can see why Anand thinks it's an interesting product, but based on his article I don't think Intel is quite there.The current need for 5 chips is going to be a problem no matter how Intel dresses things up, and if all phones end up looking like the design shown I wouldn't be surprised if the consumer reaction was tepid - a phone of that size is still pretty big. The video playback time is also going to be a problem when it comes to spec sheets (I doubt the real-world impact will be as huge), but OEMs like their spec sheets and consumers aren't too far off either. Just looking like it'll perform poorly there may be enough.
The other issue is the reliance on an OS. At this point it seems like no one really wants another OS. Most people around here seemed to be more relieved than concerned when Palm went under. With BlackBerryOS, IPhoneOS, Android, and WinCE, there seems to be as many OSes as the market can reasonably handle. Moblin/MeeGo may be necessary for the hardware right now, but I see no reason to expect that it's going to be properly developed for consumer use like the above OSes were. Unless Intel can land RIM/Apple, they need to get Android up to par on Moorestown and they need to do it yesterday.
Ultimately I think it's going to Medfield that's a proper ARM competitor. With fewer chips it will fit in to traditional designs, and with any luck Intel will be a node ahead of its competition on the manufacturing process. It won't solve the current OS reliance, but it'll put them in a better position than Moorestown does.
ET - Wednesday, May 5, 2010 - link
Ultimately I think that most people don't care about the OS. The OS mainly matters in terms of applications available for it, and it's a pain for developers to address many OS's, but also an opportunity for new developers to carve their niche.That said, Anand did mention that Intel is making Android available for this new platform, which should be good enough.
IntelUser2000 - Wednesday, May 5, 2010 - link
It's much closer than expected. There were quite frequent comments that thought it wouldn't even reach 5 hour on standby! Having a lot of knowledge and doing a bit research helps of course. Glad they can be roughly on par though.It's likely the idle power can't be achieved without optimized OSes. Even if you can run Windows on it, what's the point when you won't have the battery life for it? Windows uses too much on keeping legacy support and its too bloated for idle power under 50mW.
Platform approach is the key to low power on Moorestown.
piroroadkill - Wednesday, May 5, 2010 - link
I'm not sold. ARM has been more efficient for a lot longer, even though it's still being made on commonly larger processes than current Intel CPUs. All smartphones are ARM anyhow, so I don't see the advantage in having x86 in this space