I have a specification from my company, how do we get it ratified?

RISC-V does not have a process for simply ratifying externally developed specifications.  All specifications are developed by a Task Group (TG) whose need has been identified by a Special Interest Group (SIG) or a Committee (an ISA Committee or IC or a Horizontal Committee HC).  

So, what really needs to occur is the following set of steps:

1. Instead of identifying the solution, up-level the discussion to what problem is being solved.

2. Locate the IC, HC, or SIG which has a vested interest in solving this problem.  This is your potential “sponsor”.  If you cannot find one, reach out to the RISC-V Staff for guidance.

3. Meet with the potential sponsors and see if they agree that this is a problem, and is high enough priority to begin solving.  If so, work with the sponsor group, and likely the TSC leadership to build the correct path for defining the problem to be solved.  If there are multiple solutions, a SIG may be required to explore all solutions and pick.

4. When it has been determined that a new group needs to be formed, follow the directions in the “Specification Development“ section of the RISC-V Development Process wiki page.

5. Be ready to volunteer to drive any work that needs to be done.  RISC-V is a “contributor culture”.

6. Accept that the current solution implementation may not be the final implementation.  Open development is a grass-roots, organic, unique, and sometimes frustrating process.

Thank you for your interest!

How do I propose an ISA Extension?

Evaluation of future RISC-V ISA extensions should begin with a discussion on the isa-dev mailing list. Generally speaking, this list contains many experts who have been contributing to and discussing the ISA for many years.

The recommended way to start such a discussion is with a question such as, “Has the RISC-V community ever considered an extension to accomplish <your idea here>?” or “What extensions does RISC-V have to accomplish <your idea here>?”   This approach avoids jumping to conclusions about an implementation and acknowledges that this idea may have already been discussed in the past or might even already exist.

If your idea is one that is recommended to be pursued, the next question would be whether this is a full specification, requiring a task group to write the specification or whether this can be done as a Fast Track extension under the guidance of an ISA Committee (IC).  More information about both of these options can be found on the “Specification Development“ section of the RISC-V Development Process wiki page.

Questions at any point along this journey can be routed to the RISC-V Staff.

How do I know if my document is an ISA or Non-ISA document?

ISA documents are any documents that impact the processor instruction encoding or state.  Any document that requires even the slightest change should be treated as ISA.  Everything else is non-ISA.

There is no such thing as a “hybrid” document, it’s an ISA document if you need any changes.

Does RISC-V support non-ISA specifications using the Fast Track process?

While RISC-V has historically used the Fast Track process as defined by the Fast Track Policy for ISA specifications, the process may also be applied to non-ISA documents.  If you need help or have questions, please contact the RISC-V Staff with questions or to request assistance.

How do I become a Chair or Vice-chair?

As with many groups in life, leaders are most frequently selected organically from within the organization.  Thus, the best way to become a group leader is to join and to contribute technically to the group before seeking leadership.

The RISC-V process by which leaders are solicited is the Call for Candidates during which potential leaders are identified (usually self-identified, not nominated).  Interested candidates provide a brief bio and a short Statement of Intent (description of how they plan to lead and/or what they want to accomplish). The call is generally held open for 2 weeks.  

Upon closure, the candidates are voted on by the body.

More details about the Call for Candidates and the approval process can found in the Running a Call for Candidates wiki page.

I have a concern with a specification which is under development, how do I raise an issue?

First there are a couple of policies and process with which you should become familiar. The RISC-V Technical Contribution Overview wiki page details these.

We don't profess to be perfect so if you find something that we could communicate better about or improve please contact the RISC-V Staff.

During the specification development lifecycle, the natural ways to raise an issue for a specification are:

• For standard (non-fast track) specifications, join the owning task group's email list and go to meetings. This is the earliest way to influence a specification. Issues can be posted to the email list or GitHub issues.

• Participate in the Internal Review. All specifications need a Ratification Plan that includes an Governing Committee Review. The best way to find out about the ratification plans is to find the specification in the Specification Status wiki page and review the details.

• Participate in the Public Review.  Review details are sent to the tech-announce and isa-dev mailing lists and occur for at least a 30 day period.

We require that all open issues are resolved before going for ratification by the TSC and BOD. However, we cannot satisfy everyone's requests but we aim to make sure everyone feels heard.

If you have gone through this process and don't feel heard or you think we missed something, you can either contact help@riscv.org or your elected official at TSC (the elected officials are announced on tech-announce).

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, Decimal Floating-Point and Transactional Memory. One goal for RISC-V International 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).

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.

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.

What about Vendor ID assignment for RISC-V implementations?

RISC-V International 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 RISC-V Instruction Set Manual Volue II: Privileged Architecture specification here.

3.1.2 Machine Vendor ID Register mvendorid

The mvendorid CSR is an 32-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.