• Base ISA Ratification
  • BitManip
    The BitManip work group will define extensions to the Unprivileged ISA that are comprised of bit-based instructions. These extensions are intended to enable the development of code that is substantially more performant and efficient that what is possible with the base instructions. Performance testing will be conducted by compiling or hand-assembling routines and then measuring performance improvement in a RISC-V modelling environment. Where possible, all or portions of standard benchmark tests will be employed in this testing. The new instructions will include operations from one or more of the following categories: bit counts, shift/rotate, insert/extract, set/clear, permute, and logical/mask. A base extension will include commonly used functions that are simpler to implement. An extended extension will be proposed should there be instructions that provide even more performance and power savings at a cost of more complexity.
  • Building on the RISC-V Foundation’s growing footprint in China across more than 25 organizations and universities, the China Advisory Committee will guide the RISC-V Foundation’s education and adoption strategies to further accelerate the RISC-V ecosystem in the region. Participation in this committee is open to foundation members who have significant China-based operations.
  • Compliance TG
  • Cryptographic Extensions Task Group
    The Cryptographic Extensions Task Group will propose ISA extensions to the vector extensions for the standardized and secure execution of popular cryptographic algorithms.
  • Debug
    The Debug Task Group's goal is the ratification of a specification for how to enable low-level hardware debugging on RISC-V implementations. In this section of the RISC-V Foundation Workspace you will find meeting minutes and slides, updated on a regular basis. Access to this area is restricted to members of the Debug Task Group.
  • Fast Interrupts TG
    The Fast Interrupts task group is focused on developing a low-latency, vectored, priority-based, preemptive interrupt scheme for interrupts directed to a single hart, compatible with the existing RISC-V standards.
  • Formal Spec
    This group will produce a Formal Specification for the RISC-V ISA. This is a specification of the ISA in a formal language, for precision, unambiguity, consistency and completeness. It should be readable and understandable as a canonical reference by practising CPU architects and compiler writers. It should executable and machine-manipulable for use in formal tools for establishing correctness and transformations in both compilers and CPU designs. [ This work is closely related to and complementary to the work of the Memory Model Task Group ]
  • J Extension Task Group
    The RISC-V J extension aims to make RISC-V an attractive target for languages that are traditionally interpreted or JIT compiled, or which require large runtime libraries or language-level virtual machines. Examples include (but are not limited to) C#, Go, Haskell, Java, JavaScript, OCaml, PHP, Python, R, Ruby, Scala or WebAssembly. Among other topics, the group expects to collaborate with several existing RISC-V extension working groups.
  • The RISC-V Marketing Committee is responsible for shaping RISC-V in the market place. Our goals are to increase awareness among developers, software & hardware engineers, architects, CTOs and others who influence technical decisions. We aim to accurately deliver the compelling story of RISC-V such that it becomes an admired brand and by extension this will create a halo over all RISC-V members who use it.
  • Marketing Content Task Group
    This vital collateral will ensure we drive awareness significantly higher such that RISC-V becomes a household name. The initial items to address are: RISC-V getting started guide RISC-V website content & newsletters All About Circuits RISC-V portal content
  • Memory Model
    The memory model task group charter is to define the memory consistency model for the RISC-V architecture, to produce relevant documentation and supplementary material (such as formal mathematical specifications and compliance test cases), and to work with the other task groups to ensure their own specifications remain compatible with the memory mode
  • Opcode Space Management
    The OpCode Space Management Task Group is a standing group with the task of allocating reserved opcode space for new proposed standard extensions. The group works with task groups developing new standard extensions to avoid conflicts with other current and planned future extensions.
  • Open Source and University Outreach
  • P Extension TG
    Define and ratify Packed-SIMD DSP extension instructions operating on XLEN-bit integer registers for embedded RISC-V processors. The TG will also define compiler intrinsic functions that can be directly used in high-level programming languages.
  • Privileged Spec
    The Privileged Architecture Task Group's charter is to define and facilitate the ratification of a Privileged Architecture Specification suitable for embedded systems and Unix-like operating systems.
  • Processor Trace Task Group
    The group shall standardize both a hardware interface to the RISCV core and a packet/data format which will enable the development of commercial and open source trace encoders to be supported by any tools vendors. The interfaces are to provide enough information for: Instruction Trace. The interfaces should be suitable for in-order and out-of-order cores with extensions. The group will standardize the data format for: Compressed branch trace so that program flow can be reconstructed by debugging tools. The group’s progress shall be evaluated after one year at which time the charter may be revised if necessary to narrow the scope of effort.
  • Program Committee
    The Program Committee for Workshops is responsible for guiding the content and supporting/advising on the organization of RISC-V Workshops.
  • Research Task Group
  • Security Standing Committee Main Goals: ● Promote RISC-V as an ideal vehicle for the security community ● Liaise with other internal RISC V committees and with external security committees ● Create an information repository on new attack trends, threats and countermeasures ● Identify top 10 open challenges in security for the RISC-V community to address ● Propose security committees (Marketing or Technical) to tackle specific security topics ● Recruit security talent to the RISC-V ecosystem (e.g., into committees) ● Develop consensus around best security practices for IoT devices and embedded systems
  • Summit Task Group
  • Sv128 Task Group
    Using minicomputers as a starting point, logical addresses from the early to late 70’s grew from 16 to 32 bits. The main driver was main memory dram technology increases. In the early 90’s, the logical address space increased to 64 bits. Again, the main driver was the main memory dram technology increases. Today, in addition to increases in main memory technologies, the creation of cluster and node multicomputer systems has resulted in a step function in memory capacities. This coupled with newer contemporary memory reference models such as PGAS and WEB based referencing models, as well as the introduction of non-volatile memory, results is the need to define SEMANTICS for data references. This contrasts with previous logical address expansion that extended the address space (flat addressing). Consequently SV128, should be capable of BOTH globally, directly referencing memory, independent of the underlying system architecture, as well as incorporating contemporary security models. Additionally, compatibility with existing RV32 and RV64 executable images need to be supported.
  • SW Tool Chain
    Welcome to the Software Task Group. The goal of this task group is to coordinate efforts to build the RISC-V software ecosystem and to standardize RISC-V software interfaces.
  • The Technical Committee is responsible for maintaining the RISC-V ISA. This includes maintenance of specifications, errata, future enhancements, and any technical activities necessary to promote or enable the technology. The charter of the committee is to promote a coherent, usable specification and make available either directly or indirectly a set of collateral materials to promote the use of the RISC-V ISA. RISC-V ISA Specification Ratification Process Any proposed release or revision of RISC-V ISA or related specifications shall follow the governance process detailed in the RISC-V Foundation Bylaws section 5.5 (shown below), 5.5 COMMITTEE REPORTS Committee Reports shall be made publicly available online via the RISC-V website ( for external comments and discussion for at least forty-five (45) days before the Board votes on the Committee Reports. The Committee Reports forwarded to the Board shall include a document with the Committee's response to issues raised by Committee members who voted against such Committee Report and by any dissenting public comments.
  • Trusted Execution Environment TG
    Deliverables RISC-V trusted execution architecture specification: The RISC-V trusted execution architecture specification will provide the necessary architecture extensions to build a secure RISC-V processor for trusted execution environment. RISC-V trusted execution implementation guidelines: Certain microarchitecture-level attacks, such as Spectre and Meltdown attacks, cannot be mitigated through architectural changes alone.The RISC-V trusted execution implementation guidelines will provide implementation guidance, tips and best practices aiming to help implementers mitigate attacks exploiting the microarchitecture, and improve the security of their hardware implementation RISC-V trusted execution software architecture specification: The RISC-V trusted execution software architecture specification will define architecture for common software components in RISC-V trusted execution environment, such as secure boot, secure monitor and secure API and/or secure system calls.
  • Vector Extensions
    The V Extension Task Group is tasked with developing the specification for the RISC-V base V vector extension, including written documentation, executable model, and compliance suite. The group is also responsible for outlining how future vector extensions can build on this baseline.