RISC-V


RISC-V is an open standard instruction set architecture based on established reduced instruction set computer principles. Unlike most other ISA designs, the RISC-V ISA is provided under open source licenses that do not require fees to use. A number of companies are offering or have announced RISC-V hardware, open source operating systems with RISC-V support are available and the instruction set is supported in several popular software toolchains.
Notable features of the RISC-V ISA include a load–store architecture, bit patterns to simplify the multiplexers in a CPU, IEEE 754 floating-point, a design that is architecturally neutral, and placing most-significant bits at a fixed location to speed sign extension.
The instruction set is designed for a wide range of uses. It is variable-width and extensible so that more encoding bits can always be added. It supports three word-widths, 32, 64, and 128 bits, and a variety of subsets. The definitions of each subset vary slightly for the three word-widths. The subsets support small embedded systems, personal computers, supercomputers with vector processors, and warehouse-scale 19 inch rack-mounted parallel computers.
The instruction set space for the 128-bit stretched version of the ISA was reserved because 60 years of industry experience has shown that the most unrecoverable error in instruction set design is a lack of memory address space., the 128-bit ISA remains undefined intentionally, because there is yet so little practical experience with such large memory systems. There are proposals to implement variable-width instructions up to 864-bits.
The project began in 2010 at the University of California, Berkeley along with many volunteer contributors not affiliated with the university. Unlike other academic designs which are typically optimized only for simplicity of exposition, the designers intended that the RISC-V instruction set be useable for practical computers.
As of June 2019, version 2.2 of the user-space ISA and version 1.11 of the privileged ISA are frozen, permitting software and hardware development to proceed. A debug specification is available as a draft, version 0.13.2.

Rationale

requires design expertise in several specialties: electronic digital logic, compilers, and operating systems. To cover the costs of such a team, commercial vendors of computer designs, such as ARM Holdings and MIPS Technologies charge royalties for the use of their designs, patents and copyrights. They also often require non-disclosure agreements before releasing documents that describe their designs' detailed advantages. In many cases, they never describe the reasons for their design choices.
RISC-V was started with a goal to make a practical ISA that was open-sourced, usable academically and in any hardware or software design without royalties. Also, the rationales for every part of the project are explained, at least broadly. The RISC-V authors are academic but have substantial experience in computer design. The RISC-V ISA is a direct development from a series of academic computer-design projects. It was originated in part to aid such projects.
In order to build a large, continuing community of users and therefore accumulate designs and software, the RISC-V ISA designers planned to support a wide variety of practical uses: Small, fast, and low-power real-world implementations, without over-architecting for a particular microarchitecture. A need for a large base of contributors is part of the reason why RISC-V was engineered to fit so many uses.
The designers say that the instruction set is the main interface in a computer because it lies between the hardware and the software. If a good instruction set were open, available for use by all, then it should dramatically reduce the cost of software by permitting far more reuse. It should also increase competition among hardware providers, who can use more resources for design and less for software support.
The designers assert that new principles are becoming rare in instruction set design, as the most successful designs of the last forty years have become increasingly similar. Of those that failed, most did so because their sponsoring companies failed commercially, not because the instruction sets were poor technically. So, a well-designed open instruction set designed using well-established principles should attract long-term support by many vendors.
RISC-V also supports the designers' academic uses. The simplicity of the integer subset permits basic student exercises. The integer subset is a simple ISA enabling software to control research machines. The variable-length ISA enables extensions for both student exercises and research. The separated privileged instruction set permits research in operating system support, without redesigning compilers. RISC-V's open intellectual property allows its designs to be published, reused, and modified.

History

