RISC-V takes steps to minimize fragmentation The momentum behind RISC-V is growing with the backing of tech heavyweights, but it comes with a challenge: encouraging CPU designers to stay on the same page, and to avoid the sort of fragmentation that happened in MIPS and Android. With that in mind, RISC-V International, which coordinates the development of the open …
They will need real funds to protect the RISC-V branding, and prevent RISC-V labeled processors getting a bad name because they are all incompatible.
For that they would need a branding procedure, to proof basic compatibility is guaranteed on something calling itself RISC-V.
Also funds to litigate manufacturers selling non-standard RISC-V cpu's as RISC-V will be required.
there is actually a "Certification" Process, and there is supposed to be a Trademark. however one of the things about Trademark Law is that reasonable in-good-faith requests for participation must be treated Fairly, Reasonably, and Non-Discriminstorily (FRAND). i made approximately ten in-good-faith requests to participate over an 18-month period, explaining each time that the conditions set by "Membership of the RISC-V Foundation" were not appropriate for my business model and incompatible with my funding remit. i did not receive one single response. that constitutes "discrimination", and is grounds for *invalidation* of the RISC-V Trademark.
by complete contrast, IBM set the specific condition that the Power ISA would only be handed over to the OpenPOWER Foundation if contributions to the Power ISA via its ISA Working Group included an *EXTERNAL* RFC Process that specifically did *not* require Membership of the OpenPOWER Foundation. as a non-member you cannot vote, you cannot engage in discussions, but you can at least make a proposed addition to the Power ISA. this process has taken years to negotiate and get established: due to the Power ISA being so well-established, IBM wanted to make absolutely certain that it was done right.
totally ironically, RISC-V was conceived, developed, and rolled out during the time it has taken to get the Power ISA paperwork and legal issues resolved!
Exactly how this make RISC-V as an ISA specification different from either OpenRISC or OpenPOWER?
If fragmentation is in fact bad and not a feature bullet point, then what is the point behind allowing anyone to modify it and still call it 'RISC-V'?
A lot of this messaging feels overly complicated and confused.
The idea is to standardize on often-used extensions such as matrix, floating point and vector operations. To me this sounds entirely logical and supportive of the community. Even companies working on building their own extensions will benefit over time since having non-standardized instructions will hurt their uptake.
Mind you that this doesn't limit companies' right to innovate and extend RISC-V, but it will make them think twice before doing so.
> Exactly how this make RISC-V as an ISA specification different
> from either OpenRISC or OpenPOWER?
in many ways.
Patents:
* OpenRISC has zero patent protection of any kind. it is a huge risk for any commercial company to use it.
* the Power ISA has literally thousands of patents behind it, spanning back 20+ years because the Power ISA dates back as far as 1993. when creating an ASIC and having shown that it passes the Compliance Suite for Power ISA 3.0 / 3.1, you get an automatic Royalty-Free Grant from IBM. https://openpowerfoundation.org/blog/final-draft-of-the-power-isa-eula-released/
* RISC-V has patent "we won't sue each other" agreements between its *Members*... but there is *no protection from other people*. as a result there are already multiple patent infringment lawsuits underway against manufacturers of RISC-V ASICs. whoops.
Specification Contributions:
* OpenRISC - totally open. covered by Copyright Law. do what you like as long as you respect Copyright.
* RISC-V - Trademarked, and not "open" at all. it's "ITU-style" (closed-doors development). you are forced to join the RISC-V Foundation and to sign a "Commercial Confidentiality" (secrecy, NDA) clause before you can contribute to the ISA.
* OpenPOWER - not strictly "open", but at least you can contribute via an "External RFC" Process to the ISA Working Group. this is currently going through Ratification at the moment and there should be an announcement shortly.
"Customisation":
* OpenRISC: totally do what you like as long as you respect Copyright Law. you're on your own because there are not many people doing anything with it
* RISC-V: customisation is "permitted" but there is absolutely no way in hell that any of your "customisation" will end up "upstream". it is sandboxed in some "custom opcodes" and if you happen to conflict with anyone else on those custom opcodes, tough s**t. basically the "customisation sandbox" is intended for proprietary systems where the customisation, including the compiler, toolchain and libraries, will NEVER see the public light of day.
* OpenPOWER: customisation is also permitted and a sandbox Major Opcode (EXT022) is provided for that purpose, along with an area of SPRs. submission of "popular" or "general-purpose" extensions are encouraged to be submitted to the ISA WG. Power ISA is pretty much exactly in the same boat here as RISC-V, with the exception that (a) there's less contention (Power ISA is less "popular") and (b) you aren't forced to join the OPF to make ISA RFCs.
Capability
* OpenRISC: is... well... not that good. correction; for what it was at the time, it was an astounding achievement given that it's entirely Libre/Open. however it's 32-bit, and implementations never really went beyond 130nm.
* RISC-V: this article says it all https://news.ycombinator.com/item?id=24459314 but as if that wasn't bad enough, performance between RISC-V implementations can be as high as a 2x variation. they're supposed to be "compatible" (RV64GC) but if they're that different, how can you trust them, commercially? the Alibaba Group had to add a whopping extra 50% custom (rogue) instructions in order to meet par-performance with a high-end ARM Cortex A73. note: custom ROGUE instructions. that will never be accepted into the RISC-V ISA because they dominate the "sandbox".
* Power ISA: designed from the ground up as a Supercomputing ISA. adrian_b's comparative summary is the best analysis i've seen so far. although the Power ISA is by no means "perfect" it at least has Carry and Condition Codes, and LD-ST-with-update. it doesn't have "LD-ST-shifted" which both ARM and x86 have, but RISC-V has neither.
basically, several large organisations are deeply regretting their decision to go with the "easy" RISC-V "because bandwagon because Academic".
> If fragmentation is in fact bad and not a feature bullet point,
> then what is the point behind allowing anyone to modify it and still call it 'RISC-V'?
exactly.
It's worth exploring the analogy, to see what can be learned.
For Linux, the step between source and running it is compilation. For Risc V, that step is "you've got to own a semicon fab". It's trivially easy for anyone to compile Linux and run it within their chosen distro. It's not easy to own a semicon fab. I think that this means that there's a different balance of power in the two projects.
In Linux, because the means to compile it are in the hands of literally everyone, this diminishes the control that large organisations can hold over it. For a hpyothetical example, RedHat fundamenally cannot tell Linus what Linux is going to look like, and enforce it by owning the only compiler in town. Linus and the rest of the kernel community volunteers would be able to tell them where to put their patch, and everyone else can ignore it too. And, RedHat can do a proprietary version of their own and keep the source to themselves...
Whereas, with Risc V, it doesn't matter what the Foundation or originator says; the balance of power is in the fabs. Also, if they want to, they can keep it proprietary.
So it feels more like FreeBSD, rather than Linux.
In Linux, because the means to compile it are in the hands of literally everyone
Just like everyone has the (theoretical) means to write their own code and compile it, everyone has the (theoretical) ability to design a simple RISC-V core and get it made for a reasonable cost. It will be in a very old fab process, but it will operate. It isn't like the PC you run Linux and gcc on is free, so there is a cost for either option.
The fact it costs tens of millions up front before you can have one chip fabbed on leading edge process is an economic roadblock, but the fab doesn't tell you what you can and can't make (so long as you aren't violating the law, like if you tried to get them to make a chip you designed with your own unlicensed x86 core) They are not acting as gatekeepers for RISC-V designs.
FPGA vendors -- Altera, Xilinx and Lattice, for example -- already supply a RISC-V like processor as an IP block for their products. These soft processors include options such as peripheral buses, common peripherals and cache and DRAM management. Extensions would be prototyped in logic; the result won't be as fast as dedicated hardware but it will prove the design to a much better extent than just a logic simulation (and enable work on the software toolset to be used with the design).
(In case you're not familiar with FPGA work the usual mechanism is to provide a design in the form of a logic specification language such as VHDL or Verilog. This design is normally structured as nested functional blocks. The logic is compiled and if that is successful it is automatically routed onto a particular chip. The design will include timing constraints and the layout will be simulated against these constraints. Resolving all the non-logic errors and warnings is an art form; there is AFAIK no equivalent task in software.)
FPGAs are not a mass market solution.
I am familiar with FPGAs which is why I know that the cost / speed ratio is miserably bad. Plonking down a serial design such as a CPU on to programmable logic that clocks as slow as FPGAs do is defeating the whole point of the FPGA's parallelism in the first place. You're far better off using any hard cores that are probably lurking on the FPGA, and have already been paid for.
Also, RISCV is licensed under BSD. That gives everyone the right to keep their proprietary extensions private. Just because you can theoretically run their extensions on your FPGA doesn't mean you can get hold of them. They can make it so as you have to buy their chip. Feel free to de cap it and reverse engineer the extension, but then you are breaking their copyright.
It's not millions, it can be as cheap as £50k to have a chip made on an old fab. You need to have the masks already for that price, but it can (and is) done by specialist's working in the component obsolescence business.
Depending on what you're looking for it can be cheaper to get a chip made than to muck around with FPGAs...
That's still not going to be cheap enough for a determined fab to be outweighed by those very few who would go their own way.
But there are literally dozens of cheap or free CPU cores that already exist. More than half of which are open-source.
https://en.m.wikipedia.org/wiki/Soft_microprocessor
It’s been a cottage industry by the EU for two decades to manufacture open-source CPU cores for hundreds of prototype / academia chips, based on SPARC, MIPS etc. I’ve led five such myself, and worked on dozens more. As a taxpayer, you may not be aware, but you’ve *already* spent well over €300m in total on such projects, that I know of, and it’s probably double or treble that in various niches that I haven’t been involved in.
How many more ESA LEON chips do you want?! RISCV isn’t even reinventing the wheel at this point. It’s reinventing the PowerPoint budget proposal for the investigation of use of round objects.
Yes but the required spec is very minimal. If that's all you can assume from a "RISC-V" chip then it will never move out of its embedded slot into general use like ARM has - and it basically took ARM tossing out all the old garbage intended for the embedded market like Thumb and create a brand new AAarch64 ISA - and allowing implementers to drop AArch32 entirely if they so choose. That AArch64 baseline is far broader than the RISC-V baseline, which looks as out of date as ARM5.
-> RISC-V is sometimes referred to as the Linux of chips
And we see how that gets along - a new distro every 2 seconds with a few slithers of difference. Only the big distros really count, everything else is just noise.
-> the sort of fragmentation that happened in MIPS and Android
This is partly what hampered Java mobile years ago. Many of the problems had been solved, or being worked on/improved. At that time the phone manufacturers wanted specific versions of Java for their hardware. Of course, Android has been a success which swept the small Java players away.
-> It took six years for the RISC-V world to standardize vector specifications
That sounds like too long. If you were a hot new hardware designer, would you accept six years to get something standardised, or would you go your own way. RISC-V needs to be far more responsive if it doesn't want fragmentation.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
