It'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:

SunSpider Javascript Benchmark 0.9.1 - Stock Browser

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:

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.

The CPU
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