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

  • flamethrower - Tuesday, September 02, 2014 - link

    For me, I know MIPS because the Sony PSP (handheld game console) uses a MIPS, the MIPS R4000. Reply
  • alexvoica - Tuesday, September 02, 2014 - link

    Nintendo 64 used MIPS too. On top of that, it was a 64-bit MIPS-based CPU! Reply
  • alexvoica - Tuesday, September 02, 2014 - link

    Can't sleep so I'm doing a live MIPS AMA at http://redd.it/2f9c14 if anyone wants to join. Reply
  • name99 - Tuesday, September 02, 2014 - link

    "
    If two load or store instructions arrive at the scheduler with adjacent addresses, the I6400 can "bond" them together into a single instruction executed by the load/store unit.
    "

    Armv8 has essentially the same thing. Details differ, but there is an instruction that loads/stores two registers to adjacent memory locations as one operation --- same idea to utilize the full width of the 128bit bus to the cache.
    Reply
  • Stephen Barrett - Tuesday, September 02, 2014 - link

    Good to know. That is an ISA update though so it requires compiler support and a recompile. The MIPS feature is part of their hardware scheduler so they can do it on 32 bit programs and 64 bit programs simultaneously and without any updates to the programs Reply
  • WonderfulVoid - Tuesday, September 02, 2014 - link

    Load/store dual (or double) is supported already on ARMv7A (infocenter.arm.com mentions support from ARMv5TE). These are 32-bit architectures but I am sure 64-bit ARMv8 can load/store 128 bits using equivalent instructions.

    Having the HW do it for you automatically is of course a nice feature. The end result might be the same.
    Reply
  • Wilco1 - Tuesday, September 02, 2014 - link

    Having separate instructions to do load/store double means smaller codesize - these instructions are commonly used during function prolog and epilog so they give significant gains. Reply
  • DMStern - Tuesday, September 02, 2014 - link

    The MIPS r6 architecture is very interesting, because in order to clear opcode space, a number of rarely-used instructions have been deleted. Some architectural wart have also been removed, maybe most notably the branch delay slot instruction. This is the first time anything has been removed from the base ISA since its creation in 1985. Reply
  • WonderfulVoid - Tuesday, September 02, 2014 - link

    Is MIPSr6 backwards compatible? Can you run earlier user and kernel space binaries on a MIPSr6 processor?
    Difficult to emulate the removed instructions if those opcodes are used for new instructions.
    Maybe there is a need for a mode switch, r6 mode or pre-r6 mode?
    Reply
  • DMStern - Tuesday, September 02, 2014 - link

    It is not backwards compatible.
    "In Release 6 implementations, object-code compatibility is not guaranteed when directly executing pre-Release 6 code, because certain pre-Release 6 instruction encodings are allocated to different instructions in Release 6."
    Removing the delay slot of course also breaks binary compatibility in a major way. The documentation (which you can download from ImgTec's website) claims r6 has been designed to make translation of old binaries efficient.
    Reply

Log in

Don't have an account? Sign up now