Intel's Medfield & Atom Z2460 Arrive for Smartphones: It's Finally Here
by Anand Lal Shimpi on January 10, 2012 8:00 PM ESTThe GPU
The PowerVR SGX 540 in Medfield is no different from what you'd get in an OMAP 4460, with the exception that it's clocked a bit higher at 400MHz.
The SGX 540 here is a remnant of Intel's earlier strategy to have Medfield out far sooner than it actually is going to show up on the market. Thankfully Intel has plans to introduce a PowerVR SGX 543MP2 based Medfield successor also before the end of the year.
Video Decode/Encode Support, Silicon Hive ISP
Intel relies on two more IP blocks from Imagination Technologies: the VDX385 and VDE285 for 1080p video decode and encode. Intel claims support for hardware accelerated 1080p30 decode, High Profile. Maximum supported bitrate is apparently up to 50Mbps, although Intel only demonstrated a 20Mbps High Profile stream:
Intel also claims support for 1080p30 video encode.
Medfield's ISP is provided by Intel owned Silicon Hive. The ISP supports cameras ranging from 5MP to 16MP (primary sensor), with the reference design standardizing on an 8MP sensor. Medfield supports burst capture at up to 15 fps (8MP).
The Process
Intel bifurcated its process technology a few years ago, offering both low power and high performance versions of each of its process nodes. Today those process nodes are staggered (45nm LP after high perf 32nm, 32nm LP debuts after high performance 22nm, etc...) however Intel plans on bringing both in lockstep.
Medfield debuts on Intel's 32nm LP process. The only details we have from Intel are that leakage is 10x lower than the lowest on 45nm. Compared to Moorestown, Medfield boasts 43% lower dynamic power or 37% higher frequency at the same power level.
The bigger and more valid comparison is to TSMC's 28nm process, which is what companies like Qualcomm will be using for their next-generation SoCs. It's unclear (and very difficult) to compare different architectures on different processes, but it's likely that Intel's 32nm LP process is more comparable to TSMC's 28nm LP process than it would be to any 4x-nm node.
It is important to note that Intel seems very willing to sacrifice transistor density in order to achieve lower power consumption where possible. I don't believe Intel will have the absolute smallest die sizes in the market, but I also don't believe it's clear what the sweet spot is for mobile SoCs at this point. It's quite likely that Apple's ~120mm^2 target is likely where everyone will eventually end up in the near term.
The Roadmap
Although Medfield is already posting competitive performance numbers, its current competition is roughly a year old. Within the next two quarters we'll see smartphones and tablets shipping based on Qualcomm's Krait. The next-generation Snapdragon platform should be Cortex A15-like in its performance level
Today we have Medfield, a single core Atom paired with a PowerVR SGX 540 built on Intel's 32nm LP process. Before the end of the year we'll see a dual-core Atom based Medfield with some form of a GPU upgrade. I wouldn't be too surprised to see something like a PowerVR SGX 543MP2 at that point either. In tandem Intel will eventually release an entry level SoC designed to go after the more value market. Finally we'll see an Intel Atom based SoC with integrated Intel baseband from its Infineon acquisition - my guess is that'll happen sometime in 2013.
Facebook
Twitter
RSS
164 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.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...
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.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.
dethrophes - Wednesday, April 8, 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.0cSGX540 = 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.