The term RISC dates from about 1980. Before this, there was some knowledge that simpler computers could be effective, but the design principles were not widely described. Simple, effective computers have always been of academic interest. Academics created the RISC instruction set DLX for the first edition of Computer Architecture: A Quantitative Approach in 1990. David Patterson was an author, and later assisted RISC-V. DLX was intended for educational use; academics and hobbyists implemented it using field-programmable gate arrays, but it was not a commercial success. ARM CPUs, versions 2 and earlier, had a public-domain instruction set, and it is still supported by the GNU Compiler Collection, a popular free-software compiler. Three open-source cores exist for this ISA, but they have not been manufactured. OpenRISC is an open-source ISA based on DLX, with associated RISC designs. It is fully supported with GCC and Linux implementations. However, it has few commercial implementations.
Krste Asanović at the University of California, Berkeley, found many uses for an open-source computer system. In 2010, he decided to develop and publish one in a "short, three-month project over the summer". The plan was to help both academic and industrial users. David Patterson at Berkeley also aided the effort. He originally identified the properties of Berkeley RISC, and RISC-V is one of his long series of cooperative RISC research projects. At this stage, students inexpensively provided initial software, simulations, and CPU designs.
The RISC-V authors and their institution originally provided the ISA documents and several CPU designs under BSD licenses, which allow derivative works—such as RISC-V chip designs—to be either open and free, or closed and proprietary. The ISA specification itself was effectively put into the public domain when the ISA tech reports were published, though the actual tech report text was later put under a Creative Commons license to allow it to be improved by external contributors including RISC-V International.
A full history of RISC-V has been published on the RISC-V International website.

RISC-V Foundation and RISC-V International

Commercial users require an ISA to be stable before they can use it in a product that may last many years. To address this issue, the RISC-V Foundation was formed to own, maintain, and publish intellectual property related to RISC-V's definition. The original authors and owners have surrendered their rights to the foundation.
In November 2019, the RISC-V Foundation announced that it would relocate to Switzerland, citing concerns over U.S. trade regulations. As of March 2020, the organization was named RISC-V International, a Swiss nonprofit business association.
, RISC-V International freely publishes the documents defining RISC-V and permits unrestricted use of the ISA for design of software and hardware. However, only paying members of RISC-V International can vote to approve changes, or use the trademarked compatibility logo.

Awards

ISA base and extensions

RISC-V has a modular design, consisting of alternative base parts, with added optional extensions. The ISA base and its extensions are developed in a collective effort between industry, the research community and educational institutions. The base specifies instructions, control flow, registers, memory and addressing, logic manipulation, and ancillaries. The base alone can implement a simplified general-purpose computer, with full software support, including a general-purpose compiler.
The standard extensions are specified to work with all of the standard bases, and with each other without conflict.
Many RISC-V computers might implement the compact extension to reduce power consumption, code size, and memory use. There are also future plans to support hypervisors and virtualization.
Together with a supervisor instruction set extension, S, an RVGC defines all instructions needed to conveniently support a general purpose operating system.
To tame the combinations of functionality that may be implemented, a nomenclature is defined to specify them. The instruction set base is specified first, coding for RISC-V, the register bit-width, and the variant; e.g., RV64I or RV32E. Then follows letters specifying implemented extensions in canonical order. The base, extended integer and floating point calculations, and synchronisation primitives for multi-core computing, the base and extensions MAFD, are considered to be necessary for general-purpose computation, and thus have the shorthand, G.
A small 32-bit computer for an embedded system might be RV32EC. A large 64-bit computer might be RV64GC; i.e., shorthand for RV64IMAFDC.
A naming scheme with Zxxx for standard extensions and Yxxx for non-standard extensions has been proposed. For example, the Ztso extension for total store ordering, an alternative memory consistency model to weak memory ordering, is under discussion.

Register sets

RISC-V has 32 integer registers, and, when the floating-point extension is implemented, separate 32 floating-point registers. Except for memory access instructions, instructions address only registers.
The first integer register is a zero register, and the remainder are general-purpose registers. A store to the zero register has no effect, and a read always provides 0. Using the zero register as a placeholder makes for a simpler instruction set.
becomes.
Control and status registers exist, but user-mode programs can access only those used for performance measurement and floating-point management.
No instructions exist to save and restore multiple registers. Those were thought to be needless, too complex, and perhaps too slow.

Memory access

