Intel's Medfield & Atom Z2460 Arrive for Smartphones: It's Finally Here
by Anand Lal Shimpi on January 10, 2012 8:00 PM ESTThe GPU
The PowerVR SGX 540 in Medfield is no different from what you'd get in an OMAP 4460, with the exception that it's clocked a bit higher at 400MHz.
The SGX 540 here is a remnant of Intel's earlier strategy to have Medfield out far sooner than it actually is going to show up on the market. Thankfully Intel has plans to introduce a PowerVR SGX 543MP2 based Medfield successor also before the end of the year.
Video Decode/Encode Support, Silicon Hive ISP
Intel relies on two more IP blocks from Imagination Technologies: the VDX385 and VDE285 for 1080p video decode and encode. Intel claims support for hardware accelerated 1080p30 decode, High Profile. Maximum supported bitrate is apparently up to 50Mbps, although Intel only demonstrated a 20Mbps High Profile stream:
Intel also claims support for 1080p30 video encode.
Medfield's ISP is provided by Intel owned Silicon Hive. The ISP supports cameras ranging from 5MP to 16MP (primary sensor), with the reference design standardizing on an 8MP sensor. Medfield supports burst capture at up to 15 fps (8MP).
The Process
Intel bifurcated its process technology a few years ago, offering both low power and high performance versions of each of its process nodes. Today those process nodes are staggered (45nm LP after high perf 32nm, 32nm LP debuts after high performance 22nm, etc...) however Intel plans on bringing both in lockstep.
Medfield debuts on Intel's 32nm LP process. The only details we have from Intel are that leakage is 10x lower than the lowest on 45nm. Compared to Moorestown, Medfield boasts 43% lower dynamic power or 37% higher frequency at the same power level.
The bigger and more valid comparison is to TSMC's 28nm process, which is what companies like Qualcomm will be using for their next-generation SoCs. It's unclear (and very difficult) to compare different architectures on different processes, but it's likely that Intel's 32nm LP process is more comparable to TSMC's 28nm LP process than it would be to any 4x-nm node.
It is important to note that Intel seems very willing to sacrifice transistor density in order to achieve lower power consumption where possible. I don't believe Intel will have the absolute smallest die sizes in the market, but I also don't believe it's clear what the sweet spot is for mobile SoCs at this point. It's quite likely that Apple's ~120mm^2 target is likely where everyone will eventually end up in the near term.
The Roadmap
Although Medfield is already posting competitive performance numbers, its current competition is roughly a year old. Within the next two quarters we'll see smartphones and tablets shipping based on Qualcomm's Krait. The next-generation Snapdragon platform should be Cortex A15-like in its performance level
Today we have Medfield, a single core Atom paired with a PowerVR SGX 540 built on Intel's 32nm LP process. Before the end of the year we'll see a dual-core Atom based Medfield with some form of a GPU upgrade. I wouldn't be too surprised to see something like a PowerVR SGX 543MP2 at that point either. In tandem Intel will eventually release an entry level SoC designed to go after the more value market. Finally we'll see an Intel Atom based SoC with integrated Intel baseband from its Infineon acquisition - my guess is that'll happen sometime in 2013.
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.