RISC-V Really?

Learning Note 4, Dec. 25 2019

Eric
5 min readDec 25, 2019

Reference

Why The ISA Battles Aren’t Over Yet

Summary

Open and royalty-free ISA isn’t a new thing for the industry. Why 9+ years of RISC-V is different when we already have 34+ years of MIPS, 33 years+ of SPARC, and the Power ISA. RISC-V might still have a long way to go and some of its features should be verified more.

Many Flavors of RISC

There is a healthy collection of RISC ISAs today:

1. ARM (proprietary)
2. AVR (proprietary)
3. OpenRISC (free)
4. SPARC (free) 33 years+
5. MIPS (free) 34 years+
6. Power (free) 40 years+

Specifically for OpenRISC, it was developed with many of the same goals as RISC-V back in 2000, never made much of a splash, even though it is being used commercially.

SPARC had been an open ISA for a long time, with ESA’s LEON SPARC implementation in VHDL having been available since 1997. Since 2010, MIPS and IBM’s Power ISA have also joined the ranks of open and royalty-free ISAs, with open-source designs in Verilog, VHDL and others made available.

What’s more, MIPS has been a standard teaching tool for processor ISAs since the 1990s, with many students writing their own minimalistic MIPS core as part of their curriculum.

The difference in RISC-V compared with others?

Because of the existing contenders in these areas, RISC-V cannot simply distinguish itself by being open, royalty-free, having a more mature ISA, or better freely available HDL cores.

Instead, its ISA must have features that make it attractive from the standpoint of power efficiency, faster computation, or other metrics.

Below listed two of them.

ISA Advantages

  1. Modulized ISAs: RISC-V isn’t a singular ISA, but over 20 individual ISAs, each focusing on a specific set of functionality → flexibility to design the hardware in enough ISA
  2. Adding custom instruction sets is encouraged in RISC-V ISA, while for others, it is forbidden in order to maintain ISA stability → efficiency targeting to a specific application

These strengths would result in compact hardware devices.

Predication

RISC-V doesn’t provide the condition code register. It forces the processor to execute every single branch in the expectation that one of them is correct, discarding the results of the other branches (means that you cannot parallel execute branches). RISC-V developers claim that out-of-order CPUs can overcome the limitation through brute processing force.

  1. Performance Efficiency: Eliminating predication would cause RISC-V less efficient than equivalent arm-based microcontrollers.
  2. Energy Efficiency: Decrease since branch prediction would flush the work if mispredict the branch → less efficient than predication
  3. Code Sizes: The code sizes would become larger without predication

Strengths of Predication: https://youtu.be/xtA1arYjq-M?t=466 (07:46 ~ 19:04)

Drawbacks

Unfinished ISAs

Only parts of the ISAs are frozen, meaning that they will not be changed. Some ISA packages are still in the early stages of development. Extensions like hypervisor bit manipulation, transactional memory, and user-level interrupts are still in flux, thus only suitable for experimental use.

The embedded ISA isn’t finished either.

Immaturity of HDL and Software Tools

Few cores and tools offer or expect anything beyond the basic (RV32I or RV64I) functionality due to the non-stabilization of the ISA sets

There is no available performance data to back up claims that it can handily outperform any competition.

A world with only Intel, or only AMD, or only ARM, or only RISC-V processors in everything would be rather dull indeed

Comment

Even though there are several good sides of RISC-V, we still have to admit that this isn’t a new thing. We should think about why RISC-V, instead of other ISAs like OpenRISC and something that has already had a long history, attracts enterprises. One of the examples is because of the current needs of the applications (AI + IoT, I have talked about it in my previous posts) that fosters the development of RISC-V. However, we should recognize the drawbacks of the RISC-V.

  • Its removal of predication could result in the loss of performance efficiency. It should be verified by more comprehensive simulation, especially in OoO core configuration according to their claim that OoO could overcome the limitation of discarding predication.
  • Immaturity of software tools is definite. According to my experience in developing RISC-V, the challenges in software toolchains are existing. One would spend a huge time building the required environment to develop RISC-V. For example, to build the riscv-tools, one should resolve the dependencies problems in different platforms to get it compiled. Moreover, RISC-V feature, adding custom instruction, requires huge efforts for developers to do so. it potentially creates barriers for more exciting, inspiring forms of RISC-V to come out.

Tools should be more user-friendly and easy-to-use if RISC-V would like to allow more innovations with more users using it. Apparently for RISC-V now, it still needs a long way to go.

  • Immaturity of HDL cores could prevent RISC-V to be mainstream today. Industries today are still using Verilog to make chips; however, RISC-V is using a higher-level language based on scala, Chisel, to make RISC-V cores. RISC-V converts Chisel codes to Verilog using an engine called firrtl.

    Therefore, there is a lack of complete HDL cores based on Verilog that could provide the industries to use. Even though you provide them with firrtl-generated Verilog codes, the Verilogers would question the efficiency of the code and suspect its synthesizability.

All in all, we should not blindly believe that RISC-V would eventually change the chip industries; instead, the above three drawbacks should be addressed properly by the RISC-V community members. To the best of my knowledge, I believe the software toolchains will become more and more complete. There are many people working on developing the software tools for RISC-V; for example, recenly, I knew there is a new simulator for RISC-V created (https://github.com/mariusmm/RISC-V-TLM). When the RISC-V development environment becomes complete, I believe the validity of the RISC-V and its drawbacks would be soon verified for people to exaimed.

Facts talk. I should work on the verification of the RISC-V to demonstrate its power!

--

--

Eric

SoC Software Engineer at Tesla | 2021 UC Berkeley EECS | 2019 NTUEE.