Intel's Medfield & Atom Z2460 Arrive for Smartphones: It's Finally Here
by Anand Lal Shimpi on January 10, 2012 8:00 PM ESTIt's here. Intel's first smartphone SoC that you'll actually be able to buy in a device before the end of the year. The platform is called Medfield and Paul Otellini just announced its first device partners.
Medfield starts out as a bonafide mobile SoC. Whereas Moorestown was a "two-chip" solution, Medfield is just one - the Penwell SoC:
The SoC is only available in a PoP (Package on Package) configuration measuring 12mm x 12mm. Intel wouldn't give out a die size but it did show me a Penwell sample without the stacked DRAM:
Since I know the measurements of the package I could estimate the dimensions of the silicon itself. My math worked out to be around 62mm^2. That's larger than a Tegra 2-class SoC, but smaller than Tegra 3 or Apple's A5. The diagram of its high level architecture above helps explain why.
There's only a single version of Medfield being announced today: the Intel Atom Z2460. The Z2460 features a single Atom core with a 512KB L2 cache, a PowerVR SGX 540 GPU and a dual-channel LPDDR2 memory interface. In a world where talking about four Cortex A9s and PowerVR SGX 544MP2s isn't uncommon, Medfield starts out almost sounding a bit...tame. But then you see its performance:
Although running what appears to be a stock Gingerbread browser, Intel's Medfield reference platform posts SunSpider performance better than any other smartphone we've tested - including the Galaxy Nexus running Ice Cream Sandwich. Intel promises that Medfield's performance will scale on ICS as well - the gap should be maintained. We've seen high results from reference designs in the past, but the Medfield platform is a little different as you'll soon see - it's a complete smartphone design that should be representative of handsets that hit the market later this year.
Medfield isn't a one trick pony either, performance is similarly dominating under BrowserMark:
These are tablet-like scores. Here the Galaxy Nexus running ICS comes close, but once again Intel expects that on the same OS Medfield should be faster than any of the currently available SoCs.
I asked Intel where its SunSpider and BrowserMark performance advantages came from, especially considering we've typically only seen huge gains with new browsers and not new SoCs. Their response pointed to a bunch of factors, but one stand out issue was the A9 has a great execution core but seems to be more limited on the memory interface. Atom can support far more outstanding misses in L2 than the Cortex A9, which chokes bandwidth to the processor for anything not already in the L2 cache. This may be one of the reasons why we've never been able to get really high bandwidth numbers out of A9 based SoCs. It's probably safe to assume that things will be different with the Cortex A15, but for now it's little things like this that give Medfield a performance advantage.
GPU performance is understandably not as impressive. We couldn't get offscreen numbers of GLBenchmark 2.1 but we did get results at the device's native resolution (1024 x 600):
3D performance is better than the OMAP 4460 due to Medfield's 400MHz GPU clock compared to ~300MHz in most OMAP4 devices.
Performance without power considerations is meaningless, especially in the smartphone world. Luckily for Intel, Medfield seems very competitive there as well. Intel provided some power and performance data for Medfield based on its reference platform. I still haven't been able to verify any of this for myself, but I was able to see some power tests run in person on the reference platform and competitive devices.
The Intel provided values are pretty astonishing . Sub 20mW idle, sub 750mW during a call on 3G and although not pictured here, Intel's internal data suggests ~1W power consumption while browsing the web compared to ~1.3W on the iPhone 4S and Galaxy S 2. I've done my own measurements on 4S web browsing and came up with a very similar value.
| Intel Measured Smartphone Power Consumption (Identical Display Brightness) | ||||||
| Standby (3G) | Talk (3G) | Browsing (3G) | Video Playback 720p | |||
| Apple iPhone 4S | ~38mW | ~800mW | ~1.3W | ~500mW | ||
| Intel Medfield Reference | ~18mW | ~700mW | ~1.0W | ~850mW | ||
| Samsung Galaxy S II | ~19mW | ~675mW | ~1.2W | ~650mW | ||
The performance and power data both look great for Medfield. You would think that this data, assuming there's nothing fundamentally wrong, would be enough to convince a handset maker to actually give Intel a shot. You'd be right.
In addition to disclosing Medfield performance data, Intel is also announcing partnerships with both Motorola and Lenovo. The former is a broad, multi-year agreement stating that Motorola plans on creating many devices based on Intel silicon - the first of which will be a smartphone due out before the end of the year. Tablets will follow at some point as well.
Lenovo on the other hand will actually be taking and tweaking Intel's own Medfield reference platform, and releasing it in China in Q2.
All of this is exactly what Intel needed: a start.
Facebook
Twitter
RSS
164 Comments
View All Comments
french toast - Wednesday, January 18, 2012 - link
I agree with what you are saying, Intel is not competitive in the smartphone space...yet.. but they sure as hell will be within 18 months, this was just about getting a foot in the door..which lets be honest they tried before with moorestown..they even said similar things too, manufacturer tie ups?..remember LG!?But i get the feeling that had this been released mid last year it would have been competitive, but when released this year it will be old news.
I wouldn't take these Intel marketed benchmarks provided by anand too literally, they aren't better than current designs, but with silvermont followed by that steam train like 'tic tock' strategy they will have something to put the wind up ARM shareholders...
Hector2 - Wednesday, January 11, 2012 - link
I think everyone expected Medfield to perform well but the low power is surprising. But not you, eh ? One of those "glass is half empty" kind of guys are you ? Next up for Intel is the next gen 22nm that not only is faster & smaller than 32nm Medfield but has even lower active power and a 10X-20X standby power improvement due to having FinFET transistors. 22nm hits shelves in 2nd quarter for PCs but doesn't get into SoCs until 2013.Exophase - Tuesday, January 10, 2012 - link
Look at the data for the two tests you ran (that aligns perfectly with the only two tests Intel wants to report on, I might add!) - you see that the Galaxy Nexus does drastically better than the Galaxy SII despite having a very similar CPU arrangement. That should be a massive red flag that this test is right now more about software maturity than uarch, yet you use it to draw sweeping conclusions about uarch.These tests are about javascript. Javascript performance, while important, hardly dominates software usage on mobile platforms, nor is it representative of other programs. For one thing, it's JITed code and browser developers have spent a lot more time optimizing for x86 than ARM, while other platforms (GCC, Dalvik) are less slanted. For another thing, Javascript is double-precision float oriented, which isn't even remotely a standard nor useful programming paradigm for everything else that runs on phones.
All I can say is that you need to do some real benchmarks before you make the conclusions you have, and not just parrot the highly skewed selection Intel has given. That is, if you don't want to come off as Intel sponsored.
chuckula - Tuesday, January 10, 2012 - link
Uh... Android (which is what Intel is running) has been optimized for ARM all the way back to version 1.0. To come out now and complain that x86 is getting "unfair" software optimization advantages in its very first release before there has been much opportunity at all to do *any* real optimizations is really stretching things.If ARM wants more optimizations, it can contribute source code updates to GCC (it's open source after all).
Exophase - Tuesday, January 10, 2012 - link
Maybe you don't understand my post. These tests are JAVASCRIPT BENCHMARKS. Android optimization barely plays into it: what we're going to be looking at is Chrome optimization. You know what also doesn't play into it? GCC. The Javascript VM in the browser performs its own compilation, and JITs especially have really long development paths. I guess you missed what I said about the comparison of two different Android platforms, which shows that this is clearly an area where ARM performance is highly in flux and therefore immature and not representative.Regardless of whether or not you understand why this isn't a good test, you should at least understand that running only two benchmarks - two benchmarks that fall under the same category, no less - is a really pitiful way to draw conclusions about uarch. If anyone tried to pull this with an Intel or AMD desktop CPU they'd be immolated.
chuckula - Tuesday, January 10, 2012 - link
You want a wide range of benchmarks between a dual-core Cortex A9 and (older than Medfield) single core Atoms? Go here: http://www.phoronix.com/scan.php?page=article&...The brand-new Omap chip manages to win one real benchmark (C-ray) by 10%, a couple of synthetic cache benchmarks, and loses everything else to single-core Atoms that are actually slower than Medfield.
The benchmarks that Anandtech posted are *extremely* representative of what most people are doing on their phones most of the time. If you want performance numbers for "pure" applications, look at the Phoronix article.
The Dalvik JVM from Google has been optimized to run on ARM from day one. When I mentioned GCC, I was talking about the compiler used to COMPILE the Dalvik JVM (you do know the JVM isn't written in Java, right?). Dalvik is NOT the same JVM that you get from Sun/Oracle that (might) be more optimized for x86 than for ARM. In fact, Dalvik is a register-based VM while J2SE is a stack based VM, and Oracle has sued Google over it since Google lifted the Java interfaces but ditched the rest of the VM. Dalvik was only at beta-level operability with x86 during Honeycomb, and ICS is the first version to really work 100% with x86, but there's no rule saying that there couldn't be more optimizations for x86 based systems.
ARM has had *plenty* of time to work with GCC, Google, and anyone else who is needed to get optimizations introduced into Android. If it takes Intel entering the market to finally spur ARM into action, then I say it's about time this market got some real competition.
mczak - Tuesday, January 10, 2012 - link
I'm not convinced actually those older atoms shown in the phoronix article are really slower than Medfield. I don't think IPC of Medfield is really any higher, and even if it is (slightly) Medfield can only turbo up to 1.6Ghz (so might not run all the time at that frequency potentially) whereas those other atoms all run at 1.6Ghz. Memory bandwidth could also be potentially higher there. Not that it would change things much.Exophase - Tuesday, January 10, 2012 - link
It might have more memory bandwidth than an N270 IF paired with faster than 533MHz DDR2/3.. which I doubt you'll see in a phone. So I expect it to be pretty similar to the Z530's, all told.Clock for clock Medfield's CPU core sounds like it's a little faster due to some tweaks, but it all looks very minor. I'd be surprised if it improved anything by more than a few percent at most.
Exophase - Tuesday, January 10, 2012 - link
Right, now compare those numbers with this:http://openbenchmarking.org/result/1201051-AR-1112...
And this:
http://www.phoronix.com/scan.php?page=article&...
And the only sane conclusion is that Pandaboard ES is or the testing performed on it is critically broken. Now rethink your post.
Try your post again with those things in mind. And don't make me repeat myself any further, Javascript doesn't run on Dalvik, it runs on a Javascript VM. Do you seriously not understand this simple concept? Do you not understand how a purely web based language is not representative of - oh I don't know - apps that are running Java or C/C++ code?
french toast - Wednesday, January 11, 2012 - link
I have to say i am shocked to see those numbers, so much so i do wander about the validity of them as exophase has pointed out, especially since that 'fake' DX11 ivy bridge demo.Regarding the benchmarks, they are single thread right? so in actual fact you are comparing a 1.2ghz cortexa9 v 1.66ghz atom on different software and different process? i suspect that all things being equal the number would be very similar.
I take from the pandaboard tests exactly the same thing, that all clock speeds being equal that clock for clock atom is on par with cortex a9.
BUT that doesnt tell the whole story does it?..multi threaded apps including multiple tabbed web browsing..how would the atom fair against a duel core a9 clocked at 1.66ghz?
Its the power consumtion estimates that are the real suprise here..really? im under the impression that multicore SOCs spread the load across multiple cores to reduce power, and that arm had the power consumption 'in the bag' due to the complexity of x86 cisc v ARM risk.
The die area is also rather shocking, i thought it would be substantially bigger than that.
Whilst these numbers will give ARM vendors food for thought, lets not get ahead of our selfs just yet, Medfield is comparable to tegra 2 class designs(all things equal)
Krait, Cortex A-15 designs will be apon us by the time this launches..again on 28nm and 32nm designs...that should completely smoke this into oblivion.
The real worrying thing is not about this year its next year, if they can match a exynos 4210 when many thought they didnt have a chance..then silvermont on 22nm FINfet will be scary for arm, since they have already convinced Motorolla to sign a multi year deal and they have billions and billions to chuck around..i would be worried if i was an investor with ARM.