RISC-V

RISC-V
Designer University of California, Berkeley
Bits 32, 64, 128
Introduced 2010
Version 2.1
Design RISC
Type Load-store
Encoding Variable
Branching Compare-and-branch
Endianness Little
Extensions M, A, F, D, Q, C, P
Open Yes
Registers
General purpose 16, 32 (x0=0)
Floating point 32
RISC-V processor prototype, January 2013

RISC-V (pronounced "risk-five") is an open-source instruction set architecture (ISA) based on established reduced instruction set computing (RISC) principles.

In contrast to most ISAs, RISC-V is freely available for all types of use, permitting anyone to design, manufacture and sell RISC-V chips and software. While not the first open ISA, it is significant because it is designed to be useful in modern computerized devices such as warehouse-scale cloud computers, high-end mobile phones and the smallest embedded systems. Such uses demand that the designers consider both performance and power efficiency. The instruction set also has a substantial body of supporting software, which fixes a usual weakness of new instruction sets.

The project was originated in 2010 by researchers in the Computer Science Division at University of California, Berkeley, but many contributors are volunteers and industry workers otherwise unaffiliated with the university.[1]

The RISC-V ISA has been designed with small, fast, and low-power real-world implementations in mind,[2][3] but without over-architecting for a particular microarchitecture style.[3][4][5][6]

As of 2016, version 2.1 of the userspace ISA is fixed.[3]

Significance

The RISC-V authors aim to provide several CPU designs freely available under a BSD license. Such licenses allow derivative works, such as RISC-V chip designs, to be either open and free, like RISC-V itself, or closed and proprietary. This is unlike the alternative OpenRISC cores, which under the GPL license, requires derivative works to be open.

By contrast, commercial chip vendors such as ARM Holdings and MIPS Technologies charge substantial license fees for the use of their patents.[7] They also require non-disclosure agreements before releasing documents that describe their designs' advantages and instruction set. Many design advances are completely proprietary, never described even to customers. The secrecy interferes with legitimate public educational use, security auditing, and the development of public, lowcost free and open-source software compilers, and operating systems.

Developing a CPU requires design expertise in several specialties: electronic logic, compilers, and operating systems. It's rare to find this outside of a professional engineering team. The result is that modern, high-quality general-purpose computer instruction sets have not recently been widely available anywhere, or even explained, except in academic settings. Because of this, many RISC-V contributors see it as a unified community effort. This need for a large base of contributors is part of the reason why RISC-V was engineered to fit so many uses.

The RISC-V authors also have substantial research and user-experience validating their designs in silicon and simulation. 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.[3][8]

History

Predecessors

The term "RISC" dates from about 1980.[9] 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. However DLX was for educational use. Academics and hobbyists implemented it using field-programmable gate arrays, but it was not a commercial success.

ARM CPUs, version 2 and earlier, had a public-domain instruction set, and it is still supported by the GCC, a popular free software compiler. This helped promote acceptance of the ARM architecture. Three open-source cores exist for this ISA, but they have not been manufactured.[10][11]

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.

Foundation

Krste Asanovic at 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.[8] David Patterson at Berkeley also aided the effort. Patterson originally identified the properties of Berkeley RISC,[9] and RISC-V is one of his long series of cooperative RISC research projects. Early funding was from DARPA.[3]

Requirements Motivating RISC-V

The designers claim 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, it should dramatically reduce the cost of software by permitting much more reuse of the software. It should also increase competition among hardware providers, who can use more resources for design and less for software support.[8]

The designers claim that new principles are becoming rare in instruction-set design, as the most successful designs of the last forty years have become increasingly similar. Most of these that failed, failed because their sponsoring companies failed commercially, not because the instruction-sets were technically poor. So, a well-designed open instruction set designed using well-established principles should attract long-term support by many vendors.[8]

Unlike other academic designs which are optimized only for simplicity of exposition, the designers claim that the RISC-V instruction set is for practical computers. It's said to have features to increase a computer's speed yet reduce its cost and power use. These include a load-store design, bit patterns to simplify the multiplexers in a CPU, simplified standards-based floating-point, a design that is architecturally neutral and placing most-significant bits at a fixed location to speed sign-extension. Sign extension is said to often be on the critical timing path.[3]

The designers claim that RISC-V CPUs can achieve higher speeds, and smaller, lower-power and lower-cost electronics, than some comparable commercial CPUs.[2]

The instruction set is designed for a wide range of uses. 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 rack-mounted parallel computers.