Like many RISC designs, RISC-V is a load–store architecture: instructions address only registers, with load and store instructions conveying to and from memory.
Most load and store instructions include a 12-bit offset and two register identifiers. One register is the base register. The other register is the source or destination
The offset is added to a base register to get the address. Forming the address as a base register plus offset allows single instructions to access data structures. For example, if the base register points to the top of a stack, single instructions can access a subroutine's local variables in the stack. Likewise the load and store instructions can access a record-style structure or a memory-mapped I/O device. Using the constant zero register as a base address allows single instructions to access memory near address zero.
Memory is addressed as 8-bit bytes, with words being in little-endian order. Words, up to the register size, can be accessed with the load and store instructions.
Accessed memory addresses need not be aligned to their word-width, but accesses to aligned addresses may be faster; for example, simple CPUs may implement unaligned accesses with slow software emulation driven from an alignment failure interrupt.
Like many RISC instruction sets, RISC-V lacks address-modes that write back to the registers. For example, it does not auto-increment.
RISC-V manages memory systems that are shared between CPUs or threads by ensuring a thread of execution always sees its memory operations in the programmed order. But between threads and I/O devices, RISC-V is simplified: It doesn't guarantee the order of memory operations, except by specific instructions, such as.
A instruction guarantees that the results of predecessor operations are visible to successor operations of other threads or I/O devices. can guarantee the order of combinations of both memory and memory-mapped I/O operations. E.g. it can separate memory read and write operations, without affecting I/O operations. Or, if a system can operate I/O devices in parallel with memory, doesn't force them to wait for each other. One CPU with one thread may decode as.
RISC-V is little-endian to resemble other familiar, successful computers, for example, x86. This also reduces a CPU's complexity and costs slightly because it reads all sizes of words in the same order. For example, the RISC-V instruction set decodes starting at the lowest-addressed byte of the instruction. The specification leaves open the possibility of non-standard big-endian or bi-endian systems.
Some RISC CPUs place 16 bits of offset in the loads and stores. They set the upper 16 bits by a load upper word instruction. This permits upper-halfword values to be set easily, without shifting bits. However, most use of the upper half-word instruction makes 32-bit constants, like addresses. RISC-V uses a SPARC-like combination of 12-bit offsets and 20-bit set upper instructions. The smaller 12-bit offset helps compact, 32-bit load and store instructions select two of 32 registers yet still have enough bits to support RISC-V's variable-length instruction coding.

Immediates

RISC-V handles 32-bit constants and addresses with instructions that set the upper 20 bits of a 32-bit register. Load upper immediate loads 20 bits into bits 31 through 12. Then a second instruction such as can set the bottom 12 bits.
This method is extended to permit position-independent code by adding an instruction, that generates 20 upper address bits by adding an offset to the program counter and storing the result into a base register. This permits a program to generate 32-bit addresses that are relative to the program counter.
The base register can often be used as-is with the 12-bit offsets of the loads and stores. If needed, can set the lower 12-bits of a register. In 64-bit and 128-bit ISAs, and sign-extend the result to get the larger address.
Some fast CPUs may interpret combinations of instructions as single fused instructions. or may be good candidates to fuse with, loads or stores.

Subroutine calls, jumps, and branches

