Medfield: Intel in a Smartphone

I touched on this before but there were a number of reasons we never saw Moorestown in a smartphone. One part of the problem was the number of packages required to implement the platform, the other was that it simply lacked some of the things that smartphone OEMs implicitly expect to live on an SoC. The internal Intel guidance was that Moorestown required 2 packages to implement (Lincroft and Langwell), and in addition to those two you needed an external PMIC and DRAM. There wasn’t support for PoP memory, only external LPDDR1, and there was only support for 5 MP camera and 720p encode.

Medfield builds in every way on top of this by delivering a bona fide SoC with PoP LPDDR2 (2 x 32 bit support), improved ISP from Intel’s Silicon Hive acquisition, video encode and decode blocks from Imagination, SGX 540 graphics at 400 MHz, additional I/O, and an external Avatele Passage PMIC (Intel calls this an MSIC). The result is a platform that looks to an OEM like any of the other competitors - it’s a combination of SoC, PMIC, and some PoP LPDDR2, as opposed to the previous solution which required two additional external packages. Intel has a few slides online about this evolution and how things have moved inside the single Medfield package, and the result again is something that finally looks like any one of countless ARM-based SoCs.

The specific part inside the X900 is an Atom Z2460 32nm SoC (the platform is Medfield, Penwell is the SoC, and the CPU inside is a Saltwell), and inside a Penwell is the Atom Saltwell core running at up to 1.6 GHz with 512KB of L2 cache, a PowerVR SGX 540 GPU at 400 MHz, and a dual channel LPDDR2 memory interface. Anand has already written about the CPU architecture itself pretty comprehensively, and how it compares to ARM’s Cortex A9 and A15 designs. The long and short of it is that Saltwell is still a dual-issue, in-order core with Hyper-Threading support. There’s a 16 stage integer pipeline, no dedicated integer multiply or divide units (they’re shared with the floating point hardware), and in addition to the 512KB L2 cache there’s a separate 256KB SRAM which is lower power and on its own voltage plane. When Saltwell goes into its deepest sleep state, the CPU state and some L2 cache data gets parked here, allowing the CPU voltage to be lowered even more than the SRAM voltage. As expected, with Hyper-Threading the OS sees two logical cores to execute tasks on.

The other interesting thing is support for EIST and additional C states when the device is idle. Dynamic CPU clocks through the linux governor is something absolutely critical for getting a smartphone with acceptable battery life. What’s interesting here is that Penwell’s advertised dynamic range is between 100 MHz and 1.6 GHz with fine grained 100 MHz increments between, in addition to the C6 state where CPU state data is saved in the on-SoC low power SRAM and the platform is basically suspended (deep sleep).

However, the Android governor onboard the X900 only includes a few steps between 600 MHz and the maximum 1.6 GHz burst clock, in addition to C6. You can see this either by inspecting the governor’s available scaling frequencies:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
1600000 1400000 1200000 900000 600000 
$ cat time_in_state
1600000 233495
1400000 12304
1200000 19780
900000 25801
600000 5306262

Or by using an Android application which inspects exactly this data. I spent a day with the Medfield phone in my pocket and made a note of capturing what the state data was after the day’s end, and the CPU does indeed go into C6 while idle and in the pocket, and spend a lot of time at the minimum 600 MHz clock with some bursts to 1.6 GHz when I’m doing things.

 

The reality is that most of the smartphone’s time is really spent idling, waking up only to watch some DRX slots or process background tasks. It is curious to me however that Intel isn’t implementing their Ultra-LFM modes between 100 and 600 MHz - it’s possible there’s no voltage scaling below 600 MHz which in turn doesn’t make it worth jumping into these lower clocks quite yet.

Depending on the device’s thermals, Intel’s governor will select between those available frequencies. There actually are four thermal zones in the device, on the back, front, baseband, and SoC itself. The SoC can go up to 90C before you get throttled (which is pretty typical for Intel CPUs), 75 C on the back, 64 C on the front, and 80 C on the modem. Those sound high but aren’t out of the ordinary for some of the other SoCs I’ve seen who have similar thermal management. In addition, if the platform gets too hot, the display brightness will be clamped to 50%.

I have to admit that I did see the display brightness get clamped once as shown above, but only once during a period where I was running the display at 100% brightness and maxing out the CPU. The bottom back of the X900 can indeed get warm, but nothing inordinate or near the thermals that are set in the software management.

Finally, Saltwell supports the same instruction set as Core 2, including SSE3 and Intel 64. We can check this by looking at the CPU flags from cpu_info as well:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 39
model name : Intel(R) Atom(TM) CPU Z2460  @ 1.60GHz
stepping : 2
cpu MHz : 600.000
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon pebs bts nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 xtpr pdcm movbe lahf_lm arat tpr_shadow vnmi flexpriority
bogomips : 3194.88
clflush size : 64
cache_alignment : 64
address sizes : 32 bits physical, 32 bits virtual
power management:

The rest of the Medfield platform we’ll talk about in the appropriate sections, but the big takeaway is that Intel finally has a real x86 SoC for smartphones and tablets. In addition to the Z2460 that we’re looking at in the X900, Intel has two other SKUs which round out the high end and low end. At the low end is the Z2000 which is functionally identical to the Z2460 but with a maximum CPU clock of 1.0 GHz, no HT, and an SGX 540 clock of 320 MHz, and the Z2580 which is clearly targeted at Windows 8 tablets with two Saltwell cores clocked up to 1.8 GHz, and PowerVR SGX544MP2 graphics at 533 MHz for Direct3D 9_3 compliance.

