Introduction

One of ARM’s most tangible business advantages is its offer of both CPUs and GPUs to SoC designers. Anyone with experience in business to business relationships knows just how complex forming and maintaining a mutually beneficial collaboration can be. Setting up contracts, forming rapport, defining goals, and even just understanding documentation and technical content formatting all takes time. Unless there is significant benefit to investing in two different relationships and technologies, it is simpler (read: cheaper) to single source contributing components of a design. There are down sides of single sourcing (see Boeing 787 battery fiasco), but depending on a business’ capacity for risk, the savings are undeniable. Especially when ARM undoubtedly offers bundle pricing promotions.

When Imagination Technologies acquired MIPS Technologies in 2012 for $100 million, their goal was very clear – attack ARM. Imagination’s GPU business was already wildly successful, with design wins in a bevy of high end mobile devices including those from Samsung and Apple. Adding the CPU cores from MIPS, with their decades of history designing and licensing IP, strategically positioned Imagination opposite ARM’s licensing business. Imagination’s executives have also stated they are prepared to offer aggressive IP bundling discounts.

Looking at Imagination’s product, press, demos, and interviews, it appears they are not (yet?) positioning MIPS cores to combat ARM cores at the high end of the market. Rather, they appear focused on being a viable alternative to ARM in multi-threaded and low power workloads. In fact, the vast majority of MIPS cores are currently used in network infrastructure where threading and power efficiency are paramount.

Today MIPS is announcing a major launch: the Warrior I6400 core. Based on the 64-bit MIPS64 instruction set (release 6), the Warrior I6400 core is the middle-class CPU core in a family of three, each targeting a different point in the power/performance curve. Imagination is releasing the I6400 core last, which is at the middle of the pack balancing performance with power. Imagination has already released their high-end P56xx series and low-end M51xx series.

The most analogous ARM core to the I6400 appears to be the ARM Cortex-A53, but I6400 has some interesting features we haven’t seen in this market before and MIPS estimates it will deliver higher performance. I’ve produced a table here to help put performance in context. Note that only A57, A53, P5600, and I6400 are 64-bit processors.

MIPS and ARM High End IP Cores in Order of Performance
MIPS Manufacturer
Estimated
DMIPS/MHz/core
ARM
  5.0 Cortex-A57
  4.0 Cortex-A17
Cortex-A15
P5600 3.5  
I6400 3.0  
  2.5 Cortex-A9
  2.3 Cortex-A53
  1.9 Cortex-A7

Keep in mind that these processors use different instruction sets (ISAs) so DMIPS are not directly comparable. However, as they are both RISC processors, the DMIPS should hopefully be roughly comparable. I would like to use directly comparable CoreMark scores but only MIPS provides CoreMark numbers for their processors.

While no one can accurately predict if Imagination will grab additional market share away from ARM, we can educate ourselves on this alternative before it potentially arrives in our hands and homes. And besides, competition is always a good thing.

MIPS ISA & Mobile Devices
POST A COMMENT

84 Comments

View All Comments

  • Exophase - Wednesday, September 03, 2014 - link

    Hi Alex, could you clarify what you mean by this comment? Superscalar and in-order are completely orthogonal properties, and I would expect that it always behaves like an in-order design regardless of SMT. Do you mean that in SMT mode it can only dispatch one instruction per cycle from the same thread? If that's the case, surely this is something that can be dynamically configured based on active thread count and not a fixed property of the processor? Reply
  • MartinT - Thursday, September 04, 2014 - link

    I guess it is true strictly speaking that because of the two execution queues, it's limited to either super-scalar (single-threaded) or (scalar) multi-threaded operation at any one instant.

    I agree that it should read 'scalar' rather than 'in-order'.
    Reply
  • mthrondson - Sunday, September 07, 2014 - link

    To clarify - the I6400 can run superscalar on a single thread, or issue from two threads simultaneously. And it can switch which thread(s) it is working from on a per cycle basis. Reply
  • Guspaz - Tuesday, September 02, 2014 - link

    They taught us MIPS32 assembly in school. My impression was that it was enormously simpler to write by hand than x86 assembly, much less of a headache to work with. Of course, assembly is almost entirely irrelevant these days. Reply
  • patrickjchase - Tuesday, September 02, 2014 - link

    The main reason everybody learns MIPS (a.k.a. "DLX") in school is because the dominant architecture text was co-written by MIPS' inventor. Reply
  • Guspaz - Tuesday, September 02, 2014 - link

    That's entirely possible. To be honest, I don't remember which textbook we used for our processor architecture course. But it was a breath of fresh air compared to x86 or even SIC. Having all the registers be general-purpose and letting you specify which register to put results into in the instruction was much easier to work with when writing assembly by hand on paper than x86, where every register seemed to be special-purpose, with different instructions putting results in different abstractly named registers. Reply
  • Exophase - Wednesday, September 03, 2014 - link

    I've written x86 and MIPS assembly in real world applications, and personally I find both to be pretty annoying. When writing MIPS assembly, the poor addressing modes, delay slots, and range of immediates make it more cumbersome than x86. When writing x86 assembly, the lack of registers and three-address operands make it more cumbersome than MIPS. I haven't written much in x86-64, which I suspect is less annoying. Reply
  • dwforbes - Tuesday, September 02, 2014 - link

    It's worth noting that for Android developers using the NDK, coding for MIPS, ARM64, or x86-64, is in the vast majority of cases nothing more than a compiler flag. There is seldom extra work necessary unless you've specifically used inline assembly. Reply
  • Samastrike - Tuesday, September 02, 2014 - link

    I couldn't help noticing that the android logo used in the slide on the second page is holding a lollipop. Is this some confirmation of the official name when android L releases? Reply
  • Stephen Barrett - Tuesday, September 02, 2014 - link

    I had the same thought. Wondered if someone would notice that. I'll let everyone conjecture on that topic :) Reply

Log in

Don't have an account? Sign up now