RISC-V's subroutine call places its return address in a register. This is faster in many computer designs, because it saves a memory access compared to systems that push a return address directly on a stack in memory. has a 20-bit signed offset. The offset is multiplied by 2, then added to the PC to generate a relative address to a 32-bit instruction. If the result is not at a 32-bit address, the CPU may force an exception.
RISC-V CPUs jump to calculated addresses using a jump and link-register, instruction. is similar to, but gets its destination address by adding a 12-bit offset to a base register.
's bit format is like the register-relative loads and stores. Like them, can be used with the instructions that set the upper 20 bits of a base register to make 32-bit branches, either to an absolute address or a PC-relative one.
RISC-V recycles and to get unconditional 20-bit PC-relative jumps and unconditional register-based 12-bit jumps. Jumps just make the linkage register 0 so that no return address is saved.
RISC-V also recycles to return from a subroutine: To do this, 's base register is set to be the linkage register saved by or. 's offset is zero and the linkage register is zero, so that there is no offset, and no return address is saved.
Like many RISC designs, in a subroutine call, a RISC-V compiler must use individual instructions to save registers to the stack at the start, and then restore these from the stack on exit. RISC-V has no save multiple or restore multiple register instructions. These were thought to make the CPU too complex, and possibly slow. This can take more code space. Designers planned to reduce code size with library routines to save and restore registers.
RISC-V has no condition code register or carry bit. The designers believed that condition codes make fast CPUs more complex by forcing interactions between instructions in different stages of execution. This choice makes multiple-precision arithmetic more complex. Also, a few numerical tasks need more energy. As a result, predication is not supported. The designers claim that very fast, out-of-order CPU designs do predication anyway, by doing the comparison branch and conditional code in parallel, then discarding the unused path's effects. They also claim that even in simpler CPUs, predication is less valuable than branch prediction, which can prevent most stalls associated with conditional branches. Code without predication is larger, with more branches, but they also claim that a compressed instruction set solves that problem in most cases.
Instead, RISC-V has short branches that perform comparisons: equal, not-equal, less-than, unsigned less-than, greater-than or equal and unsigned greater-than or equal. Ten comparison-branch operations are implemented with only six instructions, by reversing the order of operands in the assembler. For example, branch if greater than can be done by less-than with a reversed order of operands.
The comparing branches have a twelve-bit signed range, and jump relative to the PC.
Unlike some RISC architectures, RISC-V does not include a branch delay slot, a position after a branch instruction that can be filled with an instruction that is executed whether or not the branch is taken. RISC-V omits a branch delay slot because it complicates multicycle CPUs, superscalar CPUs, and long pipelines. Dynamic branch predictors have succeeded well enough to reduce the need for delayed branches.
On the first encounter with a branch, RISC-V CPUs should assume that a negative relative branch will be taken. This assumes that a backward branch is a loop, and provides a default direction so that simple pipelined CPUs can fill their pipeline of instructions. Other than this, RISC-V does not require branch prediction, but core implementations are allowed to add it. RV32I reserves a "HINT" instruction space that presently does not contain any hints on branches.

Arithmetic and logic sets

RISC-V segregates math into a minimal set of integer instructions with add, subtract, shift, bit-wise logic and comparing-branches. These can simulate most of the other RISC-V instruction sets with software. RISC-V currently lacks the count leading zero and bit-field operations normally used to speed software floating-point in a pure-integer processor.
The integer multiplication instructions includes signed and unsigned multiply and divide. Double-precision integer multiplies and divides are included, as multiplies and divides that produce the high word of the result. The ISA document recommends that implementors of CPUs and compilers fuse a standardized sequence of high and low multiply and divide instructions to one operation if possible.
The floating-point instructions includes single-precision arithmetic and also comparison-branches similar to the integer arithmetic. It requires an additional set of 32 floating-point registers. These are separate from the integer registers. The double-precision floating point instructions generally assume that the floating-point registers are 64-bit, and the F subset is coordinated with the D set. A quad-precision 128-bit floating-point ISA is also defined. RISC-V computers without floating-point can use a floating-point software library.
RISC-V does not cause exceptions on arithmetic errors, including overflow, underflow, subnormal, and divide by zero. Instead, both integer and floating-point arithmetic produce reasonable default values and set status bits. Divide-by-zero can be discovered by one branch after the division. The status bits can be tested by an operating system or periodic interrupt.

Atomic memory operations

