Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Hardware

Imagination Tech Announces MIPS-based 'Warrior P-Class' CPU Core 122

MojoKid writes "Imagination Technologies has announced the first CPU based on its new version of the MIPS architecture. The new P5600 chip (codenamed Warrior) is a 32-bit CPU based on the MIPS Series 5 architecture and is designed to challenge companies like ARM in the embedded and mobile markets. Major features of the new chip include: support for 40-bit memory extensions, or up to 1TB of RAM, a 128-bit SIMD engine (Single Instruction, Multiple Data), and Hardware virtualization (MIPS R5 can virtualize other machines in hardware). The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400. According to IT, the chip is capable of executing 3.5 DMIPs/MHz in CoreMark, which theoretically puts the P5600 on par with the Cortex-A15."
This discussion has been archived. No new comments can be posted.

Imagination Tech Announces MIPS-based 'Warrior P-Class' CPU Core

Comments Filter:
  • That's a bit dated, isn't it?

    • Re:32 bit? (Score:5, Insightful)

      by jockm ( 233372 ) on Monday October 14, 2013 @04:34PM (#45126217) Homepage

      It depends what you are doing. I don't think anyone is making servers or desktops out of this, and even with recent forays into 64bit ARM (Apple's A7 for example) 32 bit is far from dead. That being said MIPS64 has been around for quite a while, so I don't think it will be a problem to adapt to it at some point in the future.

      • Can anyone enlighten us why MIPS has been much less visible than ARM? Their business model and CPU architectures are similar nowadays. Why are people seriously trying to build servers based on the brand new and untested ARMv8 architecture, while ignoring MIPS64 (in existence since 1999)? Is is all about ARM being cheaper and the network effect?
        • If MIPS would sell a cubieboard sized SBC, as open as Beagle, Panda or Cubie (more open than the raspberry pi), sign me up.

          • Re: (Score:2, Informative)

            by Anonymous Coward

            Go to ARM.com, try and download the ARM ISA, fail, sign NDA, get ISA.

            Go to MIPS.com, download MIPS64 ISA, done.

            Tell me again how ARM is more open than MIPS?

            • Re:32 bit? (Score:4, Insightful)

              by fuzzyfuzzyfungus ( 1223518 ) on Monday October 14, 2013 @06:18PM (#45127169) Journal
              In either case, the main stumbling block to 'openness' (from the perspective of people who don't have the cash to implement a core and get it fabbed, or even buy a run of a pre-cooked design, and don't want to enjoy the pleasures and efficiencies of implementing their CPU in an FPGA) isn't really the CPU ISA; but the fact that the SoCs you can actually buy tend to be coupled with GPUs that make Nvidia look like a model of transparency and AMD a model of driver-writing competence.

              If memory serves, the rPi's SoC depends on a fairly massive binary blob driver and a 'VideoCore 4' GPU thing that is right up to Broadcom's usual standards for openness in documentation, which is presumably what the grandparent poster doesn't like.

              Most of the punchier ARM options aren't a whole lot better (though some of them are somewhat less weird). Certainly, given that Imagination Technologies is already a supplier of GPU architectures to ARM licencees (and occasionally Intel), I'd assume that any MIPS SoCs you end up being able to buy will be approximately as bad as the ARM scene, maybe a bit worse.

              Now, if you do want to bake your own CPU, MIPS64 is probably a better option (though don't they still have a few patented instructions? I vaguely remember some flap concerning the legal status of that Chinese MIPS-and-national-pride CPU a few years back...)
              • by Anonymous Coward

                If I'm baking my own cpu, licensing a core is the least of my worries. Unless it's in an FPGA, it makes no difference to me whether the SoC I'm using has a free core or a licensed core in it, as long as the ISA is public, since in both cases I can't go in and change it (alas, I don't have FIB deposition/erosion tools at my disposal). It's just a piece of silicon that either works right, or I'm SOL.

                You're right about the GPUs, pretty much every ARM SoC GPU is Ninja Destruction Agreemented beyond all hell. Th

              • One of the punchiest ARM options is the quad-core RK3188. It has the least punchy GPU in the class, a clock-increased (by 25%) Mali400. However, this is the ARM-coupled GPU with the most functional OSS driver. It is already possible to boot Linux on RK3188 directly, and play Quake3, with an OSS driver. OHI, there is now an installer. [g8.net] However, it does not appear that the installer includes recovery. Hmm, reading further, it does not include the accelerated video driver or working bluetooth either, so I guess

            • You don't need an NDA to download the ARM architectural specifications, you just need to register on their site. Which you need to do for MIPS as well.
          • by hattig ( 47930 )

            This would be a very good idea for Imagination to work towards - a "Raspberry MIPS" based around this MIPS core, a low-end current-gen Imagination GPU, and some other standard features. Get it out into the market at a cheap price, support it (the ecosystem is as important as getting it out there in the first place) and you could get a lot of people using their hardware, testing software by using it, etc.

        • by hedley ( 8715 )

          I think it stems from the initial directions each co took.

          MIPS started from a 32bit Stanford grad project (MIPS-X) spun out to become the R2000 workstation class CPU. No hint of embedded arch at all at that time.
          They steamed on finally hitting 64bit archs relatively quickly. Once they got to the R4K32 series and upon adding MIPS-16, they had a small footprint embedded soln but...

          ARM started from basically a hobbyist computer, already with some small footprint pedigree built in. Very quickly Thumb was adopte

        • by Bert64 ( 520050 )

          64bit MIPS has been around a lot longer than 1999, SGI were using them in the early 90s...
          Availability of current designs to play with however is a problem, i tried very hard to buy one of the loongson mips designs from china and i just couldn't get one anywhere.

        • by hattig ( 47930 )

          ARM got the mobile phone market early on - very early on (late 90s) - presumably due to a very hard working sales team and an established pedigree in mobile designs (Apple Newton, for example), as well as proven low power (MIPS wasn't there then, Hitachi was with SH3/4 which was used in early Windows CE fliptops). They also had Java support (hardware assistance) which was very big on the client at the time.

          ARM clearly has very good engineers who work with their customers - this means a lot when you're licen

      • by Anonymous Coward

        MIPS started out as a workstation and server killer micro (I worked with them in the early 90s), ARM started out more modestly as being cheap, quite fast and small (a 6502 replacement for the Archimedes). Then Apple threw some money at it to make a low power CPU for the Newton. It's in the history.

      • by tlhIngan ( 30335 )

        and even with recent forays into 64bit ARM (Apple's A7 for example) 32 bit is far from dead.

        The main reason Apple with with ARMv8 (the big difference between ARMv7 and ARMv8 is basically 64-bit) is that the 64-bit architecture (AArch64) is way more efficient than 32-bit (AArch32). It's a lot easier to speed up the 64-bit system as it gets rid of a lot of legacy AArch32 features that get in the way of a modern superscalar design CPU.

        Surprisingly, things like conditional execution, great back in the 80s, are

    • by jockm ( 233372 )

      From TFA:

      This new core is the first of a family, with later 64-bit chips to follow. The 64-bit warrior chips, when they do launch, will be fully backwards compatible with 32-bit software, much like the 64-bit implementations of ARM and Intel/AMD.

      • In that case, why 32-bit first, when the market is already @ 64? They can start w/ something like an R4600, and just release 32-bit versions of that chip whenever it's needed. It's easier to chop then to scale up.
        • by Goaway ( 82658 )

          The market is still very much at 32 bit. You are just confused about what "the market" is. It is not desktop PCs or servers.

          • I wasn't thinking about desktops or servers. If the competition is ARM, it's pretty obvious that the market in question is tablets & phones. But even there, 32-bit ain't gonna cut it any more: memory sizes can easily exceed 4GB, and in those sort of designs, you don't want to go w/ PAE. Given all that, Imagination Technologies is doing fine w/ MIPS, but IMO making a wrong move going 32-bit.
            • by kriston ( 7886 )

              From TFA:

              "Support for 40-bit memory extensions, or up to 1TB of RAM rather than the typical 4GB limit associated with 32-bit processors. It's worth noting that there's typically a significant performance hit associated with this kind of work-around for memory addressing in 32-bit chips."

              • Precisely, and hence my original question - why not simply go 64-bit, instead of eating this performance hit?
            • by Goaway ( 82658 )

              There's like a single 64-bit ARM processor in existence yet. The market is still pretty much entirely 32-bit, and it will be a long time before most of it moves to 64 bit. Sure, in some years it will be different. But not now.

    • by Anonymous Coward

      Not really, especially on embedded.

    • That's a bit dated, isn't it?

      If the cores themselves are merely 'competitive' with A15s, probably not. I'm sure that there is some special application out there that needs minimal CPU power and 64TB of RAM; but if the things do 32 bit address spaces with 40-bit PAE(or whatever the equivalent acronym is for MIPS), that covers your just-under-4-usable-Gigabytes SoC configuration, and would also cover fairly large interconnected systems, for applications that have lots of lightweight processes (which would be the only thing you'd use a sw

    • by Misagon ( 1135 )

      The "64-bit" Intel and ARM have more to do with new instruction set architectures than the size of a processor word or the address space.
      The new instruction sets are more capable than the ones before, not just in the larger size of pointers and words but also in other ways, such as in the number of registers. For instance, ARM's "64-bit" ISA has 32 integer registers instead of 16.

      MIPS32 is already a very capable instruction set, with 32 integer registers from the start. The 64-bit MIPS instructions is just

    • 32-bit is the norm on phones and tablets. This company is best known for their mobile GPU found in such products - PowerVR.

    • Precisely!!! At this day & age, if your 32-bit CPU requires 40-bit memory extensions, then why bother making it 32-bit? Particularly when the architecture in question - the MIPS - has by now mature 64-bit implementations in MIPS IV & V? Incidentally, what do they mean by Series 5? MIPS V, if that's what they mean, is a 64-bit CPU - starting from the R10k onwards.

      I recall in the early 90s, when some companies such as QED & IDT did CPUs like the R4600: that would have been a fine template to

  • by Rinikusu ( 28164 ) on Monday October 14, 2013 @04:35PM (#45126235)

    COMPETITION IS GOOD.

    I'd love to see MIPS make a comeback. I've been looking for one of the looongson (?) netbooks for awhile now, just so I can have a MIPS Linux box to play with, but those seem hard to come by.

    • Ingenic make a few interesting MIPS devices - the iPPea TV http://www.ippea.com/ [ippea.com] is a $50 Android thumb drive computer that can be modded to run Debian chroot. They also supplied the SoCs for the Ainol Novo 7 MIPS tablets.
    • Competition is not necessarily good when ImgTech is involved. They have a pretty nasty reputation of not providing drivers that work outside of very narrowly defined Linux or Windows builds (not versions, builds, their drivers will break if they find themselves outside the "licensed" environment) they are directly involved with. They've colluded pretty nicely with Apple to have iOS devices having magical GPU performance superiority on their own, identical hardware, again, because they do not license drive
      • by fatphil ( 181876 )
        > They have a pretty nasty reputation of not providing drivers that work [...]

        You could simply have ended that sentence there. They're bodgers, full stop. When they deliver you the next version of the driver, it's in the form of a patchbomb which intersperses functional changes with cosmetic changes, so it's hard to see what's actually changed. I once even wrote a whitespace-changes remover *specifically* for IMG's patchbombs.

        And let's not even start on the fact that their drivers were clearly written fo
        • Their Windows drivers are nearly as bad as the Linux ones. One of the interesting anecdotes in the tablet PC community is the inability to Frankenstein a driver package with any combination of OpenGL, DirectX, Flash, and x264 acceleration. You only get to pick the former 2 or latter 2 at a given time based on driver version (or one or none in later drivers). The only PVR drivers with any merit are on OSX / iOS in the iShinys where magical OpenGL + x264 support exists (which would be more than enough for
    • I'm more interested in the competition that is represented by Intel's "Bay Trail" Atom. That thing might actually win some phone / tablet designs, and not just be relegated to Thin Clients and vastly underpowered also-ran Netbooks.

      If Chipzilla can finally bring something to market that makes the ARM crowd stand up and take notice, that will have much more effect than someone pulling MIPS out of the dustbin of architecture history.

    • Yeah, it's the only liberated netbook out there, according to RMS. I doubt it'll run Windows, so if you take one of those, load it up w/ gNewSense and run emacs on it, you'll have good company
  • That is a bit strange to count Integer operations. Most of the computations one do nowadays are mostly floating point. Also,there is no mention of memory bandiwdth and cache size. Though I'll stay tuned.

    • It has two Int/SP/DP floating point pipe lines in the SIMD unit

      • by godrik ( 1287354 )

        That means little. can it do vectout = cosine(vectin);? In how many cycle? can it do multiply-add in a single instruction and in a single cycle? Can it do that in EACH pipe?

        • There's a GPU core you know... Besides, it's not the CPU core but the memory bandwidth that matters.

          • by godrik ( 1287354 )

            TFA does not mention any GPU core. Did I miss something?

            People often say that the core does not matter, the memory bandwidth does. That is only true for applications doing "bookkeeping"

            The application defines how much "computation per byte" it does and you want an architecture that can play well with a wide range of "computation per byte". When the kernels are a little bit complicated, getting the right data to the core can take many instructions (so many cycles even if the data fits in L1 cache), so you wa

            • When ARM released the Cortex A15, there was no mention of a GPU. It's up to the SoC designer to integrate one.
              Imagination Technologies already have their own GPU that is up there with the rest of them, the PowerVR series.

              • When ARM released the Cortex A15, there was no mention of a GPU. It's up to the SoC designer to integrate one.
                Imagination Technologies already have their own GPU that is up there with the rest of them, the PowerVR series.

                The only thing that matters is that there's going to be a GPU core to take care of those operations so you won't be missing them.

                And, in ARM's case, there was the reference Mali GPU core...

            • Going down that road, you can discredit all RISC instructions sets on account of their lower code density.

              As for the "only true for applications doing "bookkeeping"", since MIPS is already used in embedded so it's not an issue there, what exactly are you doing aside from bookeeping on a mobile SoC that won't be moved into the GPU core?

    • by Anonymous Coward

      True floating point (float, double) performance does not really matter, except, sometimes, for games.
      There are also some special applications, like video decode, which rely on SIMD... or the GPU.
      For ordinary software, both in embedded (a car, an usb key, a digital camera, whatever) or in smartphones/tablets/computers, integer and memory are what makes the difference.

  • by Anonymous Coward on Monday October 14, 2013 @04:54PM (#45126435)

    You can still find plenty of MIPS based embedded cpus but they're getting more and more obscure.

    One of my very favorite things about the "smartphone revolution" is the proliferation of cheap ARM based SoCs. For a couple of bucks you can get a complete system in a package that runs on a couple of watts and runs circles around a high end workstation from a decade ago. (It's hard to belive 2003 was a decade ago.) And these aren't crippled micros. They're complete systems that run a real full fat operating system. Just look at the raspberry pi. Memory management On package DDR memory. Frame buffer with openGL aclleration and hardware video decoding. Amazing stuff.

    Point is, arm is everywher, easy, and cheap. What's the benefit of going MIPS? (Or SH3, or PPC..)

    • Obscure? You can buy a MIPS based embedded CPU right now from Digikey for $2.50 ea in single qty- the PIC32MX110 - it is M4K core based.

      • by aiadot ( 3055455 )
        Obscure as in not a main feature in the consumer market. MIPS, along side many other embedded architectures, are still present everywhere. The thing is that they're just yet another component and not something developers and engineers are whiling to spend money and time on(hence your couple of bucks PIC). You don't choose a microwave because it has a 64 bit quadcore ARM SoC with 2 GB RAM and and 64 CUDA cores, you choose it because it heats. The cheapest controller that can satisfy the specification is the
    • Re: (Score:2, Interesting)

      by Anonymous Coward

      It is not the problem of architecture but rather of MIPS company. I have worked on MIPS for many years and still do. MIPS architecture is not worse than ARM in any respect but MIPS company does not promote the architecture and therefore there are no inexpensive boards available. PIC32 is MIPS architecture but without the MMU. I found that when implemented correctly performance of MIPS is on par with ARM per MHz but ARM can clock higher in most common implementations. There is a perception of MIPS being slo

    • by AmiMoJo ( 196126 ) *

      All off Microchip's current PIC32 line is MIPS based, and their reps always push them aggressively when I talk to them. Their theory seems to be that they wanted a 32 bit microcontroller but didn't want to get into direct competition with ARM vendors.

  • Chips based on this new Core are a ways out.
  • by Anonymous Coward

    We've seen this before. Imagination blown to bits in the PC 3D-accelerator marketplace, and forced to withdraw with its tail between its legs. Now Imagination seems on the edge of admitting defeat in the hight-end ARM GPU market, and vanishing into this fantasy market of competing with ARM using its MIPS core.

    The problem Imagination has is that there are too many players in the ARM GPU space. ARM itself provides MALI cores, both cheap and nasty ones for all bottom end ARM SoC devices, and high-end ones for

    • by rsborg ( 111459 )

      At the moment, PowerVR is 3DFX (at the height of its success) strong in the ARM market, but faces the same problems that brought 3DFX's fortunes crashing down. PowerVR is currently used by Apple in all its non-x86 products. The important Chinese ARM chip companies are also starting to use PowerVR as well. PowerVR is in a golden age, but struggles to see a sunny future.

      Soon, basic OpenGL ES2.0 functionality on ARM SoC parts will return almost worthless to the GPU IP companies. Good enough acceleration for everything but proper games (which have yet to have an important impact on ARM devices) is in a hardware race-to-the-bottom, with too many excellent competing designs. This mirrors the end of value in the PC 2D video space, after years of excellent profit for companies like Hercules, S3 and Number-nine.

      This assertion is ridiculous. Smartphones and tablets will suck down all the graphics power-per-watt mobile GPU vendors can provide, as they are (and since the iPhone, have been) consumer-bought devices, where high-touch and bling win and win big. The differentiator is that, without massive enterprise control of spending, consumers will rightly choose the best graphics chip out there (enterprises just wanted enough to be able to surf spreadsheets and basic imagery - anything more was a liability - games c

    • by gl4ss ( 559668 )

      arm is trying to come up with things to compete with powervr products and arm doesn't use powervr so... what hand were they biting again?

    • the powervr 6 series, as seen in the the new iphone is currently the most advanced mobile gpu. Mali has always been one step behind powervr and adreno. Meanwhile, tegra has a disadvantage in the mobile space because it's not tile based and less power effient.

  • Odds on there being any open source drivers for this SoC? ImgTec is known for being hostile towards open source in general and delivering shit-grade binary-blob drivers that perform poorly and are rife with compatibility issues.

  • MIPS are for kids!

  • ... designed to challenge companies like ARM in the embedded and mobile markets. ...
    Major features of the new chip include: support for 40-bit memory extensions, or up to 1TB of RAM, a 128-bit SIMD engine (Single Instruction, Multiple Data), and Hardware virtualization (MIPS R5 can virtualize other machines in hardware). The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400. According to IT, the chip is capable of executing 3.5 DMIPs/MHz in CoreMark...

    hmm... seems a bit limited for a smartphone processor.

  • The P5600 core is being touted as supporting up to six cores in a cache-coherent link, most likely similar to ARM's CCI-400.

    The CCI-400 is not relevant here. In both MIPS and ARM worlds CPUs are now multi cores capable out of the box. One cluster can be configured from 1 to 4 cores typically, and here for this latest MIPS up to 6. The L2 management is handled as part of the cluster, which also typically supports coherency with external hardware accessing the L2 through one or several coherency port(s). The L1 cache(s), the L2 and the hardware are kept coherent inside a cluster (with some limitations at times on the low end, ther

  • by AaronW ( 33736 ) on Tuesday October 15, 2013 @04:40AM (#45130257) Homepage

    MIPS provides a much cleaner upgrade path going forward than ARM. MIPS64 is a very clean extension to MIPS32. All of the MIPS32 instructions behave the same except that they are sign extended to 64-bit. 64-bit ARM on the other hand has almost nothing in common with ARM32. The instruction encoding is totally different. The register definitions are also completely different. A lot of the things that made ARM ARM are gone such as conditional execution.

    I have spent many years working with MIPS and the last three working for a 64-bit multi-core MIPS manufacturer. MIPS also allows for clean extensions to the instruction set by various vendors, something ARM does not allow. For example, my employer has added a lot of instructions using coprocessor 2 (COP2) to add encryption, hashing, CRCs and more without breaking standard MIPS compatibility since COP2 is typically reserved for vendor extensions.

    MIPS page tables are also interesting. They are entirely managed by software, allowing the operating system to use whatever format they want for them. While some vendors have added hardware walkers they typically don't make much difference in performance.

    MIPS32 is fairly old and many implementations don't provide cache coherency which is a pain in the butt and impacts performance but the ones I deal with (Cavium's OCTEON processors) are fully cache coherent.

    As for doing encryption in the instruction set it allows full acceleration in user space without needing to deal with descriptors or DMA or userkernel transitions.

    Perhaps the only thing I would get rid of is the branch delay slot. It no longer really buys anything. The MIPS tools are much more mature than ARM, especially for 64-bit support. There are 32 general purpose registers with register 0 always being 0.

    With ARM64 most of the interesting ARM features are gone and in fact it looks a lot more like MIPS except that the instruction decoding is a lot more complicated. MIPS hasn't been standing still either. Extensions have been added for things like virtualization, 16-bit instructions (like Thumb) which usually don't buy you much and some multimedia extensions.

    I periodically work on MIPS assembly language with some of the bootloader stuff I do. All I can say is it's a joy to work with compared to X86 and is quite elegant. It's nice when I can have just a couple dozen lines of assembly language put a stack in cache memory and go straight to 64-bit C code. At this point it's quite hard for me to beat recent versions of GCC when it comes to optimizing code.

    I don't know why they're limiting their Warrior P-Class CPU core to 32-bits though. Moving to 64-bit MIPS is not very difficult. Personally I'd love to see 32-bit MIPS go away and just do 64-bit MIPS and use either the N32 or N64 ABI. N32 runs in 64-bit mode but with 32-bit addressing so you get all the advantages of 32-bit pointers and 64-bit registers.

    My employer makes MIPS processors with up to 32 cores and soon will have 48 cores and fully support Linux.

    • by adri ( 173121 )

      ... replying from my real account.

      Yeah, FreeBSD? dev boards? Any interest?

    • by tlhIngan ( 30335 )

      MIPS provides a much cleaner upgrade path going forward than ARM. MIPS64 is a very clean extension to MIPS32. All of the MIPS32 instructions behave the same except that they are sign extended to 64-bit. 64-bit ARM on the other hand has almost nothing in common with ARM32. The instruction encoding is totally different. The register definitions are also completely different. A lot of the things that made ARM ARM are gone such as conditional execution.

      All in the name of speed, actually. Conditional execution i

      • by AaronW ( 33736 )

        That is true. I am not that familiar with ARM personally. As I said most of my experience is with MIPS. I have been working with MIPS processors for the last 14 years at the device driver and bootloader level.

        The biggest issue with ARM64 right now is that it is still rather immature. It will take a while for things to fully stabilize. I will likely be working on it in the future since my employer is working on 64-bit ARM chips. The funny thing is that from what I looked at, ARM64 looks an awful lot like MIP

    • We're not going to do 32-bit cores only, we have 64-bit 'Warrior' CPUs in the pipeline too. 64-bit CPUs have area and power implications that are too complicated to go into detail here; for affordable mobile devices and microservers, 32-bit MIPS + XPA + EVA should be more than enough. Regards, Alex.
  • It's about time for a competitive MIPS mobile processor. The relatively open architecture is so well-supported by so many different operating systems for decades. I'm glad to see the modernization of MIPS32 as well as the MIPS64 Chinese Loongson supercomputing initiative.

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce

Working...