The Road to Medfield, and The Device Android on x86 and Binary Translation
Comments Locked

106 Comments

View All Comments

  • kyuu - Wednesday, April 25, 2012 - link

    I dunno what review you all were reading, but I didn't see average performance. I saw it pretty much beating everything else save the HTC One S/X with only a single-core and running an old version of Android. Wth ICS, it'd probably be at the top easily.

    Sure, ARM isn't sitting still, but is Intel. I have no desire to see Intel overtake the market, but I can easily see Intel being the performance king by a good margin in the mobile SoC market when they release their next SoC.

    Also, for people saying cost is a factor... do you have any source to back up the claim that Intel's SoC is significantly more costly? All I see are assumptions.
  • kyuu - Wednesday, April 25, 2012 - link

    That's "neither is Intel" in the second paragraph, first sentence.
  • UpSpin - Thursday, April 26, 2012 - link

    SunSpider and Browsermark results are that good because of software tweaks done by Intel. Intel tweaked a lot in software, thus I doubt that ICS will improve anything further.

    Linpack single threaded, that's the most important benchmark to compare raw processing power without software tweaks. It shows that Medifield is faster than ARM A9, a good sign, but slower than Krait and thus all soon to get released A15 cores, a bad sign.
    Linpack multi threaded shows that Medfield has not the slightest chance vs. Krait and ARM A15, most of them will be dual core SoCs, but even if they get produced in single core varients they will be faster (Linpack single threaded). Medifield also gets beaten by Quad Core A9 chips (all new high end smartphones pack either a Quad Core A9, or dual Core krait/A15). Medfield is at best, as fast as a dual core A9 (raw processing power).

    Then take a look at the GPU: Poor performance for todays standards. Slower than the SGSII, slightly faster than the Galaxy Nexus, which has a slow GPU, too.

    Power consumption: poor to average. (sadly we don't have numbers for Krait or Tegra 3 (HTC One X/S)

    The SoC is not bad at all, but its release date is one year too late. This year is the year of Krait and A15, which beat Medfield in single threaded applications and are at least dual cores, so more than twice as fast. The integrated GPU is pretty weak, too, especially if you consider that this years ARM SoCs have a much better GPU.

    Additionally x86, the advantage is huge software tweaks thanks to Intel, the disadvantage, custom skins/apps/features made by third party manufacturers won't run that easily.
  • Exophase - Friday, April 27, 2012 - link

    Intel doesn't tweak Sunspider or Browsermark. But Javascript JIT performance is probably much better on x86 than ARM right now because it got a ton of attention on PCs from all major browser vendors, starting with the release of Chrome. And there's at least one major ARM improvement (EABI hardfloat) that's in V8 but didn't make it into official Android yet.

    Browsermark is only partially Javascript, but the other part (HTML5 rendering) is really lame too. Run it and you'll see what I mean, I hope.

    Linpack is also a lousy benchmark. Any serious vector FP code on a phone (like matrix stuff for a game) would use SIMD with compiler intrinsics or ASM, and probably single precision over double precision. But even as a Dalvik double precision floating point test it sucks because it's not tiled and therefore heavily bandwidth limited.

    Basically, most of the benchmarks used are awful.
  • clockerspiel - Wednesday, April 25, 2012 - link

    The cell phone industry desparately needs a "flagship" representative for the Android ecosystem - and this ain't it!
  • jjj - Wednesday, April 25, 2012 - link

    You can't normalize battery life unless you factor in the screen size since the screen uses a lot of power and the handset's volume is directly related to the screen size and battery size.
    By normalizing you are making things worse than better.If you can't measure the power consumption for just the SoC you might as well just provide the system's battery life since,in the end, that's what matters anyway.
    It is what it is,you can't take out the screen or the RAM or the NAND but that's no reason to make things worse with tests that distort the reality instead of helping.
  • menting - Wednesday, April 25, 2012 - link

    uhh, it's not measuring the power consumption for the SoC, it's measuring the whole phone's power usage. So in this case, normalizing IS a valid way to go about this.
  • plamengv - Wednesday, April 25, 2012 - link

    It is beyond me why Intel will market x86 CPU with OS that has nothing to do with x86. The people who want Android will always go with the better looking and cheaper device. Something that this device is not. The other with knowledge will go for iPhone because there is no other alternative. Windows Phone is from professional point of view worse than Windows Mobile 6.5 and lacks lot of features. Intel had to bet on Windows 7 turning the smartphones into UMPC. Imagine Viliv S5 shrinked to Galaxy Note but running Windows 7! Well maybe Haswell and 22nm will finally make it.
  • menting - Wednesday, April 25, 2012 - link

    android was built from Linux..tell me where Linux has nothing to do with x86. And with future android versions including x86 compiles by default., x86 or not isn't an issue.

    The X900 is a reference design, who says other companies can't put a different external case on it? And where's proof that it will be more expensive?
  • superPC - Thursday, April 26, 2012 - link

    why windows 7? windows 8 would be a lot better suited for something similar with this phone (with compatible GPU).

Log in

Don't have an account? Sign up now