RISC-V supports computers that share memory between multiple CPUs and threads. RISC-V's standard memory consistency model is release consistency. That is, loads and stores may generally be reordered, but some loads may be designated as acquire operations which must precede later memory accesses, and some stores may be designated as release operations which must follow earlier memory accesses.
The base instruction set includes minimal support in the form of a instruction to enforce memory ordering. Although this is sufficient, combined operations can be more efficient.
The atomic memory operation extension supports two types of atomic memory operations for release consistency. First, it provides general purpose load-reserved and store-conditional instructions. performs a load, and tries to reserve that address for its thread. A later store-conditional to the reserved address will be performed only if the reservation is not broken by an intervening store from another source. If the store succeeds, a zero is placed in a register. If it failed, a non-zero value indicates that software needs to retry the operation. In either case, the reservation is released.
The second group of atomic instructions perform read-modify-write sequences: a load to a destination register, then an operation between the loaded value and a source register, then a store of the result. Making the memory barriers optional permits combining the operations. The optional operations are enabled by acquire and release bits which are present in every atomic instruction. RISC-V defines nine possible operations: swap ; add; bitwise and, or, and exclusive-or; and signed and unsigned minimum and maximum.
A system design may optimize these combined operations more than and. For example, if the destination register for a swap is the constant zero, the load may be skipped. If the value stored is unmodified since the load, the store may be skipped.
The IBM System/370 and its successors including z/Architecture, and x86, both implement a compare-and-swap instruction, which tests and conditionally updates a location in memory: if the location contains an expected old value, replaces it with a given new value; it then returns an indication of whether it made the change. However, a simple load-type instruction is usually performed before the to fetch the old value. The classic problem is that if a thread reads a value A, calculates a new value C, and then uses to replace A with C, it has no way to know whether concurrent activity in another thread has replaced A with some other value B and then restored the A in between. In some algorithms, this ABA problem can lead to incorrect results. The most common solution employs a double-wide instruction to update both the pointer and an adjacent counter; unfortunately, such an instruction requires a special instruction format to specify multiple registers, performs several reads and writes, and can have complex bus operation.
The / alternative is more efficient. It usually requires only one memory load, and minimizing slow memory operations is desirable. It's also exact: it controls all accesses to the memory cell, rather than just assuring a bit pattern. However, unlike, it can permit livelock, in which two or more threads repeatedly cause each other's instructions to fail. RISC-V guarantees forward progress It must use only the I subset. 2) To prevent repetitive cache misses, the code It must include no system or fence instructions, or taken backward branches between the and. 4) The backward branch to the retry loop must be to the original sequence.
The specification gives examples of how to use this subset to lock a data structure.

Compressed subset

The standard RISC-V ISA specifies that all instructions are 32 bits. This makes for a particularly simple implementation, but like other RISC processors with such an instruction encoding, results in larger code size than in other instruction sets.
To compensate, RISC-V's 32-bit instructions are actually 30 bits; of the opcode space is reserved for an optional variable-length compressed instruction set, RVC, that includes 16-bit instructions. Like ARM's Thumb and the MIPS16, the compressed instructions are simply aliases for a subset of the larger instructions. Unlike ARM's Thumb or the MIPS compressed set, space was reserved from the beginning so there is no separate operating mode. Standard and compressed instructions may be intermixed freely.
Because the compressed instructions are simply alternate encodings for a selected subset of larger instructions, the compression can be implemented in the assembler, and it is not essential for the compiler to even know about it.
A prototype of RVC was tested in 2011. The prototype code was 20% smaller than an x86 PC and MIPS compressed code, and 2% larger than ARM Thumb-2 code. It also substantially reduced both the needed cache memory and the estimated power use of the memory system.
The researcher intended to reduce the code's binary size for small computers, especially embedded computer systems. The prototype included 33 of the most frequently used instructions, recoded as compact 16-bit formats using operation codes previously reserved for the compressed set. The compression was done in the assembler, with no changes to the compiler. Compressed instructions omitted fields that are often zero, used small immediate values or accessed subsets of the registers. is very common and often compressible.
Much of the difference in size compared to ARM's Thumb set occurred because RISC-V, and the prototype, have no instructions to save and restore multiple registers. Instead, the compiler generated conventional instructions that access the stack. The prototype RVC assembler then often converted these to compressed forms that were half the size. However, this still took more code space than the ARM instructions that save and restore multiple registers. The researcher proposed to modify the compiler to call library routines to save and restore registers. These routines would tend to remain in a code cache and thus run fast, though probably not as fast as a save-multiple instruction.
Standard RVC requires occasional use of 32-bit instructions. Several nonstandard RVC proposals are complete, requiring no 32-bit instructions, and are said to have higher densities than standard RVC. Another proposal builds on these, and claims to use less coding range as well.

