Final Words

Intel finally did it. After almost five years of talking about getting into mobile phone form factors, Intel went out and built a reference platform that proved what they've been saying was possible all along. Furthermore, Intel also finally landed a couple of partners who are willing to show their support by incorporating Medfield into their product portfolio. The releases are still a few months away at the earliest (possibly even longer for Motorola) but it's much better news than Intel has ever reported before in this space.


Medfield (left 1) vs. Moorestown (right 2)

The partnerships aren't out of pity either: Medfield is fast. I firmly believe had it been released a year ago it would have dominated the Android smartphone market from the very start. Even today it appears to deliver better CPU performance than anything on the market, despite only having a single core. GPU performance is still not as fast as what's in the A5 but it's competitive with much of the competition today, and I fully expect the dual-core version of Medfield to rectify this problem.

Based on the data Intel shared with us as well, the x86 power problem appears to be a myth - at least when it comes to Medfield. I'm still not fully convinced until we're able to test a Medfield based phone ourselves, but power efficiency at the chip level doesn't seem to be a problem.

Medfield and the Atom Z2460 are a solid starting point. Intel finally has a chip that they can deliver to the market and partners to carry it in. Intel also built a very impressive reference platform that could lead to some very interesting disruptions in the market.

While I'd like to say that Intel's Medfield team can now breathe a sigh of relief, their work is far from over - especially with more competitive ARM based SoCs showing up later this year. I'm really interested to see where this goes in the next 12 months...

ARM Compatibility: Binary Translation


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.
  • 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?
  • 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.
  • 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:

    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.
  • dethrophes - Wednesday, April 08, 2015 - link

    Having worked with both, in my openion intel wins hands down.
    The arm paper specs look ok until you have to work with it,
    Intel have an integrated cache solution. I always feel with arm cache that some guys just hacked together various components with gaffa tape. There are also so many errata with regard to the caches that a lot of the features such as the l2 prefetcher get disabled by default.
  • 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.
  • 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.
  • milli - Tuesday, January 10, 2012 - link

    It seems you're right. Wikipedia is wrong about this. Reply

Log in

Don't have an account? Sign up now