The instruction set is variable-width and extensible, so that more encoding bits can always be added. 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 (in 2016) intentionally undefined because there is so little practical experience, yet, with such large memory systems.[3]

However, RISC-V does also support 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.[3] The separated privileged instruction-set permits research in operating system-support, without redesigning compilers.[12] RISC-V's open intellectual property means that its designs can be published, reused and modified.[3]

Software

A normal problem for a new instruction set is a lack of CPU designs and software.

The RISC-V website has a specification for user-mode instructions, and a preliminary specification for a general-purpose privileged instruction set, to support operating systems.[13]

There are also seven open-sourced CPU designs, the 64-bit Berkeley Out of Order Machine (BOOM),[14] 64-bit Rocket,[15] and five 32-bit Sodor CPUs.[16] The three-stage Sodor CPU appears apt for a small embedded CPU. Rocket may suit compact, low-power intermediate computers such as personal devices. BOOM utilizes much of the infrastructure created for Rocket, and may be usable for personal, supercomputer and warehouse-scale computers.

The design software includes a design compiler, Chisel,[17] 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 (GCC) toolchain (with GDB, the debugger), an LLVM toolchain, a simulator (Spike) and a standard simulator QEMU.

Operating system support exists for GNU/Linux, FreeBSD, and NetBSD, but the supervisor-mode instructions are unstandardized as of 10 November 2016,[12] so this support is provisional. The preliminary FreeBSD port to the RISC-V architecture was upstreamed in February 2016, and will ship in FreeBSD 11.0.[18][19] A port of Fedora is in progress, and most utilities for a standard disk image are complete.[20] There is also a simulator to run a RISC-V Linux system on a web browser using JavaScript.

Adopters

Similar projects

Design

Instruction Subsets

The minimum, mandatory set of RISC-V instructions is the integer instruction set. (Indicated with a letter "I".) This set by itself can implement a simplified general-purpose computer, with full software support, including a general-purpose compiler.[3]

A computer design may add further subsets: Integer multiplication and division (set "M"), Atomic instructions for handling real-time concurrency ("A"), IEEE Floating point ("F") with Double-precision ("D") and Quad-precision ("Q") options.[3] A "privileged" instruction set defines instructions to support a UNIX-style operating system. There are plans for it to support hypervisors, to support virtualization.[12] A computer with all of these instruction sets, an "RVIAFDP" is said to be "general-purpose" summarized as "G".[3]

There's an optional "compact" subset to reduce code size. (set "C") Many RISC-V computers might add this ISA to reduce power, code size, and memory.[3] There's also a 32-bit embedded subset ("E") that supports only 16 registers, to reduce the cost of the smallest CPUs.[3]

These sets are further described by the size of the registers, i.e. 32 or 64 bits. There are small differences in each subset for different register sizes.

A small 32-bit computer for an embedded system might be "RV32EC." A large 64-bit computer might be "RV64G."[3]

Subsets are also planned for 128-bit computers, bit-manipulation, decimal floating-point, Packed SIMD (i.e. multimedia), vector processing and transactional memory.[3]

Register Sets

RISC-V has a constant 0 in place of register zero, 31 integer registers and optionally, 32 floating-point registers. All arithmetic, bitwise-logic and subroutine calls reference only registers to avoid delays from accessing memory.

A constant 0 is accessed as register 0. The assembler uses register 0 as a placeholder to make any of several human-readable instructions into one machine instruction, e.g., move rx to ry becomes add r0 to rx and store in ry.[3]

Control and status registers exist, but user-mode programs can only access those used for performance-measurement.

There are no instructions to save and restore multiple registers. Those were thought to be unnecessary, too complex and perhaps too slow.[3]

To reduce circuitry and associated costs, very small ("embedded") RISC-V CPUs (set "E") may have only 16 of the most frequently used registers.[3]

Memory Access

Like many RISC designs, RISC-V is a load-store machine. Only loads and stores access memory.[3]

Memory is addressed as 8-bit bytes. Loads and stores support data sizes from 8 bits to the computer's word size. Loads and stores larger than a byte need not be aligned to their natural word-width, but alignment may increase performance. (E.g. 16-bit, 2-byte data may fetch and store in less time if it is always aligned to start only on even addresses.) This feature reduces code size, and can be supported on simple CPUs with software emulation driven by an alignment failure interrupt.[3]

Words larger than a single byte are "little-endian." I.e. the least significant byte has the smallest address.[3]