Embedded subset

An instruction set for the smallest embedded CPUs is reduced in other ways: Only 16 of the 32 integer registers are supported. Floating-point instructions should not be supported, so a floating-point software library must be used. The compressed set C is recommended. The privileged instruction set supports only machine mode, user mode and memory schemes that use base-and-bound address relocation.
Discussion has occurred for a microcontroller profile for RISC-V, to ease development of deeply embedded systems. It centers on faster, simple C-language support for interrupts, simplified security modes and a simplified POSIX application binary interface.
Correspondents have also proposed smaller, non-standard, 16-bit RV16E ISAs: Several serious proposals would use the 16-bit C instructions with 8 × 16-bit registers. An April fools' joke proposed a very practical arrangement: Utilize 16 × 16-bit integer registers, with the standard EIMC ISAs The joke was to propose bank-switching registers, when a 32-bit CPU would be clearly superior.

Privileged instruction set

RISC-V's ISA includes a separate privileged instruction set specification., version 1.11 is ratified by RISC-V International.
Version 1.11 of the specification supports several types of computer systems:
  1. Systems that have only machine mode, perhaps for embedded systems,
  2. Systems with both machine mode and user-mode to implement operating systems that run the kernel in a privileged mode.
  3. Systems with machine-mode, hypervisors, multiple supervisors, and user-modes under each supervisor.
These correspond roughly to systems with up to four rings of privilege and security, at most: machine, hypervisor, supervisor and user. Each layer also is expected to have a thin layer of standardized supporting software that communicates to a more-privileged layer, or hardware.
The overall plan for this ISA is to make the hypervisor mode orthogonal to the user and supervisor modes. The basic feature is a configuration bit that either permits supervisor-level code to access hypervisor registers, or causes an interrupt on accesses. This bit lets supervisor mode directly handle the hardware needed by a hypervisor. This simplifies a type 2 hypervisor, hosted by an operating system. This is a popular mode to run warehouse-scale computers. To support type 1, unhosted hypervisors, the bit can cause these accesses to interrupt to a hypervisor. The bit simplifies nesting of hypervisors, in which a hypervisor runs under a hypervisor. It's also said to simplify supervisor code by letting the kernel use its own hypervisor features with its own kernel code. As a result, the hypervisor form of the ISA supports five modes: machine, supervisor, user, supervisor-under-hypervisor and user-under-hypervisor.
The privileged instruction set specification explicitly defines hardware threads, or harts. Multiple hardware threads are a common practice in more-capable computers. When one thread is stalled, waiting for memory, others can often proceed. Hardware threads can help make better use of the large number of registers and execution units in fast out-of-order CPUs. Finally, hardware threads can be a simple, powerful way to handle interrupts: No saving or restoring of registers is required, simply executing a different hardware thread. However, the only hardware thread required in a RISC-V computer is thread zero.
The existing control and status register definitions support RISC-V's error and memory exceptions, and a small number of interrupts. For systems with more interrupts, the specification also defines an interrupt controller. Interrupts always start at the highest-privileged machine level, and the control registers of each level have explicit forwarding bits to route interrupts to less-privileged code. For example, the hypervisor need not include software that executes on each interrupt to forward an interrupt to an operating system. Instead, on set-up, it can set bits to forward the interrupt.
Several memory systems are supported in the specification. Physical-only is suited to the simplest embedded systems. There are also three UNIX-style virtual memory systems for memory cached in mass-storage systems. The virtual memory systems have three sizes, with addresses sized 32, 39 and 48-bits. All virtual memory systems support 4 KiB pages, multilevel page-table trees and use very similar algorithms to walk the page table trees. All are designed for either hardware or software page-table walking. To optionally reduce the cost of page table walks, super-sized pages may be leaf pages in higher levels of a system's page table tree. SV32 has a two layer page table tree and supports 4 MiB superpages. SV39 has a three level page table, and supports 2 MiB superpages and 1 GiB gigapages. SV48 is required to support SV39. It also has a 4-level page table and supports 2 MiB superpages, 1 GiB gigapages, and 512 GiB terapages. Superpages are aligned on the page boundaries for the next-lowest size of page.

