Frequently Asked Questions about RISC-V

  • 1. What is the license model?
    It is a BSD Open Source License. This is a non-viral license, only asking that if you use it, you acknowledge the authors, in this case UC Berkeley. We have not filed nor do we intend to file any patents that would be required to implement a RISC-V-compatible processor. While we know of no patents that are required to implement the RISC-V ISA, there are many microarchitectural patents that might be infringed by a particular RISC-V implementation. We cannot indemnify users against ISA or implementation patents asserted by others.

    Within the newly established RISC-V Foundation we’ll be establishing updated licensing terms for the benefit of all RISC-V implementors.

  • 2. Does that mean free for industry to use and play with, but then we pay if we produce a product using this ISA?
    No. It’s free for product use too.

    UC Berkeley has a proud tradition of sharing software with industry for free that goes back long before the term “open source” was invented. The following all have thousands to millions of users as well as their own long Wikipedia entries: the operating system Berkeley Unix (aka BSD Unix), the database programs Ingres and PostgreSQL, the electronic computer aided design programs SPICE and Magic, and most recently the cluster computing framework Spark. Indeed, even the BSD open source license is so popular that has its own Wikipedia entry.

  • 3. If our company builds a RISC-V implementation, is it required to release its source code for the RISC-V core?
    No. The licence only requires acknowledging the authors, in this case, UC Berkeley, in the documentation. The source code can be completely closed.
  • 4. Is there an ISA reference manual?
    Yes. The 100-page RISC-V user-level ISA is available as a tech report. The RISC-V privileged-level ISA specification is still being developed.
  • 5. Are there publications beyond the ISA reference manual?
    Yes. Visit our Publications Page.
  • 6. How mature are the software tools?
    The team at UC Berkeley has been using the software tools internally for the past three years and continue to actively develop them. Additionally, programmers outside UC Berkeley are contributing code and fixing bugs as part of an open-source effort for the RISC-V tools.
  • 7. Is there a RISC-V consortium? Who is already in? Can you give me some details about that?
    We are in the formative stages of establishing the RISC-V Foundation, a non-profit corporation with a mandate to govern RISC-V, evolve the ISA, and to promote the use of RISC-V.
  • 8. I didn’t see any plans for SIMD extensions. Do they exist?
    We plan to define more optional instruction set extensions for RISC-V beyond the ones we already have, including Packed-SIMD Instructions (P), Bit Manipulation (B), Decimal Floating-Point (L), and Transactional Memory (T). One goal for the RISC-V foundation is to manage development of these future standard instruction-set extensions.

    The currently defined extensions to the base Integer (I) ISA are Multiply-Divide (M), Atomic (A), Floating-point in multiple precisions (F, D, and Q), and Compressed Instructions (C).

  • 9. How fast are RISC-V processors compared to x86 or ARM processors?
    This depends entirely on the quality of the implementation, including microarchitectural design, circuit design, and process technology used. We believe there are no fundamental reasons that a RISC-V implementation should be less efficient than x86 or ARM, and indeed that the ISA design should enable implementations to be somewhat more efficient than either.
  • 10. Are RISC-V processors lower power than ARM processors?
    This depends entirely on the quality of the implementation, but we feel RISC-V implementations should be at least comparable in energy efficiency to ARM cores built in the same microarchitectural style and with the same engineering effort in the same process technology. In one point of comparison, the RISC-V Rocket core is twice as energy efficient as the most similar ARM implementation, the Cortex-A5.
  • 11. Why not use OpenRISC? Or MIPS?
    When we started developing RISC-V in 2010, we decided against adopting the OpenRISC ISA for several technical reasons:

    • OpenRISC had condition codes and branch delay slots, which complicate higher performance implementations.
    • OpenRISC uses a fixed 32-bit encoding and 16-bit immediates, which precludes a denser instruction encoding and limits space for later expansion of the ISA. This pretty much entirely eliminates the ability to explore new research architectures.
    • OpenRISC does not support the 2008 revision to the IEEE 754 floating-point standard.
    • There was no 64-bit address space version of OpenRISC when we began. While there has been some work since 2010 towards the 64-bit address space version of OpenRISC, hardware implementations and software stacks are still not available.

    Many of the above reasons also apply to MIPS, but with the added legacy and patent and trademark issues.

    By starting from a clean slate, we could design an ISA that met all of our goals.

  • 12. Who has funded the RISC-V ISA project?
    RISC-V has been developed as part of a number of sponsored research projects. We thank the following research sponsors for their support.

    ASPIRE Lab research partially funded by:

    • DARPA PERFECT Award Number HR0011-12-2-0016
    • DARPA POEM Award HR0011-11-C-0100
    • Center for Future Architectures Research through the Semiconductor Technology Advanced Research Network (STARnet).
    • ASPIRE Industrial Sponsor: Intel
    • ASPIRE Industrial Affiliates: Google, Nokia, NVIDIA, Oracle, Samsung

    Par Lab research supported by Microsoft (Award #024263) and Intel (Award #024894) funding and by matching funding by U.C. Discovery (Award #DIG07-10227). Additional support from Par Lab affiliates Nokia, NVIDIA, Oracle, and Samsung.

    BWRC partially funded by DoE Award DE-SC0003624 (Project Isis).

    The content of this website does not necessarily reflect the position or the policy of the US government or our other sponsors and no official endorsement should be inferred.