MIPS Tempts Hackers With Raspbery Pi-like Dev Board

DeviceGuru (1136715) writes "In a bid to harness the energy and enthusiasm swirling around today's open, hackable single board computers, Imagination Technologies, licensor of the MIPS ISA, has unveiled the Creator C120 development board, the ISA's counter to ARM's popular Raspberry Pi and BeagleBone Black SBCs. The MIPS dev board is based on a 1.2GHz dual-core MIPS32 system-on-chip and has 1GB RAM and 8GB flash, and there's also an SD card slot for expansion. Ports include video, audio, Ethernet, both WiFi and Bluetooth 4.0, and a bunch more. OS images are already available for Debian 7, Gentoo, Yocto, and Arch Linux, and Android v4.4 is expected to be available soon. Perhaps the most interesting feature of the board is that there's no pricing listed yet, because the company is starting out by giving the boards away free to developers who submit the most interesting projects."

Comments

Sweet

[Anonymous Coward]

I imagine this'll turn up in CS courses that use Patterson and Hennessey's Computer Organization and Design textbook, which uses the MIPS ISA as the canonical example.

no price?

[Anonymous Coward]

The entire appeal of the raspberry pi was that it cost only $35. This new thing, you won't even tell us the price. If you need to ask, you can't afford it...

Re:no price?

[gigaherz]

It's a MIPS board. I have been waiting for this for SO long that I'd consider anything with less than 4 digits. And probably decide not to get it if it turns out to be > $200. I don't apply for the free ones since I just want to toy around with it, not do some specific project with it. ;P

Re:no price?

[TheRaven64]

There's no price yet because they're giving away the first production run to people who are going to do interesting things with them. Unfortunately, this is a really bad time to do anything MIPS related (and I say this as someone who hacks on a MIPS IV compatible softcore and the LLVM MIPS back end). Imagination has just released the MIPS64r6 and MIPS32r6 specs. These are the biggest revisions to the MIPS ISA since MIPS III, which introduced 64-bit support. They've removed a load of legacy crap like the lwr and lwl instructions and the branch-likely instruction family and added things like compact (no delay slot) branch instructions, the requirement that hardware supports unaligned loads and stores (or, at least, that the OS traps and emulates them), and added much better support for PC-relative addressing. The result is a nice ISA, which is not backwards compatible with MIPS32r2 or MIPS64r2, the ISA that these boards use. Any investment in software for MIPS now is going to be wasted when products with the new ISA come out.

Re:no price?

[LoRdTAW]

It doesn't always have to boil down to price. This is the same argument over and over again from some maker/hacker types who want to turn platforms into religions.

The Raspberry Pi is a lackluster board with a crummy SoC and limited I/O and no FPU. Not to say that the Raspberry Pi is total crap, it does its intended job very well and there is a lot of community support. Plus where else can you buy a $35 board that runs Linux and X with HDMI USB and Audio?

But it falls flat in a few areas that is frustrating. First off it has *ONE* PWM output. Anyone looking to use this for motor control has to add an external PWM chip. Not a big deal but an annoying one. Next problem is there is the Ethernet is a USB-Ethernet chip on board, there is no hardware Ethernet NIC on the SoC which robs the CPU of cycles. Next up, and this is my gripe with many boards: no high speed interface. There is so much more these boards could do if we could attach an FPGA to them. Sure there is SPI but it simply isn't fast enough for certain things. The only board that can do this is the Beagle Bone which gives you an external bus interface but that disables the HDMI as the pins are shardes on the SoC. So its a trade off.

What I want to see in a dev board: dual core SoC w/FPU, 1GB RAM+, GPU, HDMI, SD card, SPI, I2C, 6-8 channels of 16 bit PWM, 8 channels of Analog 12bit-16bit, hardware 10/100 or gbit, 4xUSB host, *external bus interface not shared with I/O*. That's it. Just let me plug an FPGA daughter card that gives me the option to load bit files from the CPU and we are golden. Then we can do what ever crazy thing we want: more custom PWM (e.g. directly drive 3 phase bridges), quadrature encoders, faster ADC's, delta-sigma DAC's, high speed I/O, custom bus interfaces, etc. And make it cost $75. We are close to having a board like this, we just need the interest and the right SoC.

