Why I will be using RISC-V in my next chip

https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-1...

The good news is that RISC has been around since the early 80's so any killer hardware patent will likely have expired by now. Note that the RISC-V ISA is separate from any hardware implementations. If you get fancy with your micro-architecture you can definitely trample on one of the 1000's of micro-architecture patents filed across the industry.

Perhaps the issue is that the internals of eg. modern Intel CPUs are locked up at Intel, so the missing step from CISC assembly to efficient RISC is missing (while we've got high-level/C/C++ to CISC covered)?

If you look at the current results for Rocket and BOOM, you'll find that these microarchitectures seem competitive with Cortex A5/A8 and Cortex A15 respectively at comparable frequencies.

In addition to this, they seem to have some significant amount of space savings on die. Power/performance ratios already seem to be better (likely due in part to smaller die area).

On a power-performance front, a bigger OoO RISC-V could likely be competitive in peak performance to an intel, though you'd have to find a market for that. There has also been a lot of discussion about a real vector machine extension, and that would likely wipe the floor with x86's packed SIMD if done right.

For people designing their own cores for whatever reason (there can be many, research and commercial), RISC-V is very attractive because of all the reasons already given, but it's obviously not the only option.

RISC-V is carefully designed compromise; it scales down to extremely cheap cores and up to superscalar. Like Alpha before it, extreme attention has been paid to avoid features/choices that would be bad for OoOE implementations. Some examples:

- rs1, rs2, rd fields are always in the same location and all register sources and destinations are explicit (makes decoding faster and you can start fetching/renaming without having decoded)

- there are no branch delay slots

- instructions produce at most a single result

- no condition codes etc (dependencies are explicit)

- the sign-bit for all immediate fields is in a fixed location (cheaper sign-extension)

and so forth.

I'm also a big fan of the conditional branch instruction which unlike the Alpha can compare two registers.

> I'm surprised to see a lot of RISC proponents still around, because I think it's quite clear that things didn't quite work out the way they thought it would --- the vision of cheap, simple, high-performance CPUs just didn't happen. Thus I'm not of the opinion that another "MIPS, but free" architecture is such a good idea.

You seem to be implying that there's RISC failed. If you ask anyone who mattered in computer architecture ranging from academics like Patterson who literally wrote the most used books in the field to Intel fellows, they'll all tell you that the essential point the RISC folks were making was proven right. This point being that RISC is requires less logic (=area,power) to implement, it's easier to write compilers for, processors have faster cycle times, and so on.

In the end though, it turned out the market valued software compatibility over performance. That, good marketing and a phenomenally efficient supply chain and fab resulted in Intel winning. But don't confuse this with CISC winning or RISC losing. If Intel had to do a clean slate design today, they'd do RISC themselves. In fact, Intel have a few proprietary microcontrollers hidden inside their chipsets and SoCs that were designed post-2005ish and these have RISC architectures.

> In my experience, statements like this really mean "it's actually really bad, but we don't want to say that"... after all, who would call benchmarks "controversial" if they were winning? There do tend to be few comparative benchmarks, but here's one that shows how ARM and x86 are competitive, but MIPS is behind in energy efficiency:

The benchmark performance depends only on how much effort is put into optimizing the implementation. Intel have on average maybe 200 architects and 200 more designers tweaking their processors for performance for the last 30 years. It is completely absurd to expect a team of 10 or so grad students to compete with them.

[1] https://github.com/ucb-bar/rocket-chip [2] https://github.com/ucb-bar/fpga-zynq

-only 2% of the standard FPGA fabric does useful work..

&

-the really expensive part to develop is the IO (too many standards)

Having an open FPGA is a a good start, but it will only be truly useful if the IO and the optimization is brought up to date with modern fpgas. Today's fpgas are really structured asics.

Very much for an open fpga, but let's not underestimate the investments made by fpga companies to get to the current state of the art. Building platforms is very expensive [ref mythical man month]

VLIW has been the future since the 80s, and we're still waiting for the magic wonder compilers that can actually spit out efficient VLIW code. Even GPUs have abandoned VLIW (AMD TeraScale) in favour of RISC (Nvidia, AMD GCN).

And the concept of baking into your ISA what the designer believes is the "perfect functional unit mix" is an anti-pattern. What's the perfect mix depends on the benchmark, and it changes from basic block to basic block. A history of failed VLIW projects can attest to this. A dynamic superscalar is far superior, even in power-efficiency.