MIPS Claims "Best-In-Class Performance" With New RISC-V eVocore CPUs

[Akiko]

There are some very odd design choices here: there is a shared L2 cache and SMT, but no mention of L3 or SIMD extension.

Yeah, no "V" in the name of the core. This is actually a bit odd. But it used compressed instructions. It looks a bit like an embedded design and not like a performance core.

[igxqrrl]

You download an image, dd it to a card, put the card in the board, connect power, and away you go.

Undoubtedly some of that is difficult for some people -- especially disk destroyer -- or the instructions tell them they need to use Balena Etcher, but they have a Mac or Linux and think they need to get hold of a Windows computer.

None of this is any different for a Raspberry Pi. Last time I bought one it didn't come with a pre-flashed card either. Some of my RISC-V boards did come with a ready-to-go cards. Trying to think which ones. The Microchip Icicle for sure. I think the HiFive Unmatched did too. Oh, and the Pi 400. In general, higher priced boards.

A decent SD card costs as much as some of the cheap boards sell for, so if the manufacturer includes a preprogrammed card it doubles the apparent price -- and then people will complain they already have perfectly good cards lying around.

The other big problems are people using poor quality SD cards on a board that wants to actually do fast IO to the card. Or using a poor quality USB power adaptor that can't supply enough current for booting.

Well, I'm sufficiently intrigued to try ordering a couple clockworkpi boards to put in my turingpi...

[Gonk]

Who owns MIPS these days? Does anyone trust them enough to do business with them?

MIPS Technologies was part of Wave Computing of Santa Clara, California, but Wave went bankrupt. Wave emerged from bankruptcy as just MIPS (now based in San Jose), and is wholly owned by Tallwood Venture Capital of Menlo Park.

[Developer12]

Ah, another closed-source RISC-V chip.

Has RISC-V made any progress on their fragmentation problem?

So long as nobody can agree on a basic set of extensions and system peripherals (on standard interrupt controller and MMU interface, for example) that should be available in *every* linux-capable chip, you're just going to continue to see dozens of vendors peddling their own mixed bag and long list of out-of-tree patches.

Until that gets settled, I'm not buying any RISC-V hardware. Long-term support is anywhere from a complete gamble to a total impossibility. The exact opposite of what you get if you just buy a raspi.

[willmore]

MIPS Technologies was part of Wave Computing of Santa Clara, California, but Wave went bankrupt. Wave emerged from bankruptcy as just MIPS (now based in San Jose), and is wholly owned by Tallwood Venture Capital of Menlo Park.

Thank you for looking that up!

So, to summarize your post and others about the design, there's no MIPS in this MIPS other than the four letters in the name--neither institutional nor design. I wonder what happened to the people, ie, those who designed actual MIPS chips.

[Hugh]

Yeah, no "V" in the name of the core. This is actually a bit odd. But it used compressed instructions. It looks a bit like an embedded design and not like a performance core.

The Vector Extension was only ratified at the end of last year. It takes a while to implement it unless you want to risk being non-conformant (eg. cache-coherency issues with Alibaba's processor) https://riscv.org/announcements/2021...pecifications/

[microcode]

Who owns MIPS these days? Does anyone trust them enough to do business with them?

Imagination (PowerVR guys) bought them.

[microcode]

Ah, another closed-source RISC-V chip.

Yes, who told you it wouldn't be this way?

Has RISC-V made any progress on their fragmentation problem?

So long as nobody can agree on a basic set of extensions and system peripherals (on standard interrupt controller and MMU interface, for example) that should be available in *every* linux-capable chip, you're just going to continue to see dozens of vendors peddling their own mixed bag and long list of out-of-tree patches.

The interrupt controller and MMU are fully standardized, as is a base instruction set for linux-capable chips (RV64GC), this has been the case for years now. On the firmware side, UEFI is widely available. Not sure what you mean by fragmentation. I think it's likely that desktop class processors will have the V extension (ratified last year) in addition to G[MAFD]C, but it's the same sort of thing as SSE or AVX detection on x86, not a new problem.

[willmore]

Imagination (PowerVR guys) bought them.

You missed a bit:

"MIPS Technologies was part of Wave Computing of Santa Clara, California, but Wave went bankrupt. Wave emerged from bankruptcy as just MIPS (now based in San Jose), and is wholly owned by Tallwood Venture Capital of Menlo Park."

[Developer12]

Yes, who told you it wouldn't be this way?



The interrupt controller and MMU are fully standardized, as is a base instruction set for linux-capable chips (RV64GC), this has been the case for years now. On the firmware side, UEFI is widely available. Not sure what you mean by fragmentation. I think it's likely that desktop class processors will have the V extension (ratified last year) in addition to G[MAFD]C, but it's the same sort of thing as SSE or AVX detection on x86, not a new problem.

There are _multiple_ standards for the interrupt controller and MMU, and not everyone making linux run on their RISC-V chip implements the same version, or any at all. Same with "standard" extensions needed for linux.

As an example, WD ported linux to the K210 without it supporting any MMU at all, with kernelspace and userspace both residing in the same physical address space with no protection at all. It's upstream.

While it's true that (multiple) standards "do exist" for a lot of the stuff required, and more bits are being specified, until a consensus emerges that everyone follows then the fragmentation will continue.