Re:no price?

[topham]

Sold it cheaper? Why?

The Rpi has an excellent price, it's low enough that price is not the deciding factor on using it.

Re:no price?

[obarthelemy]

What makes the Pi attractive is relative openness.
There are a lot way more powerful Android sticks that end up cheaper ( http://www.geekbuying.com/item... , $43 w/8GB Flash, WiFi, BT and a PSU are included)
The hardware could be more open, but the libraries and documentation for the CPU/pinouts, and above all the GPU, would require a lot of work and hit a lot of walls. It's telling that the Pi's competitors are all chipset-maker driven.

Re:no price?

[TheRaven64]

Wouldn't it be just a matter of re-compiling your code though?

Assuming that your code doesn't do anything that is vaguely MIPS specific. If it is, then there is little benefit in using MIPS32r2 now - ARMv7 is likely to be closer than MIPS32r2 to MIPS32r6 in terms of compatibility with C (or higher-level language) source code compatibility.

I love MIPS and, that is the case in large part, because of its current instruction set. It seems like a bad idea to mess with the current instruction set and break backward compatibility. Why did they decide to do that?

Basically, because the MIPS ISA sucks as a compiler target. Delay slots are annoying and provide little benefit with modern microarchitectures. The only way to do PC-relative addressing is an ugly hack in the ABI, requiring that every call uses jalr with $t9 in the call, which means that you can't use bal for short calls. The lwl / lwr instructions for unaligned loads are just horrible and introduce nasty pipeline dependencies. The branch likely instructions are almost always misused, but as they're the only way of doing a branch without a delay slot there's often no alternative.

Re:no price?

[tepples]

Wouldn't it be just a matter of re-compiling your code though?

Good luck convincing publishers of existing proprietary applications, libraries, operating systems, and drivers to recompile their code.

Re:no price?

[mark-t]

I would suggest that the much bigger problem with a lack of price means that it's currently impossible to get one at all, since the giveaway period has also expired.

Re:no price?

[Fnord666]

There's no price yet because they're giving away the first production run to people who are going to do interesting things with them.

The program is now closed anyway, so I guess we'll just have to wait and see

Thanks for your interest in the MIPS Creator CI20 development board. While the current programme is now closed, stay tuned for more information as the Creator programme progresses as part of the Imagination community.

Re:no price?

[niftymitch]

It doesn't always have to boil down to price. .......

The Raspberry Pi is a lackluster board with a crummy SoC and limited I/O and no FPU. Not to say that the Raspberry Pi is total crap, it does its intended job very well and there is a lot of community support. .........

OK I am a child of the 60s. Time not the drug thing...

The Raspberry Pi is an astounding teaching tool.
It is open at all the important levels (hardware and software) that
are impossible or impracticable for a student and class to explore
on any other computer.

At the current price it is less expensive than most textbooks.

It supports all the tool chains a student needs support on and
supports virtually any programming language worth teaching
and worth learning.

The last turn of the Raspberry Pi gave it more USB ports and
a better connector for the OS flash media (mSD). All good stuff.

I have built small MPI clusters with them and noticed that I quickly
ran into problems that plague programmers of million dollar clusters that I have
worked on. The Beaglebone Black is a nice baby step forward in ARM land.

This MIPS board that started this does need to match the price and features
of the R-Pi or BBB if it is to have legs. I am a fan of the MIPS ISA but with
modern compilers the ISA is almost a don't care.

Re this MIPS board do wish it had dual+ GigE networking. I do wish it
had more DRAM. I do wish I knew more about it in detail.

Of interest the SD card, case and wall wart power supply cost as much as the
board itself. All together it costs less than most textbooks....

But golly folks do not ignore the Raspberry Pi.

Re:no price?

[TheRaven64]

Just curious, what's so wrong with branch with delay slot and isn't that more native way to look at branch ?

They're a pain for people on both sides of the ISA.

The compiler has to find an instruction that can run after the branch. This is normally trivial for calls, but for conditional branches within a function it's often difficult to find an instruction that you can put there. It has to be one that is either from before the jump (or in both basic blocks after the jump), but that the branch doesn't depend on (because it's executed after the branch instruction). This means that you quite often end up padding the delay slots with nops, which bloats your instruction cache usage. On a superscalar implementation this is the only cost, but on a simple in-order pipeline it's also a completely wasted cycle.

On the other side, it's a pain to implement. It made sense for a three-stage pipeline in the original MIPS, because you always knew the next instruction to fetch. A modern simple pipeline is 5-7 stages though, so your branch is still in register fetch (if there) by the time the delay slot is needed. It doesn't buy anything and it means that, if you're doing any kind of speculative execution (even simple branch prediction, which you really need to do to get moderately good performance) then you have an extra dependency to track - you can't just use the branch as the marker and flush everything after it, you need to do some reordering. In a superscalar implementation, you need to do even more complex things in register renaming to make it work.

Fragmented

[Circlotron]

I can see this small board stuff getting as fragmented as the bazillions of Linux distributions available. Choosing which board you want to play with will get as complicated as choosing a phone plan. Too much choice is not good. What the right amount of choice is, I don't know.

Re:competitive features? generally available? not

[Bert64]

Linux support for MIPS is actually pretty good, and has been around at least as long as ARM support if not longer... The rest of the toolchain, like gcc etc also has good MIPS support. There is already 64bit MIPS support in the Linux kernel and has been for a long time too, MIPS is actually one of the oldest 64bit architectures out there.
MIPS would actually be better off focusing on this, as they have a good head start on ARM when it comes to 64bit and multiprocessing. I used to have a 24 cpu (discrete cpus, not cores) 64bit MIPS years ago in the form of an SGI Onyx.

No, that makes it uninteresting

[drinkypoo]

Wake me up when there is pricing, and I'll decide how interested I am. I'm not interested in a product which could cost $INFINITY dollars.

Re:Patent on this new feature

[TheRaven64]

No idea. I don't know if the instructions for computing PC-relative addresses in an ISA without an architectural PC are patentable. They also exist in RISC V (not sure which came first), so if they do then it's going to be a problem for Kriste et al. Nothing else in there is especially novel: like ARMv8, it's a nicely designed compilation target, but it doesn't do anything that's especially exciting.

I didn't look at the floating point stuff in much detail, so there may be something there, although the biggest changes in recent versions of the MIPS specs have been that they're more closely aligned with the IEEE floating point standards, so it's hard to imagine anything there.

The biggest difference between MIPS64r6 and ARMv8 is that the MIPS spec explicitly reserves some of the opcode space for vendor-specific extensions (we use this space, although our core predates the current spec - it's largely codifying existing opcode use). This allows, for example, Cavium to add custom instructions that are useful for network switches but not very useful for other things. ARMv8, in contrast, expects that any non-standard extensions are in the form of accelerator cores with a completely different ISA. This means that any code compiled for one ARMv8 core should run on any ARMv8 implementation, which is a big advantage. With MIPS, anything compiled for the core ISA should run everywhere, but people using custom variants (e.g. Cisco and Juniper, who use the Cavium parts in some of their products) will ship code that won't run on another vendors' chips.

Historically, this has been a problem for the MIPS ecosystem because each MIPS vendor has forked GCC and GNU binutils, hacked it up to support their extensions, but done so in a way that makes it impossible to merge the code upstream (because they've broken every other MIPS chip in the process) and left their customers with an ageing toolchain to deal with. I've been working with the Imagination guys to try to make sure that the code in LLVM is arranged in such a way that it's relatively easy to add vendor-specific extensions without breaking everything else.

Imagination doesn't currently have any 64-bit cores to license, but I expect that they will quite soon...

no Gbit, no sale

[dltaylor]

There appears to be enough RAM and enough compute power, but the Ethernet interface is pathetic. Even in an inexpensive experimenters' board, GBit Ethernet should be standard. For one thing, it's hard to judge the real processing power needed (as a fraction of the available) for networking, when the network, itself, is the bottleneck.