3 ms·

I saw this asked the other day but never really saw a satisfactory answer. Why has RISC-V taken off? It's not the only royalty-free ISA. OpenPOWER and OpenSPARC

I saw this asked the other day but never really saw a satisfactory answer. Why has RISC-V taken off? It's not the only royalty-free ISA. OpenPOWER and OpenSPARC have both been around for almost 20 years with basically 0 enthusiasm.

itomato 3y ago
Maybe because RISC-V was built to be open, not a post-facto?
nickik 3y ago
People often asked this but there are a few misconceptions. OpenPOWER was not really 'open' in a meaningful way. It was only RISC-V that made OpenPOWER actually push towards more openness but by then it was to late. OpenSPARC is really only truly open in its 32 bit version. The 64 bit was not open in the same way. Sparc having things like register windows and delay slots also technically didn't have a clear advantage over ARM or MIPS. Also its strong association with Oracle wasn't gone help. RISC-V was truly open from first principle and did some technical clean up. Additionally, very early, before RISC-V was even a standard, they had already released a bunch of 32-bit cores that could compete with ARM cores, and a bunch of students built it. The ISA was easy to build for, and that helped in education. The university of Berkley got eyes on the project and then quickly the ETH and others jumped on in. So there were multiple open cores both in modern Chisel and SystemVerilog. They were also clear about trademarks and how to use them once the foundation was established. There was a path forward to evolve it, not a fixed standard. Companies could get involved and help get RISC-V to where they needed it. In the standard, a way to add custom instructions without clashing with any future RISC-V instruction. OpenSPARC is just a fixed IEEE Standard. There simply wasn't gone be a dynamic Linux like community around OpenSPARC. What Sun did was amazing, but I think people wanted a fresh start with everything we have learned from OpenSource and OpenHardware over the last 30 years. Sometimes things just aren't purely technical, sometimes starting something new just builds a community that dynamically drives things forward.
RetroTechie 3y ago
1. Suited for very small implementations (~$0.10 uCs, tiny FPGA softcores etc). But scales easily to high-performance cpus. 2. Clean slate design, applying latest insights concerning cpu design, virtualization & so on. 3. More a community effort & perhaps more open than other ISAs. OpenSPARC is (unlike early Sparc cpus) targeted at high-performance server / supercomputer chips. Similar for OpenPOWER which is mostly an IBM affair. And opened only around the time RISC-V came out. From what I've read (no personal experience), OpenRISC wasn't that well-designed or lacks RISC-Vs modularity. So a combination of license, community, ISA design & timing of its introduction.
- dmitrygr 3y ago
  2 is not even remotely true. Read spec. Compare to MIPS. Remove delay slot. Compare now.
snvzz 3y ago
For the same reasons RISC-V had to be created. This is documented in the paper Instruction Sets Should Be Free: The Case For RISC-V[0]. 0. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...

itomato 3y ago

Maybe because RISC-V was built to be open, not a post-facto?

nickik 3y ago

People often asked this but there are a few misconceptions. OpenPOWER was not really 'open' in a meaningful way. It was only RISC-V that made OpenPOWER actually push towards more openness but by then it was to late. OpenSPARC is really only truly open in its 32 bit version. The 64 bit was not open in the same way. Sparc having things like register windows and delay slots also technically didn't have a clear advantage over ARM or MIPS. Also its strong association with Oracle wasn't gone help. RISC-V was truly open from first principle and did some technical clean up. Additionally, very early, before RISC-V was even a standard, they had already released a bunch of 32-bit cores that could compete with ARM cores, and a bunch of students built it. The ISA was easy to build for, and that helped in education. The university of Berkley got eyes on the project and then quickly the ETH and others jumped on in. So there were multiple open cores both in modern Chisel and SystemVerilog. They were also clear about trademarks and how to use them once the foundation was established. There was a path forward to evolve it, not a fixed standard. Companies could get involved and help get RISC-V to where they needed it. In the standard, a way to add custom instructions without clashing with any future RISC-V instruction. OpenSPARC is just a fixed IEEE Standard. There simply wasn't gone be a dynamic Linux like community around OpenSPARC. What Sun did was amazing, but I think people wanted a fresh start with everything we have learned from OpenSource and OpenHardware over the last 30 years. Sometimes things just aren't purely technical, sometimes starting something new just builds a community that dynamically drives things forward.

RetroTechie 3y ago

1. Suited for very small implementations (~$0.10 uCs, tiny FPGA softcores etc). But scales easily to high-performance cpus. 2. Clean slate design, applying latest insights concerning cpu design, virtualization & so on. 3. More a community effort & perhaps more open than other ISAs. OpenSPARC is (unlike early Sparc cpus) targeted at high-performance server / supercomputer chips. Similar for OpenPOWER which is mostly an IBM affair. And opened only around the time RISC-V came out. From what I've read (no personal experience), OpenRISC wasn't that well-designed or lacks RISC-Vs modularity. So a combination of license, community, ISA design & timing of its introduction.

dmitrygr 3y ago
2 is not even remotely true. Read spec. Compare to MIPS. Remove delay slot. Compare now.

snvzz 3y ago

For the same reasons RISC-V had to be created. This is documented in the paper Instruction Sets Should Be Free: The Case For RISC-V[0]. 0. https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-146.pdf https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-...