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

  • french toast - Wednesday, January 18, 2012 - link

    Yea dont tell us you have never heard of intel anti competitive practises?? hell they have already been fined billions of $ for it. Reply
  • jaffa62 - Wednesday, May 16, 2012 - link

    Typical smartphone malware leverages platform vulnerabilities that allow it to gain root access on the device in the background. Using this access the malware installs additional software to target communications, location, or other personal identifying information. Thanks.
    Regards,
    http://www.scottsdale-azsearchforhomes.com/scottsd...
    Reply
  • ltcommanderdata - Tuesday, January 10, 2012 - link

    So Intel has switched from the DirectX compliant SGX535 to the OpenGL ES only SGX540? Does this mean they have no plans to support Windows Phone or Windows with Medfield?

    In regards to the memory interface, many Cortex A9 implementations include a 64-bit memory controller just like Medfield. If Intel is saying Cortex A9 is still memory bandwidth limited does that mean that ARM memory controllers are currently inefficient? Would increasing L2 cache from the current 512KB per core Cortex A9 implementations be an effective way to mitigate this?
    Reply
  • guilmon19 - Tuesday, January 10, 2012 - link

    " 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."

    It looks like its cache that is the problem and its more of a controller problem then the size of the cache itself, but increase the size of the cache would help, but it wouldn't be the most efficient solution.
    Reply
  • wumpus - Wednesday, January 11, 2012 - link

    The article implies that the core somehow handles it. Claiming that an in-order CPU can handle cache misses better than an out-of-order one has to be wrong. I wouldn't be surprised if the intel cache/memory controller is sufficiently better to cause these results. Reply
  • Exophase - Wednesday, January 11, 2012 - link

    Those in-flight memory requests that miss L2 wouldn't be coming from the CPU instructions themselves but the hardware prefetcher. So being in-order doesn't stop it from making requests. Plus it has SMT.

    It wouldn't surprise me if Atom's auto prefetcher is better than Cortex-A9's. Intel has a lot more experience with them, this is the first one ARM has done. It also goes directly into L1 cache, while Cortex-A9's just goes into L2 (the core gives prefetch hints to the L2 controller), but it can load into L1 directly with manual prefetch instructions.

    You can see some comparisons here:

    http://www.7-cpu.com/cpu/Cortex-A9.html
    http://www.7-cpu.com/cpu/Atom.html

    L2 latency is higher on A9 due to being less tightly coupled and shared between two cores. Somewhat mitigated by being OoO and (usually) having more of it. L2 bandwidth is comparable. Other latencies are also comparable. Effective read bandwidth is a lot higher on Atom, while effective write bandwidth higher on this A9. I'm sure the former highlights the differences in L2 misses in flight Intel is talking about, while the latter highlights differences in store queue depth.

    I doubt bandwidth is going to be a key player for most benchmarks or you'd see Exynos and OMAP4 have a big advantage over Tegra 2 (it doesn't), not to say that it doesn't matter for GPU performance.
    Reply
  • milli - Tuesday, January 10, 2012 - link

    SGX535 = DX 9.0c
    SGX540 = DX 10.1

    A CPU still needs to be able to take advantage of the available memory bandwidth (through technologies like prefetching, ...). A good example can be found in the desktop space between Intel and AMD, where Intel CPU's have much higher memory bandwidth (while both have similar theoretical bandwidth).
    While increasing the L2 cache on an A9 SOC would mitigate this to some extend, don't expect wonders. It's also not very realistic ATM to have more than 1MB cache in a mobile SOC.
    Reply
  • ltcommanderdata - Tuesday, January 10, 2012 - link

    The SGX540 does not have DirectX support. In the Series5/5XT line, the DX compliant cores are:

    SGX535: DX9.0c
    SGX544/554: DX9 level 3
    SGX545: DX10.1

    The SGX520/530/531/540/543 only support OpenGL ES 2.0 and not full DX compliance.
    Reply
  • milli - Tuesday, January 10, 2012 - link

    It seems you're right. Wikipedia is wrong about this. Reply
  • Penti - Wednesday, January 11, 2012 - link

    And it doesn't matter since the SoC's or rather CPU's aimed at Windows x86/64 tablets and Windows appliances does have SGX545. Windows 8 and Windows Phone (CE based) are two totally different OS's any way and Windows Phone is having a hard time just to support Qualcomm Snapdragon S1 and S2. I don't want to run Windows 8 Ribbon/MFC/WPF software on a phone platform neither do you. Microsoft won't support Windows Phone on x86. Microsoft won't support Windows 8 on this.

    They will as in Microsoft on Cedar Trail-M if PowerVR and Intel which have to ship them ever get their poor Windows drivers working. PowerVR/ImgTec aren't known for their Windows driver quality.

    In a tablet and even tablet-PC (which Microsoft is still going for) it's mostly the screen that uses power. It doesn't matter if the cpu and chipset uses the 5W TDP plus 2.1W TDP it's still more power efficient then anything else running Windows (NT). It's just a few watts and a screen that will use just as much if not more power. In a phone on the other hand you can't have massive batteries and screens.

    Intel is aiming the SoC towards Android handsets and tablets i.e. pads not tablet-pcs. They don't list DX support or even Windows Embedded support. Neither does it support more then 1GB of ram. It's built to interface with modem (baseband), LPDDR2, HDMI, MIPI-DSI, USB Phy, eMMC, with camera modules not with ordinary PC hardware topology of DDR3, PCI-e, LVDS/eDP, South bridge chipsets containing basic I/O. As well as support for USB, ethernet, SATA and whatnot in the SB. Memory will come included in the package too. Simply another platform.

    Not for powering Office 2010 and Visual Studio 2012. Look for other chips there.
    Reply

Log in

Don't have an account? Sign up now