Frequently Asked Questions about RISC-V

  • 1. What is the license model?
    The RISC-V ISA is free and open for use by anyone in all types of implementations without restriction. Designers are free to develop proprietary implementations for commercial exploitation or open-source implementations to be shared as they see fit. The RISC-V Foundation encourages both types of implementations. For commercial RISC-V implementations, a license to the RISC-V trademarks is required which is granted to members of the RISC-V Foundation.
  • 2. Does that mean free for industry to use and play with, but then we pay if we produce a product using this ISA?
    The RISC-V ISA is free for product use too.
  • 3. If our company builds a RISC-V implementation, is it required to release its source code for the RISC-V core?
    No, the source code can be completely closed.
  • 4. Is there an ISA reference manual?
    Yes. The 145-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. 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).

  • 8. 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.
  • 9. 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.
  • 10. 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.

  • 11. 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.

  • 12. What about Vendor ID assignment for RISC-V implementations?
    The RISC-V Foundation Vendor ID assignment uses JEDEC manufacturer IDs as defined in the RISC-V ISA Privileged Architecture Specification v1.10 Section 3.1.2 Machine Vendor ID Register mvendorid and repeated here for convenience.  Refer to the full Privileged Architecture Specification here.

    3.1.2 Machine Vendor ID Register mvendorid

    The mvendorid CSR is an XLEN-bit read-only register providing the JEDEC manufacturer ID of the provider of the core. This register must be readable in any implementation, but a value of 0 can be returned to indicate the field is not implemented or that this is a non-commercial implementation.