41–50 of 51 posts
Earlier quoted context omitted.
Smaller instruction set and shorter reference manual aren’t necessarily good attributes. The risc-v reference manual is short because in part because it is has terse-to-vague descriptions of things (not great for a specification) and because the ARM ARM specifies a bunch of things which are omitted from the RISC-V architecture spec, which either implementors will have to design themselves or the RISC-V org will event…
[deleted]
Earlier quoted context omitted.
smaller instruction set, Arm has grown, reference manual is over 6k pages smaller easier to read specs easier to get new features ratified, org is a steward, isn't seeking rents easy to add custom instructions lots of OSH implementations to choose from large 3rd party ecosystem, IP, compilers, OS, etc.
To be fair, even with a closed ecosystem for the cores themselves there is a large third party ecosystem in compilers, OSes, support hardware, and documentation around ARM these days. It's interesting how quickly all of that popped up around RISC-V the past few years though. ARM has had decades getting where they are with the ecosystem around their cores.
RISC-V is basically a different encoding to achieve the same computation as being done on Arm. From far enough out and that isn't very far they are identical. Putting a RISC-V front end on an Arm chip is not difficult. Refactoring Arm tooling to support RISC-V is just engineering work. Every program fixed to run on Arm's memory model, now runs on RISC-V as well. RISC-V is a catamaran zipping around on Arm's moat.
We see the same thing with languages and frameworks. Innovation is accelerating.
Earlier quoted context omitted.
> but can't be any fully OS ARM ones (even if someone's made an OS ARM core you still have to pay ARM a royalty) Wait long enough and you can. Even if you can’t work around them, patents expire, and you can copy the instruction set for reasons of compatibility. Trademarks don’t automatically expire, though, so unless the trademark gets genericized ( https://en.wikipedia.org/wiki/Generic_trademark ) what you can’t do…
Arm will still blacklist you if you pull this trick. And being blacklisted by ARM might hurt your business when you do actually need to buy something from them.
Protip: You don't.
Literally, just license whatever you need elsewhere. RISC-V has an open market of cores, with tens of companies and hundreds of offerings.
10 billion RISC-V cores were shipped last year - mostly you wont see them because they're heavily embedded - in disk drives/etc - used to be every flash drive had an ARM core in it and paid a few pennies to ARM, that's likely to change quickly
They said "We estimate there are 10bn cores on the market already" (that would be since 2010). Then there's a slide that says "Nearly 80 billion RISC-V CPU cores by 2025".
https://www.eenewseurope.com/en/europe-steps-up-as-risc-v-sh...
that's from a talk at Embedded World in june 2022.
I can't find that talk on youtube. But there's another shorter talk that's online, from same CEO at the same conference, where they have a slide that says "North America. Industry adoption has taken off with millions of cores shipping from Nvidia, Western Digital, SiFive, and others."
What benefits does RISC-V have over ARM besides it being open/free?
Given any ARM core (save the wildly inefficient, but faster top performance cores like the X1/X2), SiFive's got one that's like below a third of the size, uses dramatically less power and runs somewhat faster.
This is enabled by the quality of RISC-V's architecture.
The base spec has less than 50 instructions. Even with everything and the kitchensink in there (which is possible; as of the batch of extensions approved in late 2021, RISC-V is not lacking any major features ARMv9 or AMD64 have), RISC-V is still a few hundred instructions, rather than thousands.
And, despite having highly competitive 32bit code density (might be the best by year end, considering with current state of non-finished Zc/B extensions it already is) and the highest code density of 64bit architectures (by comfortable margin), RISC-V is very easy to decode. The compressed code extension does barely even complicate decode, and is still either 2x 16bit instructions or a 32bit one.
In practice, this means cores can be tiny relative to equivalent ARM cores, and SiFive's portfolio is a good demonstration of that.
By contrast:
- AMD64 aka x86 has 1-16 byte instruction length which means a 2-decode or wider implementation has to bruteforce every possible instruction start and discard the bad results. This makes complexity scale exponentially with decode width, and Intel and AMD have found that 4-decode is a practical limit.
- ARMv9's aarch64 is fixed 32bit (yet only slightly easier to decode because of that, relative to thumb2 and RISC-V). This enabled Apple to go 8-decode with the M1. But this comes at the expense of code density: If you want to implement a high performance core, you're going to need a huge L1, which besides huge area and power penalty, is also going to cap the clock the cache can achieve. Regardless, the situation is much better than AMD64(x86), and has enabled Apple to go 8-decode on the M1.
And this is why I think Apple moving to RISC-V in supporting cores is only the first step, and the main cores will eventually follow.
Apple ISA. Might take them a decade, but in the end, they will eventually do all their own thing.
Earlier quoted context omitted.
It's more likely that RISC-V replaces MIPS than ARM, although it's certainly competing for the latter too. ...and USB flash drives are more likely to be based on 8051s than ARM in volume.
RISC-V replacing MIPS is old news. It is a done deal. The company that owns MIPS, Imagination Technologies, has entirely dropped the MIPS ISA to instead focus in designing RISC-V cores.
Interesting in that Imagination have since announced RISC-V cores [2], but that's unrelated to any of the MIPS tech, and none of the MIPS engineers worked on it as the project started well after the sale.
[1] https://www.imaginationtech.com/news/completion-of-sale-of-m...
[2] https://www.imaginationtech.com/news/imagination-launches-ri...
Earlier quoted context omitted.
RISC-V replacing MIPS is old news. It is a done deal. The company that owns MIPS, Imagination Technologies, has entirely dropped the MIPS ISA to instead focus in designing RISC-V cores.
Imagination Technologies sold off MIPS in 2017 [1] - while RISC-V might have been a thing back then, it was certainly nowhere as known as it is today, and well before any decision to focus on RISC-V. Interesting in that Imagination have since announced RISC-V cores [2], but that's unrelated to any of the MIPS tech, and none of the MIPS engineers worked on it as the project started well after the sale. [1] https://www…
Earlier quoted context omitted.
I highly doubt it. As "reduced" as RISC-V is, 8051 is still tiny in comparison. 8051s are used in applications where a 4-bit MCU (yes, they do exist and are still in widespread use) is not quite enough, or they'd have chosen one of those instead.
There's a community doing "fpga golf". That is, reducing the number of LUT required to implement a CPU of a given ISA. A basic RV32 CPU is down to 500-700 LUT. https://github.com/YosysHQ/picorv32 https://github.com/olofk/serv A minimal 8051 requires about 300 LUT. https://github.com/MicroCoreLabs/Projects/tree/master/MCL51 Not sure how this translates from an FPGA to a transistor count. But RV32 and 8051 should be wi…
That's still a huge difference, and as I mentioned above, the 8051 is found in applications which are very sensitive to cost. In terms of gate count, the lowest numbers I could find for a RISC-V core are in the 10-20k range, while an 8051 goes down to 2.7k:
https://www.electronicsweekly.com/news/design/eda-and-ip/805...