Bit manipulation

An unapproved bit-manipulation ISA for RISC-V was under review in January 2020. Done well, a bit-manipulation subset can aid cryptographic, graphic, and mathematical operations. The criteria for inclusion documented in the draft were compliance with RV5 philosophies and ISA formats, substantial improvements in code density or speed, and substantial real-world applications, including preexisting compiler support. Version 0.92 includes instructions to count leading zeros, count one bits, perform logic operations with complement, pack two words in one register, take the min or max, sign-extend, single-bit operations, shift ones, rotates, a generalized bit-reverse and shuffle, or-combines, bit-field place and extract, carry-less multiply, CRC instructions, bit matrix operations, conditional mix, conditional move, funnel shifts, and unsigned address calculations.

Packed SIMD

Packed-SIMD instructions are widely used by commercial CPUs to inexpensively accelerate multimedia and other digital signal processing. For simple, cost-reduced RISC-V systems, the base ISA's specification proposed to use the floating-point registers' bits to perform parallel single instruction, multiple data sub-word arithmetic.
In 2017 a vendor published a more detailed proposal to the mailing list, and this can be cited as version 0.1., the efficiency of this proposed ISA varies from 2x to 5x a base CPU for a variety of DSP codecs. The proposal lacked instruction formats and a license assignment to RISC-V International, but it was reviewed by the mailing list. Some unpopular parts of this proposal were that it added a condition code, the first in a RISC-V design, linked adjacent registers, and has a loop counter that could be difficult to implement in some microarchitectures.
A previous, well-regarded implementation for a 64-bit CPU was PA-RISC's multimedia instructions: Multimedia Acceleration eXtensions. It increased the CPU's performance on digital signal processing tasks by 48-fold or more, enabling practical real-time video codecs in 1995. Besides its native 64-bit math, the PA-RISC MAX2 CPU could do arithmetic on four 16-bit subwords at once, with several overflow methods. It also could move subwords to different positions. PA-RISC's MAX2 was intentionally simplified. It lacked support for 8-bit or 32-bit subwords. The 16-bit subword size was chosen to support most digital signal processing tasks. These instructions were inexpensive to design and build.

Vector set

The proposed vector-processing instruction set may make the packed SIMD set obsolete. The designers hope to have enough flexibility that a CPU can implement vector instructions in a standard processor's registers. This would enable minimal implementations with similar performance to a multimedia ISA, as above. However, a true vector coprocessor could execute the same code with higher performance.
, the vector-processing proposal is a conservative, flexible design of a general-purpose mixed-precision vector processor, suitable to execute compute kernels. Code would port easily to CPUs with differing vector lengths, ideally without recompiling.
In contrast, short-vector SIMD extensions are less convenient. These are used in x86, ARM and PA-RISC. In these, a change in word-width forces a change to the instruction set to expand the vector registers, to 256-bit Advanced Vector Extensions. The result is a growing instruction set, and a need to port working code to the new instructions.
In the RISC-V vector ISA, rather than fix the vector length in the architecture, an instruction is available which takes a requested size and sets the vector length to the minimum of the hardware limit and the requested size. So, the RISC-V proposal is more like a Cray's long-vector design or ARM's Scalable Vector Extension. That is, each vector in up to 32 vectors is the same length.
The application specifies the total vector width it requires, and the processor determines the vector length it can provide with available on-chip resources. This takes the form of an instruction with four immediate operands, specifying the number of vector registers of each available width needed. The total must be no more than the addressable limit of 32, but may be less if the application does not require them all. The vector length is limited by the available on-chip storage divided by the number of bytes of storage needed for each entry.
Outside of vector loops, the application can request zero-vector registers, saving the operating system the work of preserving them on context switches.
The vector length is not only architecturally variable, but designed to vary at run time also. To achieve this flexibility, the instruction set is likely to use variable-width data paths and variable-type operations using polymorphic overloading. The plan is that these can reduce the size and complexity of the ISA and compiler.
Recent experimental vector processors with variable-width data paths also show profitable increases in operations per: second, area, and watt.
Unlike a typical modern graphics processing unit, there are no plans to provide special hardware to support branch predication. Instead, lower cost compiler-based predication will be used.

