What's Different This Time Around: Google & A Sweet Reference Platform

Intel has been talking about getting into smartphones for a couple of years now, but thus far it hasn't been able to secure a single design or partnership that that resulted in a product actually coming to market. This time around, things are different. The major change? Focus, and Google.

Intel originally had ambitions of enabling its own mobile OS with the help of Nokia (Moblin/MeeGo). Intel also wanted to support Android as well, however its attention was clearly more focused on the Moblin/MeeGo effort. Similar to the wake up call that pushed NVIDIA to focus exclusively on Android, Intel has now done the same.

At IDF last year Intel and Google announced a partnership and the intention to bring all future versions of Android, starting with Gingerbread, to x86. Since then Intel has ramped up the software engineering engine, going into the Android source code (Gingerbread, Honeycomb and now ICS) and fixing bugs. Intel's goal is to deliver the most stable version of Android as a result of its efforts. Intel is also submitting its changes upstream to the AOSP, which should help improve the Android experience even on ARM platforms.

 

 

Under the leadership of Mike Bell (formerly of Apple and Palm), Intel has also created an extremely polished Medfield reference design. This is the same design shown off at IDF last year (apparently there's an even thinner one floating around somewhere), but what separates it from other reference designs we've seen from SoC vendors is that the Medfield reference platform was designed to be a polished phone that could theoretically be rebranded and resold.

Intel knew the onus was on itself to prove that Medfield, Atom and even just x86 was power efficient enough to be delivered in a compelling form factor with competitive battery life. Paul Otellini gave Mike carte blanche access to any of Intel's resources. Instead of having to work with existing Intel groups, Mike was allowed to assemble his dream team of engineers. The team Mike built is what he felt he needed to not only bring Medfield to market, but also to build the a first class Atom based smartphone.

The result is this:

 

Internally it features Intel's own XMM 6260 HSPA+ modem. Intel claims LTE is on the way although there's no ETA on that.

WiFi in the reference design is provided by TI's 1283 controller. Intel's wireless team does not have a a WiFi solution that's low power enough to work in a smartphone, although after the recent restructuring the team has now been tasked with building an ultra low power solution that can.

 

The display is a somewhat unusual 1024 x 600 panel, with support for 1080p30 (and 1080i60) output via HDMI. The SoC specs are identical to what I've already discussed: 1.6GHz max CPU clock and a 400MHz GPU clock.

The reference platform is not only smartphone sized, but Intel has built its own qualification labs that mirror those of the carriers to ensure quality and convince its customers of the platform's legitimacy. In essence, Intel has built its own miniature smartphone design and test center.

The Medfield reference platform is available for use by any of Intel's customers, and indeed that's what's already happening. Lenovo's K800 is based on a modified version of Intel's reference platform, and I wouldn't be surprised if more aren't on the way.

All of this sounds a lot like Intel's efforts in the motherboard space over a decade ago where it started providing motherboard manufacturers with reference designs that they could modify if they desired. The effort helped significantly reduce time to market and allowed the motherboard makers to focus more on specializing on what they were good at.

The Medfield reference platform is designed to do the very same for smartphones. Intel wants to provide its partners with a well designed, stable smartphone platform. If they choose to use it, they can shave off a significant amount of development time and spend more of their time on software or simply bring a good reference phone to market in a quick fashion. I'm not entirely sure I've seen many players in the Android space that are actually all that great at software development, but Intel believes anything that shortens time to market will be appreciated.

I asked Intel if it has any plans to offer the reference platform unlocked, direct to customers. Unfortunately the answer at this point is still no. I suspect that Intel is more interested in building its customer base rather than circumventing it.

 

The GPU, Process & Roadmap ARM Compatibility: Binary Translation
POST A COMMENT

163 Comments

View All Comments

  • 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. Reply
  • 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.
    Reply
  • 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).
    Reply
  • 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.
    Reply
  • 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.
    Reply
  • 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. Reply
  • 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.
    Reply
  • 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?
    Reply
  • 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.
    Reply
  • Hector2 - Wednesday, January 11, 2012 - link

    So you doubt Anand's power measurements too ?

    As for the DX11 demo, Intel's VP showed very poor judgement running a video when they had trouble getting the demo out in time -- that's a major screw up, but Anand showed that the hardware actually works in spite of the screwed up demo.
    Reply

Log in

Don't have an account? Sign up now