Loads and stores can access constants in code, local variables in the stack, or items in a data structure. They calculate the address by adding a 12-bit signed offset to a base register. If the base register is zero, the data or constants can be in low memory.

RISC-V handles 32-bit constants and addresses with instructions that set the upper 20 bits of a 32-bit register. Load upper immediate lui stores 20 bits to bits 31 through 12. Another instruction, auipc generates the same 20 upper address bits by adding its offset to the program counter and storing the result into a base register. This permits position-independent code to have 32-bit addresses relative to the program counter. The base register can be used as-is with the 12-bit offsets of the loads and stores. If needed, addi can set the lower 12-bits of a register. In 64-bit ISAs,lui and auipc sign-extend the result to 64 bits.[3]

Like many RISC CPUs, RISC-V lacks address-modes that "write back" to the registers. For example, it does not do auto-incrementing.[3]

RISC-V is little-endian to resemble other familiar, successful computers. This also reduces a CPU's complexity and costs slightly less 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. Early iterations supported big-endian, the Internet's standard byte order. This was dropped as unnecessary complexity.[3]

Some RISC CPUs (e.g. DLX, Berkeley's RISC-I) 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 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.[3]

Subroutine Calls, Jumps and Branches

RISC-V's subroutine call, "jump and link," jal 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. jal has a 20-bit signed (2's complement) offset. The offset is multiplied by 4, 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 (i.e. evenly divisible by 4), the CPU should force an exception.[3]

RISC-V CPUs jump to calculated addresses using a "jump and link-register," jalr instruction. jalr is similar to jal, but gets its destination address by adding a 12-bit offset to a base register. (In contrast,jal adds a larger 20-bit offset to the PC).

jalr's bit format is like the register-relative loads and stores. So jalr reuses the instructions that set the upper 20 bits of a base register (lui and auipc), as well as the decoding and address generation logic of loads and stores. Also if the base register is the constant zero, jalr calls a fixed address (the offset) at small, fixed positive or negative addresses. The pc-relative upper bits made by auipc permit jalr to make PC-relative 32-bit calls in position-independent code.

RISC-V recycles jal and jalr 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.[3]

RISC-V also recycles jalr to return from a subroutine: To do this, jalr's base register is set to be the linkage register saved by jal or jalr. jalr'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, as well.[31]

RISC-V has no condition codes 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.[3]

Instead, RISC-V has short branches that perform comparisons: equal, not-equal, less-than, unsigned less-than, greater-than and unsigned greater-than. Ten comparison-branch operations are implemented with only six instructions, by reversing the order of operands in the assembler. For example, "less-than-or-equal-to" can be done by "greater-than" with a reversed order of operands.[3]

The comparing branches have a twelve-bit signed range, and jump relative to the PC.[3]

RISC-V's ISA requires default branch predictions for CPUs: Backward conditional branches should be predicted "taken." Forward conditional branches predict "not taken." The predictions are easy to decode in a pipelined CPU: Branch addresses are signed numbers added to the PC. Backward branches have negative two's complement addresses, and therefore have a one in the most significant bit of the address. Forward branches have a zero. The most significant bit is in a fixed location in the operation code in order to speed up the pipeline. Complex CPUs can add branch predictors to work well even with unusual data or situations.

The ISA manual recommends that software be optimized to avoid branch stalls by using the default branch predictions. This reuses the most significant bit of the signed relative address as a "hint bit" to tell whether the conditional branch will be taken or not. So, no other hint bits are needed in the operation codes of RISC-V branches. This makes more bits available in the branch operation codes. Simple, inexpensive CPUs can merely follow the default predictions and still perform well with optimizing compilers. Compilers can still perform statistical path optimization, if desired.[3]

To avoid unnecessary loading of branch prediction electronics, (and therefore unnecessary pipeline stalls) the comparing branch codes should never be used for unconditional jumps.[3]