External debug system

There is a preliminary specification for RISC-V's hardware-assisted debugger. The debugger will use a transport system such as Joint Test Action Group or Universal Serial Bus to access debug registers. A standard hardware debug interface may support either a standardized abstract interface or instruction feeding.
, the exact form of the abstract interface remains undefined, but proposals include a memory mapped system with standardized addresses for the registers of debug devices or a command register and a data register accessible to the communication system. Correspondents claim that similar systems are used by Freescale's background debug mode interface for some CPUs, ARM, OpenRISC, and Aeroflex's LEON.
In instruction feeding, the CPU will process a debug exception to execute individual instructions written to a register. This may be supplemented with a data-passing register and a module to directly access the memory. Instruction feeding lets the debugger access the computer exactly as software would. It also minimizes changes in the CPU, and adapts to many types of CPU. This was said to be especially apt for RISC-V because it is designed explicitly for many types of computers. The data-passing register allows a debugger to write a data-movement loop to RAM, and then execute the loop to move data into or out of the computer at a speed near the maximum speed of the debug system's data channel. Correspondents say that similar systems are used by MIPS Technologies MIPS, Intel Quark, Tensilica's Xtensa, and for Freescale Power ISA CPUs' background debug mode interface.
A vendor proposed a hardware trace subsystem for standardization, donated a conforming design, and initiated a review. The proposal is for a hardware module that can trace code execution on most RV5 CPUs. To reduce the data rate, and permit simpler or less-expensive paths for the trace data, the proposal does not generate trace data that could be calculated from a binary image of the code. It sends only data that indicates "uninferrable" paths through the program, such as which conditional branches are taken. To reduce the data rates, branches that can be calculated, such as unconditional branches, are not traced. The proposed interface between the module and the control unit is a logic signal for each uninferrable type of instruction. Addresses and other data are to be provided in a specialized bus attached to appropriate data sources in a CPU. The data structure sent to an external trace unit is a series of short messages with the needed data. The details of the data channel are intentionally not described in the proposal, because several are likely to make sense.

Implementations

The RISC-V organization maintains a list of RISC-V CPU and SoC implementations.

Existing

Existing commercial implementations include:
There are many open-sourced RISC-V CPU designs, including:
A normal problem for a new instruction set is a lack of CPU designs and software. Both issues limit its usability and reduce adoption.
The design software includes a design compiler, Chisel, which can reduce the designs to Verilog for use in devices. The website includes verification data for testing core implementations.
Available RISC-V software tools include a GNU Compiler Collection toolchain, an LLVM toolchain, the OVPsim simulator, the Spike simulator, and a simulator in QEMU.
Operating system support exists for the Linux kernel, FreeBSD, and NetBSD, but the supervisor-mode instructions were unstandardized prior to June 2019, so this support is provisional. The preliminary FreeBSD port to the RISC-V architecture was upstreamed in February 2016, and shipped in FreeBSD 11.0. Ports of Debian and Fedora are stabilizing. A port of Das U-Boot exists. UEFI Spec v2.7 has defined the RISC-V binding and a TianoCore port has been done by HPE engineers and is expected to be upstreamed. There is a preliminary port of the seL4 microkernel. Hex Five released the first Secure IoT Stack for RISC-V with FreeRTOS support. Also xv6, a modern reimplementation of Sixth Edition Unix in ANSI C used for pedagogical purposes in MIT, was ported. Pharos RTOS has been ported to 64-bit RISC-V. Also see Comparison of real-time operating systems.
A simulator exists to run a RISC-V Linux system on a web browser using JavaScript.
QEMU supports running 32 and 64-bit RISC-V systems with a number of emulated or virtualized devices, as well running RISC-V Linux binaries. It does support multi-core emulation.