There's a lot of "what" in the article, not so much "why" or "history".<p>Every decade or so, someone tries an open, current technology and specs CPU. Plenty of free FOSS or FOSS-like z80 or 6502 cores out there, not so many cutting edge designs. The key differentiator with RISC-V is its pretty near cutting edge compared to every other free core out there.<p>There are tons of cores out there for FPGAs but usually they are not cutting edge powerful (although close...) and they always have interesting and expensive licensing for non-trivial use. RISC-V should, once community support and toolchains catch up, eat every licensing dollar currently being spent on Xylinx Microblaze or Intel/Altera NIOS-II. So there's money laying around interested in RISC-V. Or a more negative way of looking at it is there's a lot of money thats interested in not seeing RISC-V succeed.<p>Around the turn of the century, the same idea was OpenSPARC. Around last decade, the same idea was OpenPOWER. Now, its RISC-V and ... maybe its going to be a winner? Its about time.
I wonder if RISC-V will be able to keep its simplicity for a long time.
ARM began as a small instruction set as well, and now we have
instructions like the FJCVTZS (Floating-point Javascript Convert to
Signed fixed-point, rounding toward Zero).
At the university that I work at, some of our operating systems courses have already adopted RISC-V. So hopefully it is around to stay. Some of the material is publicly available in an online book/blog form written by our lecturer: <a href="http://osblog.stephenmarz.com/index.html" rel="nofollow">http://osblog.stephenmarz.com/index.html</a>
My main disappointment with RISC-V is that the optional swathes of the instuction set are all-or-nothing, and they are each huge. E.g., I don't get popcount without a hell of a lot else (none of which is actually out, yet), similarly for others. Maybe this wouldn't matter if they almost always have everything, but that doesn't seem to be the case; certainly B are thin on the ground, for known reasons.<p>The second disappointment is that they flubbed the once-in-a-generation opportunity to represent the boolean true value as all-1s, which would make it also useful as a mask.<p>Third is that the comparison and conditional-branch instructions are merged, impoverishing the sets of comparisons and branches. (E.g., comparisons could set an output register to zero or all-ones, and branches could then depend on a register.)<p>You might consider these pretty small disappointments, but I feel them no less keenly for that.
RISC-V is interesting for Lattice ECP5 specifically. I'm working on a project now where I'm using it (I will make a blog or videos about it at some point):<p>- ECP5 is the lowest cost medium size FPGA. Usually I would say that using a soft core is a waste of money vs. an external microcontroller unless you need to save space, but the cost of the added gates (say the next larger FPGA size than what you would need for a design without the soft core) is less than the cost of a microcontroller for the case where you are using ECP5 and you need video (a non-video micro is still cheaper).<p>- Mico32 is Lattice's soft core solution. You can argue about its quality, but the very stupid reason that I prefer RISC-V is that the Mico32 tool chain does not work in Ubuntu (or at least not without a lot of work- it is supposed to work in RedHat). A lot of other people complain about Mico32 because it will not run Linux, but this is not so much of an issue for my design.<p>- PicoRV32 is designed for high clock speed. This is probably not good for its own performance (multiple cycles per instruction), but it does mean that the RISC-V core is not the limiting factor for the rest of your FPGA design.<p><a href="https://github.com/cliffordwolf/picorv32" rel="nofollow">https://github.com/cliffordwolf/picorv32</a><p>- The barrier to entry is low (as long as you already know GCC linker scripts). The problem with NIOS-II and especially Xilinx Microblaze is that the their tools are not simple. There is a payoff for learning their tools, in that a lot of vendor cores become available. But if you don't need the vendor cores, then the non-existent toolchain (there is no system building to learn) for RISC-V is better. An example of this is the following project trellis (a cool open source FPGA toolchain, but that's another story) example design:<p><a href="https://github.com/SymbiFlow/prjtrellis/tree/master/examples/picorv32_versa5g" rel="nofollow">https://github.com/SymbiFlow/prjtrellis/tree/master/examples...</a>
“ In China, for example, the foundation has 30 members, and more than 200 people participating in local RISC-V associations.”<p>The second largest economy is going to run with this. After the trade war, they’ll reduce exposure to US restrictions.
So are RISC-V chips already available? Or is it that the chips available are all low power things.<p>I'm curious how much effort is left, before it's possible to build an open source PCB that those who wanted to could send off to be printed and populated, which could serve as some kind of MVP motherboard.