Since it has no condition codes, RISC-V must do branches instead of branch predication, that is, conditional execution of instructions. Therefore, instructions need fewer bits, because no encoding is needed for the conditions. Also, the designers claim that CPUs without predication are easier to design, and optimizing compilers are less likely to make mistakes. 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 with branch predictors that can prevent most stalls. Code without predication is larger, with more branches, but they also claim that a compressed instruction set (such as RISC-V's set "C") solves that problem in most cases.[3]

Many RISC designs have included a branch delay slot, a position after a branch instruction that can be filled with an instruction which is executed whether or not the branch is taken. This feature can improve the performance of pipelined CPUs by absorbing some of the time wasted if a CPU mispredicts the operation of a conditional branch, and the CPU's pipeline stalls. 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.[3]

Arithmetic and Logic Sets

RISC-V segregates math into a minimal set of integer instructions (set "I") with add, subtract, shift, bit-wise logic and comparing-branches. These can simulate most of the RISC-V instruction sets with software. (The atomic instructions are a notable exception.) 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 (set "M") 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 a single operation if possible. RISC-V's ISA document also recommends fusing a multiply-accumulate operation. (Multiply-accumulate is a core primitive of both digital signal processing and numerical linear algebra, and so is incorporated as part of a common benchmark, Coremark.[3][32])

The floating-point instructions (set "F") includes single-precision arithmetic and also comparison-branches similar to the integer arithmetic. It requires an additional 32 floating-point registers. These are separate from the integer registers. The double-precision floating point instructions (set "D") generally assume that the floating-point registers are 64-bit (i.e. double-width), and the "F" subset is coordinated with the "D" set. A quad-precision 128-bit floating-point ISA ("Q") is also defined. RISC-V computers without floating-point can use a floating-point software library.[3]

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 a single branch after the division. The status bits can be tested by an operating system or periodic interrupt.[3]

The Compressed Set

The standard RISC-V ISA specifies that all instructions are 32 bits. This makes for a particularly simple implementation, but a program's code is larger than in many other instruction sets.[3][31] To compensate, RISC-V reserves opcode space for a variable-length "compressed" instruction set, RVC, that includes 16-bit instructions. Unlike ARM's Thumb or the MIPS compressed set, there is no separate operating mode; standard and compressed instructions may be intermixed freely.[3][31] (letter "C") [33]

A prototype of RVC was tested.[31] The prototype code was 20% smaller than an x86 PC and MIPS compressed code, and 2% larger than ARM Thumb-2 code.[31] It also substantially reduced both the needed cache memory and the estimated power usage of the memory system.[31]

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.[31] 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 (16 or 8) of the registers. addi is very common and often compressible.[31]

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 therefore run fast, though probably not as fast as a save-multiple instruction.[31]

The Embedded Set

An instruction set for the smallest "embedded" CPUs (set "E") is reduced in other ways: Only 16 of the 32-bit integer registers are supported. Floating-point instructions should not be supported (the specification forbids it as uneconomical), so a floating-point software library must be used.[3] 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.[12]

Correspondents have proposed even smaller, nonstandard, 16-bit "RV16E" ISAs: One would use a 16x16-bit integer register file, using the standard "EIMC" ISAs (including 32-bit instructions.) Another proposal would only use the 16-bit "C" instructions with an 8x16-bit register file. A full RV16EG was said to be possible with a completely recoded ISA.[34]

Privileged Instruction Set

The privileged instruction set specification of RISC-V is currently (November 2016) preliminary.[12]

RISC-V's ISA includes a separate privileged instruction set specification that explicitly supports three types of systems: Systems that have only "machine mode," perhaps for embedded systems, systems with both machine mode (for the operating system) and user-mode, and 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.[12]

The privileged instruction set specification explicitly defines "hardware threads," or "harts." Multiple hardware threads are a common practice in larger, more powerful 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 large 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. The only hardware thread required in a RISC-V computer is thread zero.[12]

The memory systems supported in the specification include physical-only, hardware address relocation using a single set of base-and-bound registers, hardware relocation for two separate sets of base and bound registers (This permits processes with different RAM to share code or permits a system to run code from read-only memory) and UNIX-style virtual memory systems with addresses sized 32, 39 and 48-bits, all with 4k pages.[12]

The existing control and status register definitions support RISC-V's error and memory exceptions, and a small number of interrupts. For larger systems, 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.[12]

Packed SIMD

For simple, cost-reduced RISC-V systems, there is a proposal to use the floating-point registers' bits to perform parallel SIMD sub-word arithmetic. This is widely used to accelerate multimedia and other digital signal processing.[3] This ISA is (as of 2016) undefined, but could resemble PA-RISC's multimedia instructions. Besides its native 64-bit math, the PA-RISC MAX2 CPU could do arithmetic on four 16-bit subwords at a time, 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. However, they increased the CPU's performance on digital signal processing tasks by 48-fold or more, enabling practical real-time video CODECs in 1995.[35][36]

Vector Set

The proposed vector processing instruction set may make the packed SIMD set obsolete. The designers hope to have enough flexibility so 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.[37]

The vector processing proposal is currently (29 June 2015) a conservative, flexible design of a general-purpose mixed-precision vector processor (suitable for executing compute kernels). Code would port easily to CPUs with differing vector lengths, ideally without recompiling.[37]

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 (in the case of x86, from 64-bit MMX registers to 128-bit SSE, to 256-bit AVX, and AVX-512). The result is not only a growing instruction set, but also 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 (setvl) 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. That is, each vector in up to 32 vectors is the same length.[37]

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 (vsetcfg) 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. (Added hardware limits may also exist, which in turn may permit SIMD-style implementations.)[37]

Outside of vector loops, the application can request zero vector registers, saving the operating system the work of preserving them on context switches.[37]

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.[37] The plan is that these can reduce the size and complexity of the ISA and compiler.[37]

Recent experimental vector processors with variable-width data paths also show profitable increases in operations per: second (speed), area (lower cost), and watt (longer battery life).[38]

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.[37][39]

External debug system

There is a preliminary specification for RISC-V's hardware-assisted debugger.[40] The debugger will use a transport system such as Joint Test Action Group (JTAG) or Universal Serial Bus (USB) to access the system bus to write small pieces of code to debug RAM. The CPU will process a debug interrupt in a small ROM to execute the small pieces of code. This 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 RISC-V is explicitly designed for many types of computers. Also, the hardware interfaces can be finalized early, permitting early development of the hardware, followed by software improvements to the debugger.

Some correspondents[41] have proposed a debug interface said to use fewer hardware resources. It maps all registers to memory addresses, and then the external hardware debugger accesses these via the memory bus. The designer responded with a cost-reduced version of the standard debugger that eliminates the debug ROM and most debug RAM.[42]

References

  1. "Contributors". riscv.org. Regents of the University of California. Retrieved 25 August 2014.
  2. 1 2 "Rocket Core Generator". RISC-V. Regents of the University of California. Retrieved 1 October 2014.
  3. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Waterman, Andrew; Lee, Yunsup; Patterson, David A.; Asanović, Krste. "The RISC-V Instruction Set Manual, Volume I: Base User-Level ISA version 2.1 (Technical Report EECS-2016-118)". University of California, Berkeley. Retrieved 22 July 2016.
  4. Celio, Christopher; Love, Eric. "ucb-bar/riscv-sodor". GitHub Inc. Regents of the University of California. Retrieved 12 February 2015.
  5. 1 2 "SHAKTI Processor Project". Indian Institute of Technology Madras. Retrieved 15 September 2014.
  6. Celio, Christopher. "CS 152 Laboratory Exercise 3" (PDF). UC Berkeley. Regents of the University of California. Retrieved 12 February 2015.
  7. Demerjian, C. (2013). "A long look at how ARM licenses chips: Part 1". SemiAccurate."How ARM licenses it's IP for production: Part 2".
  8. 1 2 3 4 Asanovic, Krste. "Instruction Sets Should be Free" (PDF). U.C. Berkeley Technical Reports. Regents of the University of California. Retrieved 15 November 2016.
  9. 1 2 Patterson, David A; Ditzel, David R. (October 1980). "The Case for the Reduced Instruction Set Computer". ACM SIGARCH Computer Architecture News. 8 (6): 25. Retrieved 25 August 2014.
  10. "Amber ARM-compatible core". OpenCores. OpenCores. Retrieved 26 August 2014.
  11. "ARM4U". OpenCores. OpenCores. Retrieved 26 August 2014.
  12. 1 2 3 4 5 6 7 8 9 Waterman, Andrew; Lee, Yunsup; Avizienas, Rimas; Patterson, David; Asanovic, Krste. "Draft Privileged ISA Specification 1.9". RISC-V. RISC-V Foundation. Retrieved 30 August 2016.
  13. RISC-V Foundation. "RISC-V The Free and Open Instruction Set". The RISC-V Foundation's Web Site. The RISC-V Foundation. Retrieved 11 November 2016.
  14. Celio, Christopher. "riscv-boom". GitHub. Regents of the University of California. Retrieved 11 November 2016.
  15. Asanovic, Krste; et al. (many contributors). "rocket-chip". GitHub. The RISC-V Foundation. Retrieved 11 November 2016.
  16. Celio, Christopher. "riscv-sodor". GitHub. Regents of the University of California. Retrieved 11 November 2016.
  17. "Chisel: Constructing Hardware in a Scala Embedded Language". UC Berkeley. Regents of the University of California. Retrieved 12 February 2015.
  18. "FreeBSD Wiki: RISC-V".
  19. 1 2 "FreeBSD Foundation: Initial FreeBSD RISC-V Architecture Port Committed".
  20. "Archtectures/RISC-V". Fedora WIKI. Red Hat. Retrieved 26 September 2016.
  21. Merritt, Rick. "Google, Oracle and HP Join RISC-V". EE Times. UBM. Retrieved 11 February 2016.
  22. https://riscv.org/membership/1424/rambus-cryptography-research/
  23. "IIT Madras Open Source Processor Project". Rapid IO. IIT Madras. Retrieved 13 September 2014.
  24. https://www.youtube.com/watch?v=gg1lISJfJI0
  25. Ashenden, Peter. "At ASTC (www.astc-design.com), we have an ... RV32EC ... core ... for small embedded applications.". Google Groups. Google. Retrieved 10 November 2016.
  26. Manners, David. "Codasip and UltraSoc Combine on RISC-V". Electronics Weekly. Metropolis International Group, Ltd. Retrieved 23 November 2016.
  27. SiFIVE. "Hi-FIVE1: Open-source Arduino-Compatible Development Kit". CROWDSUPPLY. crowdsupply.com. Retrieved 2 December 2016.
  28. Oloffsson, Andreas. "Why I will be using RISC-V in my next chip.". Adapteva Blog. Adapteva. Retrieved 11 February 2016.
  29. "lowRISC website". Retrieved 10 May 2015.
  30. Traber, Andreas; et al. "PULP:Parallel Ultra Low Power". ETH Zurich, University of Bologna. Retrieved 5 August 2016.
  31. 1 2 3 4 5 6 7 8 9 Waterman, Andrew (13 May 2011). Improving Energy Efficiency and Reducing Code Size with RISC-V Compressed. U.C. Berkeley: Regents of the University of California. p. 32. Retrieved 25 August 2014.
  32. "Coremark FAQ, "What factors are involved in improving a device?"". Coremark, an EEMBC Benchmark. EEMBC. Retrieved 1 October 2014.
  33. Waterman, Andrew, et. al. "The RISC-V Compressed Instruction Set Manual Version 1.9 (draft)" (PDF). RISC-V. Retrieved 18 July 2016.
  34. Brussee, Rogier. "Proposal: Xcondensed, [a] ... Compact ...16 bit standalone G-ISA". RISC-V ISA Mail Server. Google Groups. Retrieved 10 November 2016.
  35. Lee, Ruby; Huck, Jerry (February 25, 1996). "64-bit and Multimedia Extensions in the PA-RISC 2.0 Architecture". Proceedings of Compcon 96: 152–160. Retrieved 21 September 2014.
  36. Lee, Ruby B. (April 1995). "Accelerating Multimedia with Enhanced Microprocessors" (PDF). IEEE Micro. 15 (2): 22–32. Retrieved 21 September 2014.
  37. 1 2 3 4 5 6 7 8 Schmidt, Colin; Ou, Albert; Lee, Yunsup; Asanovic, Krste. "RISC-V Vector Extension Proposal" (PDF). RISC-V. Regents of the University of California. Retrieved 14 March 2016.
  38. Ou, Albert; Nguyen, Quan; Lee, Yunsup; Asanovic, Krste. "A Case for MVPs: Mixed-Precision Vector Processors" (PDF). UC Berkeley EECS. Regents of the University of California. Retrieved 14 March 2016.
  39. Lee, Yunsup; Grover, Vinod; Krashinsky, Ronny; Stephenson, Mark; Keckler, Stephen W.; Asanovic, Krste. "Exploring the Design Space of SPMD Divergence Management on Data-Parallel Architectures" (PDF). Berkeley's EECS Site. Regents of the University of California. Retrieved 14 March 2016.
  40. Newsome, Tim. "RISC-V External Debug" (PDF). RISC-V. The Regents of the University of California. Retrieved 11 February 2016.
  41. Herveille, Richard. "Lightweight Debug Unit Specifications". RISC-V Mailing Lists. RISC-V Foundation. Retrieved 2 December 2016.
  42. Newsome, Tim. "Lightweight *and* full featured". RISC-V Mailing Lists. RISC-V Foundation. Retrieved 2 December 2016.

Further reading

External links

This article is issued from Wikipedia - version of the 12/4/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.