Original Link: https://www.anandtech.com/show/5770/lava-xolo-x900-review-the-first-intel-medfield-phone
Lava Xolo X900 Review - The First Intel Medfield Phone
by Brian Klug on April 25, 2012 6:00 AM ESTFor Intel, the road to their first real competitive smartphone SoC has been a long one. Shortly after joining AnandTech and beginning this journey writing about both smartphones and the SoC space, I remember hopping on a call with Anand and some Intel folks to talk about Moorestown. While we never did see Moorestown in a smartphone, we did see it in a few tablets, and even looked at performance in an OpenPeak Tablet at IDF 2011. Back then performance was more than competitive against the single core Cortex A8s in a number of other devices, but power profile, lack of ISP, video encode, decode, or PoP LPDDR2 support, and the number of discrete packages required to implement Moorestown, made it impossible to build a smartphone around. While Moorestown was never the success that Intel was hoping for, it paved the way for something that finally brings x86 both down to a place on the power-performance curve that until now has been dominated by ARM-powered SoCs, and includes all the things hanging off the edges that you need (ISP, encode, decode, integrated memory controller, etc), and it’s called Medfield. With Medfield, Intel finally has a real, bona fide SoC that is already in a number of devices shipping before the end of 2012.
In both an attempt to prove that its Medfield platform is competitive enough to ship in actual smartphones, and speed up the process of getting the platform to market, Intel created its own smartphone Form Factor Reference Design (FFRD). While the act of making a reference device is wholly unsurprising since it’s analogous to Qualcomm’s MSM MDPs or even TI’s OMAP Blaze MDP, what is surprising is its polish and aim. We’ve seen and talked about the FFRD a number of times before, including our first glimpse at IDF 2011 and numerous times since then. Led by Mike Bell (of Apple and Palm, formerly), a team at Intel with the mandate of making a smartphone around Medfield created a highly polished device as both a demonstration platform for OEM customers and for sale directly to the customer through participating carriers. This FFRD has served as the basis for the first Medfield smartphones that will (and already are) shipping this year, including the Orange Santa Clara, Lenovo K800, and the device we’re looking at today, the Lava Xolo X900. Future Medfield-based devices will deviate from the FFRD design (like the upcoming Motorola device), but will still be based loosely on the whole Medfield platform. For now, in the form of the X900 we’re basically looking at the FFRD with almost no adulteration from carriers or other OEMs.
The purpose and scope of this review is ambitious and really covers two things - both an overview of Intel’s Medfield platform built around the Atom Z2460 Penwell SoC, and a review of the Xolo X900 smartphone FFRD derivative itself.
The Device
Beginning April 23rd, Intel, through Lava International, began selling the Xolo X900 smartphone in India for INR 22000 (~$420 USD). As we’ve stated before, the design and construction of the Xolo X900 almost identically mirrors the Intel FFRD we’ve seen before, from the specifications and Medfield platform itself, to industrial design and exterior buttons.
It’s a testament to the polish of the reference design that Mike Bell’s team put together that Intel is confident enough to basically sell exactly that device through carrier partners. I’ll admit I was skeptical upon hearing that Intel would basically be selling their MDP to customers, but the device’s fit and polish exceeded my expectations and are clearly those of something ready for customer abuse. First up are the X900 specifications in our regular table (below), Xolo also has its own nicely presented specifications page for the X900 online.
Physical Comparison | ||||
Apple iPhone 4S | Samsung Galaxy S 2 | Samsung Galaxy Nexus (GSM/UMTS) | Lava Xolo X900 | |
Height | 115.2 mm (4.5") | 125.3 mm (4.93") | 135.5 mm (5.33") | 123 mm (4.84") |
Width | 58.6 mm (2.31") | 66.1 mm (2.60") | 67.94 mm (2.67) | 63 mm (2.48") |
Depth | 9.3 mm ( 0.37") | 8.49 mm (0.33") | 8.94 mm (0.35") | 10.99 mm (0.43") |
Weight | 140 g (4.9 oz) | 115 g (4.06 oz) | 135 g (4.8 oz) | 127 g (4.5 oz) |
CPU | Apple A5 @ ~800MHz Dual Core Cortex A9 | 1.2 GHz Exynos 4210 Dual Core Cortex A9 | 1.2 GHz Dual Core Cortex-A9 OMAP 4460 | 1.6 GHz Intel Atom Z2460 with HT (1C2T) |
GPU | PowerVR SGX 543MP2 | ARM Mali-400 | PowerVR SGX 540 @ 304 MHz | PowerVR SGX 540 @ 400 MHz |
RAM | 512MB LPDDR2-800 | 1 GB LPDDR2 | 1 GB LPDDR2 | 1 GB LPDDR2 @ 400 MHz |
NAND | 16GB, 32GB or 64GB integrated | 16 GB NAND with up to 32 GB microSD | 16/32 GB NAND | 16 GB NAND |
Camera | 8 MP with LED Flash + Front Facing Camera | 8 MP AF/LED flash, 2 MP front facing | 5 MP with AF/LED Flash, 1080p30 video recording, 1.3 MP front facing | 8 MP with AF/LED Flash, 1080p30 video recording, 1.3 MP front facing |
Screen | 3.5" 640 x 960 LED backlit LCD | 4.27" 800 x 480 SAMOLED+ | 4.65" 1280x720 SAMOLED HD | 4.03" 1024x600 LED backlit LCD |
Battery | Internal 5.3 Whr | Removable 6.11 Whr | Removable 6.48 Whr | Internal 5.4 Whr |
It’s interesting to me that Intel, Qualcomm, and others identified and went with WSVGA (1024x600) for their reference designs in roughly the same 4" size. It’s a display form factor that corresponds almost exactly to 300 PPI, and looks great, but more on that later. The rest of the X900 is basically what you’d expect for a smartphone of this generation, and on par with the Android competition that Intel was targeting, perhaps minus microSD expansion.
The design language of the X900 (and Intel FFRD) is a pretty obvious nod to the iPhone 4/4S design, complete with chrome ring, similar button placement, and a few other things. Likewise, the X900 uses a microSIM whose tray is located on the right side and makes use of an ejector port and tool. Below that is the X900’s two-stage camera button, and then speaker port. There’s a matching speaker port on the other side in the same area.
MicroUSB is located at the very bottom slightly off center, and microHDMI is on the left side. Up at the top is power/standby and the standard headphone jack. There’s no real surprises here, and despite being entirely plastic-clad, the X900 feels pretty decent in the hand.
The backside is a soft touch material which we’ve seen and felt on countless other smartphones before. The only downside to the X900 design is lack of a user replaceable battery - the backside is permanently attached. At the top is the 8 MP camera port, adjacent LED flash, and secondary microphone for noise suppression.
The front of the X900 is likewise pretty standard fare - up top are the 1.3 MP front facing camera, speaker grille, ambient light sensor, and proximity sensor. At the bottom are the four Android capacitive buttons whose design mirrors the FFRD we’ve seen before.
Again there’s nothing super crazy about the design or construction of the X900, it’s an extremely polished reference design turned consumer electronic that feels solid and ready for use as a daily driver if you’re up for it. Enough about the superficial stuff though, let’s talk about what everyone wants to know about - Medfield and Android on x86.
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 : 0vendor_id : GenuineIntelcpu family : 6model : 39model name : Intel(R) Atom(TM) CPU Z2460 @ 1.60GHzstepping : 2cpu MHz : 600.000cache size : 512 KBphysical id : 0siblings : 2core id : 0cpu cores : 1apicid : 0initial apicid : 0fdiv_bug : nohlt_bug : nof00f_bug : nocoma_bug : nofpu : yesfpu_exception : yescpuid level : 10wp : yesflags : 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 flexprioritybogomips : 3194.88clflush size : 64cache_alignment : 64address sizes : 32 bits physical, 32 bits virtualpower 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.
Android on x86 and Binary Translation
So the other major and obvious piece of the puzzle is what changes were required to make Android and all of its applications run on x86. Android itself has already been built for x86 before, and again we’ve seen and played with it running all the way back at IDF 2010. That part of the puzzle is relatively understood, but the devil again is in the edge cases. Among the things that need massaging for x86 are the Dalvik VM, x86 JIT, NDK, and JavaScript engine.
Android itself is actually an ideal platform for Intel to target, as the vast majority of Android applications in the Play Store run atop the Dalvik VM and use the Android Framework (75–80% are commonly cited numbers, depending on how you’re counting). The rest either are Dalvik VM applications that run and use JNI (Java Native Interface) libraries that are built for ARM only, or NDK (Native Development Kit) applications. So where does Intel’s binary translation secret sauce fit into all this? Simply put, Intel’s binary translation is the mitigation for both libraries and NDK applications that haven’t yet been ported to x86, and allows the device to expose itself as supporting two application binary interfaces (ABIs), both x86 and ARMv5, in fact this is easy enough to see upon superficial inspection of build.prop:
ro.product.cpu.abi=x86 ... ro.product.cpu.abi2=armeabi
In the case of Dalvik applications, developers don’t need to do anything. Thankfully again this is the vast majority of Android applications you encounter on a daily basis - they just work, given that Intel has made Dalvik work with x86 and spit out the right machine code.
NDK applications are also easy enough to mitigate - the developer simply needs to recompile the NDK project, which supports ARMv5 (‘armeabi’), ARMv7 (‘armeabi-v7a’), and x86 (‘x86’). Building for x86 will deliver code that’s tailored (unsurprisingly) exactly to the Saltwell CPU feature set, or more explicitly what you’d get by running GCC with the compiler flags “-march=i686 -msse3 -mstackrealign -mfpmath=sse” - this is all outlined in the CPU-ARCH-ABIS.html document as part of the NDK documentation. The resulting APK can be packaged as a “fat binary” with machine code for all three platforms, and upon install only the proper one is unpacked and installed.
The remaining two cases are where binary translation come in. In the case of applications that haven’t been rebuilt with the NDK to target x86, the binary translator magic kicks in and translates the armeabi version into x86. The same applies for applications that request some JNI libraries that are currently ARM only.
Intel outlines this in a number of slides which have made their way online, and the process is virtually completely transparent to end users and Dalvik applications. The x86 compatible Dalvik VM is a part of the OS, as are the ARM to Atom BT phase for JNI libraries. ARM native NDK apps on the other hand are translated by Intel in the cloud, validated against Intel's Android x86 emulator and pushed to the Play Store. The point is the bulk of binary translation happens away from the device itself and running on much faster Xeons in the cloud. As binary translation requires more cycles than natively running the code, which in turn consumes additional power, this was the only route for Intel to ensure that Atom would remain power efficient (and high performance) even on non-native NDK apps. Update: Intel has clarified and informed us there is no cloud aspect to binary translation, it is 100% done on the device for ARM NDK applications.
It's still unclear just how long this process takes after a developer has uploaded a non-x86 NDK app to the Play Store, or what happens if the process fails to validate for whatever reason (Does Intel get in touch with the developer? Is the app forever excluded?). Intel is being unusually vague about how all of this works unfortunately.
The combination of all of these efforts should result in over 90% of the apps in the Play Store working right away. What about in our experience? We discuss that next.
Software: Nearly Flawless
The X900 that I was sent came running Android 2.3.7, which is the latest version on the 2.3 branch. Xolo intends to deliver an Android 4.0.3 update later, and Intel internally has its own 4.0.x image stable and ready to go, which we’ve seen running on the FFRD a bunch before. It’s a bit odd to see things going this way when 4.0.x is clearly already ready, but no doubt some logistical issues with carrier support are the final hurdle. I’m eager to check out Intel’s 4.0.x port and intend to update when that happens.
Xolo and Intel have basically left things entirely stock with the X900. The notifications shade has one minor positive change - inclusion of the power controls, and Swype is bundled in addition to the stock Android 2.3 keyboard. There’s one Xolo Care support application preloaded, and basically nothing else. I can honestly say this is the least preloaded junk I’ve ever seen on a non-Nexus device.
So the next logical step is talking about how well Android and its apps work on x86 in practice, and the answer is unsurprisingly that almost everything is perfect. I installed about 80% of all the Android applications I’ve ever installed on any Android phone (thanks to the new Google Play ‘All’ tab) and nearly all of them worked perfectly. In fact, all of my daily driver applications work flawlessly: Twitter for Android, Baconreader, Speedtest.net, Barcode Scanner, Astro, Dropbox, Facebook, GPS Test Plus, GPS Status, Instagram, IP Cam Viewer, GTA III, Remote Desktop, Swiftkey X, and WiFi Analyzer all work perfectly.
That said there are indeed a few edge cases where things don’t seem to be perfect. For one, Flash 11 isn’t available for the X900, and throws an error in the market. The device does come preloaded running Flash 10.3 however, which gets the job done although is a bit dated. In addition, although Netflix would download, the installer would throw a ‘package file invalid’ error upon install. This is what leads me to think there’s some APK interception in the cloud and perhaps translation up there, and Netflix DRM not translating, but that’s speculation. Other than this, everything else I encountered works flawlessly, I wager your average Android user wouldn't be able to tell that this is running on a completely different architecture.
Javascript Performance
Although smartphones are clearly headed for a life beyond simple messaging, web browsing and phone duties, we are still lacking the tools to measure performance in areas other than a component of web page rendering. Measuring javascript performance is one component of the entire web page rendering process but it's the most mature in terms of something we can benchmark.
Sunspider is quite possibly the most well known of these javascript tests, and it also happens to be one that runs extremely well on Medfield:
The Lava phone is just a tad faster than the FFRD we tested at the beginning of the year, which may not sound like much but is positive given that Mike Bell was very confident that all Intel FFRD phones would deliver the same level of performance. The X900 ends up being the fastest smartphone we've ever tested here. Intel won't be able to claim that title in any other benchmark here today but it's an impressive feat for just now showing up to the game. It's also worth pointing out that Intel is able to do this well running on Gingerbread, while its closest competition are running on Ice Cream Sandwich with far improved JS performance built into the browser.
Why is Medfield so much faster here? It's tough to say, but likely a combination of reasons. Google's V8 engine has had a ton of optimization work done around x86 to begin with. By virtue of nearly every computing platform that runs a Google browser outside of Android being x86, it's natural that some of those optimizations are going to transition over into Android for x86 as well. That's actually a part of a much larger advantage Intel has should x86 take off in the smartphone space.
On a more technical hardware level, Intel claims its cache and memory interfaces are simply better than the competition here - which in turn results in a significant performance jump in Sunspider.
BrowserMark is another js benchmark in our suite, but here the advantage has been reduced to simply competitive with the fastest phones in our labs:
For a single Atom core running Gingerbread, Medfield does very well here - roughly equaling the performance of NVIDIA's Tegra 3 (HTC One X) and Qualcomm's Snapdragon S4 (HTC One S). It's quite possible that when running ICS Medfield will once again step ahead of the competition, but even if this is as good as it gets it's a good start. Keep in mind that we're looking at a 4 year old microprocessor architecture running on a n - 1 process from Intel.
Low Level FP Performance
Linpack isn't a great indication of smartphone performance, but it is a good test of the floating point capabilities of the CPUs in these SoCs. ARM has steadily been improving FP performance for the past few generations but we're going to see a big jump to Krait/A15. As most client smartphone workloads are integer based and those that are FP heavy end up relying on the GPU, an advantage here doesn't tell us much today (particularly because Linpack isn't running native code but rather atop Dalvik) other than how speedy the FPUs are:
Single threaded FP performance is very good on Medfield as you'd expect, but a bit lower than Qualcomm's Snapdragon S4. As Krait is a wider, out-of-order architecture with a fairly reasonable FPU the 13% advantage here isn't too surprising. Compared to anything A9 based however, Medfield is obviously quicker.
Linpack, like many scientific workloads, scales up to multiple cores quite nicely. If we spawn as many threads as there are logical cores (2 for Intel and Qualcomm, but 4 for NVIDIA's Tegra 3) we can see how Intel's single-core Atom fares in a multithreaded world:
There's roughly no change in Medfield's performance here, which will be an issue for any compute heavy, very threaded application. Luckily for Intel, not many of these types of applications exist on smartphones today, but it is a limitation of this first generation Medfield. Hyper Threading is a great way to increase CPU utilization power efficiently, but for some workloads there's no replacement for more cores. Snapdragon S4 does extremely well here in the HTC One S by being a combination of two cores and having a much faster FPU.
BaseMark OS
Rightware's BaseMark OS is a general purpose benchmark designed to better simulate overall Android performance. It includes a heavily threaded benchmark, file IO tests, and compression/decompression tasks that all contribute to its overall score. We only have results from the HTC One S (Snapdragon S4), One X (Tegra 3), Galaxy Nexus (OMAP 4) and the Lava phone (Medfield) here:
At least in BaseMark OS, Intel's performance is distinctly modern although not at the head of the class. Differences in performance here extend beyond the SoC and are obviously influenced by things like NAND selection as well as the OS on the device. For many of these benchmarks I'm very curious to see how they change with the arrival of Ice Cream Sandwich.
Vellamo
Vellamo is a Qualcomm developed benchmark that focuses primarily on browser performance, both in rendering and UI speed. The results are heavily influenced by the browser used on the device being tested. As a whole Vellamo isn't always indicative of whether or not you're going to get a smooth browsing experience, but it's another datapoint that captures more than just javascript performance. The Qualcomm-developed nature of the benchmark is always cause for concern, but even if you exclude the Snapdragon results the benchmark can be useful:
Once again we have a good showing from Intel. The X900 and its Medfield soul aren't the fastest, but Intel's first smartphone is in the top three and faster than almost everything that came before it. Much of the advantage here actually comes from the Google V8 benchmark, another js test, which we've already established Intel can do quite well in.
Flash Rendering Performance
These days nearly all high-end smartphones (I refuse to call them superphones) can render Flash smoothly. Thankfully Intel's platform is no exception as the X900 delivers a competitive showing in our Flash benchmark:
GPU Performance - GLBenchmark 2.1
While Intel's Atom core is a newcomer to Android, the PowerVR SGX 540 used in Medfield's SoC has been around the block quite a bit. Most recently, Samsung's Galaxy Nexus used an OMAP 4 that features the same SGX 540 GPU. The GPU clock is a bit higher than we're used to at 400MHz (vs 304MHz for the Galaxy Nexus), but otherwise the design and its performance are both known quantities.
We start with GLBenchmark, one of the better Android GPU tests on the market today. There are two benchmarks, Egypt and Pro, and each is run in two modes: native screen resolution and offscreen (vsync disabled) at 720p. The latter is more useful for apples to apples comparisons as everything is rendering the same number of pixels, whereas performance in the onscreen tests is determined by the screen resolution of the device along with the performance of its GPU.
The X900 falls in just behind the Optimus 3D, which shares the same GPU but is running at a lower resolution. All things considered, the X900 does reasonably well here but it's definitely not leading the pack.
At the same display resolution and without any vsync limits, the X900 falls significantly behind the cream of the crop. Despite the GPU clock advantage, Medfield is no faster than OMAP 4 in the Galaxy Nexus here which is a bit perplexing. We're either bumping into a memory bandwidth limit or some other CPU/driver limitation. Either way, Intel definitely needs a faster GPU. We'll get it but not until early next year with the 544MP2 in the Atom Z2580.
The Pro results actually show us more of what we expected to see:
The offscreen tests give the Medfield based X900 a 25% advantage over the Galaxy Nexus, which makes sense. The Droid 4 is closer than that, despite also using the same GPU.
Basemark ES 2.0 V1
Rightware's Basemark ES 2.0 V1 is an aging GPU test that tends to favor Qualcomm's Adreno GPUs above almost all others. The Imagination Technologies based GPUs, such as the SGX 540 used in Medfield (as well as NVIDIA's Tegra GPU) don't fare as well here. Intel's GPU clock advantage does show up a little bit in these tests, making it the fastest PowerVR SGX based offering here:
Battery Life
Nailing performance is one thing, but in order to really sell Medfield and other upcoming SoCs to OEMs, Intel has to deliver battery life and power consumption that's competitive. It's about performance/power in the SoC space. First, it's worthwhile to note that the X900 includes a relatively small battery, at just 5.4 Whr. Of late, batteries over 6 Whr seems like the norm, and I'm told that future designs including the Motorola phone will probably include larger ones. It's just good to have that frame of reference and this chart should help:
Intel notes battery life in their own X900 announcement blast as being around 5 hours of continuous 3G browsing and 8 hours of talk time. Our own numbers end up being pretty darn close, at 4.6 hours and 8.5 hours for those two metrics, respectively.
As a reminder, the browsing tests happen at 200 nits and consist of a few dozen pages loaded endlessly over WCDMA or WiFi (depending on the test) until the phone powers off. The WiFi hotspot tethering test consists of a single attached client streaming 128 kbps MP3 audio and loading four tabs of the page loading test through the handset over WCDMA with the display off.
As a smartphone the X900 does a bit below average here, but as we mentioned it also has an unusually small battery for a modern flagship Android smartphone. If we divide battery life by battery capacity, we can get a better idea for how the Medfield platform compares to the competition:
Normalizing for battery capacity, the X900 actually does a bit above average. In other words, the Medfield platform appears to be just as power efficient as some of the newer OMAP 4 based smartphones.
On WiFi the situation is no different:
Again we see reasonable numbers for the X900 but nothing stellar. The good news is that the whole x86 can't be power efficient argument appears to be completely debunked with the release of a single device. To move up in the charts however, Intel needs to outfit its reference design with a bigger battery - something I've heard is coming with the Z2580's FFRD. The normalized results put the X900 at the middle of the pack:
We see similar results in our talk time and 3G hotspot tests:
Camera is the other big axis of improvement with Medfield, as Intel has included a SiliconHive ISP with full support for up to 24 MP rear facing cameras and a 2 MP secondary camera. Intel acquired SiliconHive a while ago, and it has integrated their IP prominently inside the platform.
In addition all the features you need to support a smartphone camera are here, including AE, AWB, AF, lens shading and distortion correction, stabilization, and fixed pattern/dark noise subtraction. Intel is also quite proud of its burst functionality which enables up to 10 full size 8 MP images to be captured at up to 15 FPS.
I did some digging and found what CMOSes are being used in the Xolo X900 smartphone. The front facing camera is an Aptina mt9m114 1.3 MP 1/6“ CMOS with 1.9µm square pixels, and the rear facing camera is an Aptina mt9e013 8 MP 1/3.2” CMOS with 1.4µm pixels (3264 x 2448). The 8 MP rear facing system appears to possibly be from LiteOn. The optical system onboard is F/2.4 with 4.4mm focal length. The result is a thoroughly modern camera system that is up to par with what’s shipping in other devices right now. Interestingly enough, I can tell from poking around that Intel has tested the Medfield platform with a 14MP module as well.
The camera UI on the X900 is by far the most comprehensive of any smartphone I’ve encountered so far. The still shooting mode includes customization options for the burst mode and FPS, image capture size, compression level, and bracket modes in the top tab. Below that are scene modes (Auto, Sports, Portrait, Landscape, etc), focus modes (Auto, Infinity, Macro, Touch to focus), white balance (Auto, Incandescent, Daylight, etc), exposure, flash, color filters (None, Sepia, BW, Negative), ISO (100, 200, 400, 800), exposure time (1s to 1/500s), and auto exposure metering modes, phew. What’s really unique however are toggles under the happy face icon for advanced features like GDC (geometric distortion correction), XNR (extra noise reduction for low light), ANR (another noise reduction routine). These are usually things present in other ISPs, but I’ve never seen the option to play with them in any smartphone camera UI before. There are also some RAW options which, based on their labeling, I would assume allow you to save pre-Bayer demosaicing RAW data and YUV data, but I’m not sure where this data is stored after capture. Resetting the camera to defaults interestingly enough turns GDC, XNR, and ANR off, so it is in this mode that I captured sample images.
Burst mode works well, as does the camera UI. Images captured in burst mode are prefixed with BST instead of IMG when they’re stored, so you can tell the two apart later on the desktop. 8 MP images captured on SuperFine end up being just under 2 MB after JPEG compression.
To get to the bottom of still image quality, we turned to our regular set of evaluation tools, consisting of both photos taken in a fixed smartphone lightbox test scene with the lights on and off, with test charts (GMB color checker card, ISO12233, and distortion), and at our smartphone bench locations. I took these after resetting the camera to defaults, which again curiously disables GDC, XNR, and ANR. The result is some very strange higher order distortion in the chart (the chart is indeed flat and normal to the camera), but good spatial resolution in the ISO chart, I can see up to around 15 lp/ih in the vertical and 14 in the horizontal. White balance is a bit weird on the chart, but in the lightbox the white balance is pretty good. The X900 also illuminates the scene for focusing before taking the photo in the dark, which is something some smartphone OEMs are still not doing.
I’m pretty pleased with camera quality, it isn’t as good as some other smartphones that are out right now, but it’s very good. I suspect this is more a reflection of the optics (eg heavy distortion without geometrical correction) than ISP. I actually come away pretty impressed with all the options that have been made available, it’s obvious that lots of time and energy went into that part.
Video
The video capture UI unsurprisingly offers some of the same configuration options as the still shooting mode. Capture resolutions from QVGA to 1080p are offered, along with various MMS compatible settings like we’re used to seeing. The menu here also offers the ability to disable electronic video stabilization (DVS) and noise reduction (NR) which is awesome, especially since many find electronic video stabilization somewhat disconcerting. I disabled it for the test video since this results in the same behavior I saw with the Galaxy Nexus before Google ostensibly disabled it on the rear camera (but left it enabled on the front one). Anyhow, I’m grateful that the options are here, as the smartphone camera UI standard seems to be trending toward Apple’s minimalist tendency rather than exposing real options, but I digress.
To evaluate video capture quality on the X900, I took videos at the standard bench location at around the same time. The Medfield platform uses Imagination’s VDE285 video encoder. 1080p30 video recorded on the X900 is encoded at 15.0 Mbps H.264 Baseline with 1 reference frame. 720p30 video from the rear camera is encoded at around 8 Mbps with the same parameters, but interestingly enough front facing 720p30 video is encoded at 12Mbps. All three include 320 kbps AAC stereo audio.
Baseline H.264 is about par, but not the high profile that we’ve seen being done on other platforms like Exynos 4xxx or OMAP 4. Thankfully the baseline bitrate is good enough to produce good quality results, but again turning the encode parameters up a bit would enable better results with the same bitrate.
As we always do, I’ve uploaded the bench videos to YouTube and also made them available for direct download if you want to look at them without the transcode. Some small interesting points are how the videos are saved with a .3gp extension instead of the more common .mp4 (haven’t seen .3gp in a while, even if it’s acceptable), and also the 1080p video field of view is much narrower than the 720p field of view (clearly a center crop is being taken). Those notes aside, I have no issues with the 1080p video quality that’s produced, it looks good and has continuous auto focus. The 720p video has some weird decimation artifacts from downscaling, but nothing too bad, and 1080p maximum is usually what I scrutinize anyways.
Display
I mentioned earlier that it’s interesting that Qualcomm, Intel, and others have identified and gone with WSVGA (1024x600) for their reference designs at around 4“. In the case of the FFRD/X900, it’s 4.03” WSVGA TFT-LCD. That works out to 295 PPI and looks extremely attractive in person. I find it quite hard to pick out individual pixels; this is definitely a high PPI display that’s right up there with the best. In addition, the capacitive digitizer is excellent; I have no complaints about tracking accuracy at all, again just like you’d expect from a shipping device.
The X900 also goes pretty bright, at 375 nits, and has good contrast at around 800. I’m impressed with the display again just because up until recently seeing good LCDs outside of anything but the iPhone 4/4S has been a rarity. The HTC One X and Rezound are probably the only other devices in recent memory that surpass, but suffice it to say Intel/Lava haven’t skimped here.
As you can see from the gallery above, the display's performance is pretty good. CIE shows primaries and secondaries are close to where they should be, but not perfect (but way better than AMOLED insanity). Unfortunately color temperature is around 7500K constantly, and gamma is a bit sporadic. It’s worth dealing with those inconsistencies for that high PPI though.
Outdoor viewing angles are also pretty good, basically what we're used to for LCD displays outside in direct sunlight.
Cellular Performance
Cellular connectivity on the X900 is courtesy Intel’s Infineon acquisition, and uses the popular XMM6260 / X-Gold 626 baseband that we have seen in numerous other HSPA+ smartphones, including Galaxy S II and Galaxy Nexus, among others. Obviously Intel/Infineon knows how to implement its own baseband, and has done so in the device. The X900 is thus limited to GSM/UTMS for its air interfaces. The interesting part is that it’s another one of the pieces of the puzzle which Intel has in its portfolio for eventual inclusion in some upcoming SoC, and on the other hand is a major component built for an Intel phone not at an Intel fab, instead at TSMC on their 40nm process for baseband and 65nm CMOS for the UE2 transceiver, with an ARM11 at its core.
I mention these things since it’s one of the next areas that Intel will need to work on - both taping out its existing designs on its own 32nm or 22nm processes for manufacture at Intel fabs, and eventually making this another x86 powered device. Eventually baseband tasks will be de-elevated from something existing on essentially its own discrete SoC to just another task for a hypervisor to shuffle around on the main multicore SoC.
Lava Xolo X900 - Network Support | |||||
GSM/EDGE Support | 850 / 900 / 1800 / 1900 MHz | ||||
WCDMA Support | 850 / 900 / 1900 / 2100 MHz | ||||
Baseband Hardware | Intel/Infineon X-Gold 626 / SMARTi UE2 Transceiver | ||||
HSPA Speeds | HSDPA 21.1 (Cat.14) / HSUPA 5.76 (Cat.6) - 3GPP Rel.7 |
Anyhow back to the X900 - it’s a quad band WCDMA and GSM/EDGE device, with support for everything but AWS basically. That’s good enough for HSPA+ on almost everything except those on carriers who run AWS. X-Gold 626 supports 64QAM on the forward link, meaning HSDPA up to category 14 / 21.1 Mbps. The reverse link has basically stayed the same for a while now on WCDMA at category 6 / 5.76 Mbps. In addition the device supports 3GPP Release 7 features which makes it HSPA+. The X900 also implements WCDMA receive diversity.
I went ahead and ran just short of 100 tests using the trusty speedtest.net app on the X900 in my AT&T market which runs WCDMA on PCS 1900 MHz.
At this point HSPA+ 14.4 on AT&T is fairly well understood, running these is more validation that there’s nothing wrong with cellular on the device, and unsurprisingly there isn’t - again Intel knows how to implement its own baseband without issue, and with good performance.
WiFi
For WiFi and Bluetooth, the X900 uses a TI WiLink WL1271 series 6 combo chip which supplies 802.11b/g/n single spatial stream on 20 MHz channels with the short guard interval rate of 72 Mbps, and bluetooth 2.1 + EDR support. Some of the Intel documentation shows a TI WL1283 being used (which is WL 7.0 and includes a GPS baseband) and I don’t doubt that other Medfield platforms may implement WL128x or even WiLink 8 series with GNSS, however the X900 is definitely WL1271.
In our WiFi test which consists of a 100 MB PDF loaded over an 802.11n network, the WL1271 does pretty well, just as expected.
GPS
Like the TI WiLink series part, it seems that some Medfield designs include the WiLink 7 series with a GPS basbeand, and others include the more common SiRF Star 4 GSD4t GPS which we have seen in a ton of different smartphones, again including many Samsung phones.
I have no complaints with the GPS lock speed or quality on the X900, it’s speedy and accurate, and works well. I navigated around town with the device and never encountered any problems.
NFC
The X900 also includes NFC support, courtesy the ubiquitous NXP PN544 controller. The smartphone also includes the stock tag reader application, though NFC ships disabled. I tested it on the NFC tag sent with the Nexus S an eternity ago and it worked perfectly.
It’s safe to assume that with the Android 4.0 update beaming will be enabled.
Voice and Speakerphone
The X900 includes some common mode noise suppression components, including a primary and secondary microphone and an Audience eS305 voice processor.
We’ve seen the A102x series in devices before, including the Nexus One, iPhone 4, and numerous other popular smartphones. The reality is that good noise rejection so the far end hears nothing of the ambient sound around you is important both for making calls sound better, and also for increasing the idle or blanking periods on the reverse link. The X900 is my first time hearing the eS305 in action, and to test we did what we normally do by placing a call in front of some speakers, increasing volume, and speaking into the handset while recording the call on the far end on another handset.
I can’t emphasize enough that during the most taxing parts of this recording, I cannot hear myself speak at all. eS305’s performance is great, just like we’ve seen with their other solutions in devices where we’re able to identify its presence. The reality is also that using an array of microphones and some common mode noise rejection is basically the status quo for a high end smartphone right now.
Speakerphone on the X900 is split between the two bottom speaker jacks, and isn't quite as loud as I'd like. We measured as usual with an Extech digital sound data logger 3 inches above the device.
For Intel, answering the looming ARM threat is obviously hugely important for the future, and it recognizes that - look no further than the restructuring of the Intel Architecture Group. The fire was lit with the impending arrival of Windows On ARM (WOA), at which point the line between traditional ARM-dominated smartphone/tablet SoCs and a real desktop class compute platform will start getting blurry, fast.
The other trend in the SoC space is slowly arranging all the pieces of the puzzle to truly deliver a complete System On Chip. In addition to CPU, GPU, and video encode/decode, those who will be the most successful and emerge as dominant players in the SoC space will need to bring baseband, GNSS, bluetooth, WLAN, and RF all onboard. Almost everyone gets that trend - Nvidia is adding baseband with Icera, Qualcomm has baseband and has added WLAN and Bluetooth with Atheros, Intel added baseband with Infineon and ISP with SiliconHive. Further, it has Gen graphics in the future for both GPU and video encode/decode. Look no further than the last slide of one of its slide decks and you'll see an illustration showing precisely what I'm talking about - pieces of the puzzle coming together.
We understand the motivation for building a smartphone SoC (computing is going even more mobile) and the integration necessary to get there (Intel owns a lot of IP blocks + Moore's Law), so how did Intel's first attempt fare? In short, reasonably well.
The Atom Z2460 in the X900 is a competent dual-core Cortex A9 competitor with competitive battery life and power draw, and no doubt Z2580 (its dual core, SGX544MP2 high end counterpart clearly targeted at Windows 8 platforms) will be equally as competitive against quad core A9s. If Intel's goal with both Medfield and the X900 was to establish a foothold in the smartphone SoC space and demonstrate that it can indeed deliver x86 in a smaller form factor and lower power profile than ever before then it truly is mission accomplished.
The x86 power myth is finally busted. While the X900 doesn't lead in battery life, it's competitive with the Galaxy S 2 and Galaxy Nexus. In terms of power efficiency, the phone is distinctly middle of the road - competitive with many of the OMAP 4 based devices on the market today. If you've been expecting the first x86 smartphone to end up at the bottom of every battery life chart, you'll be sorely disappointed.
There is however a big difference between middle of the road and industry leading, which is really the next step that we need to see from Intel. If Motorola is able to fit a 23% larger battery in a significantly thinner phone (Droid RAZR) then we need to see the same with Medfield. As Intel's major branded launch partner, we have high hopes that Motorola will deliver just that later this year.
The performance side is obviously even more competitive. Atom isn't always industry leading in our tests, but the X900 is rarely more than a couple places away from the top (with the exception of GPU performance of course, but that's a matter of licensing a different IP block in future versions). For a reference design that an Intel partner can just buy, barely customize, and ship - that's not bad at all. Smartphone vendors spend a considerable amount of time building phones that perform well - Intel's offer to internalize much of that can be either scary or amazing depending on who you're talking to.
There's always going to be room for design and software customization, but ultimately only those vendors who are good at those types of things will be able to survive if Intel's direct FFRD route succeeds. It's unsurprisingly very PC-like, where differentiation doesn't really happen at the motherboard level but rather at the system level. I can see both good and bad that could come of this, but the initial outcome should be positive. The results of this initial FFRD turned commercial device demonstrate that Intel is absolutely a competent system integrator itself, with an awesome display, camera, and other component choices.
The software compatibility story, like the concern over power consumption, is also a non-issue. The vast majority of apps we tried just worked, without any indication that we were running something intended for a different instruction set. There are still a few rough edges (e.g. Netflix), but if Intel is able to get things working this well at launch, the situation will only improve going forward.
Ultimately Intel's first smartphone is a foot in the door. It's what many said couldn't be done, and it's here now. What it isn't however is a flagship. To lead, Intel needs an updated Atom architecture, it needs to be on 22nm, and it needs a faster GPU - at a minimum. All of this needs to come in a reference design that's not just good enough, but better than the rest.
On the one hand it's a good thing that you can't tell an Intel smartphone apart from one running an ARM based SoC, on the other hand it does nothing to actually sell the Intel experience. Intel is never taken seriously in markets where it relies on being good enough, and it moves mountains in those where it's the best. That's what Intel needs to really build credibility in the smartphone space. A little was earned by getting this far, but its reputation will be made based on what happens next. There's obviously a strategy here, but I'm curious to see it unfold. Intel can be a fierce competitor in any space where it feels threatened. What I'm waiting for is that Conroe moment, but in a smartphone.
We waited years for Intel's first smartphone, now the question is how long do we have to wait for the first irresistable one?