first_imgWith its blend of open-source freedoms with the benefits of standardization, the RISC-V ( risk-five ) Foundation is attracting widespread industry interest. Its core specifications are stable and on the cusp of ratification, soft- and hard CPU cores along with chips, development boards, and tools are commercially available, and major companies have started adopting RISC-V to replace their custom architectures. A key feature in the architecture’s appeal is that CPU developers can adapt RISC-V functionality to their needs without sacrificing the applicability of tools and libraries created for the base standard. The key to that adaptation lies in understanding RISC-V’s modular instruction set architecture.RISC-V started as the fifth iteration of reduced instruction set computing (RISC) design efforts at UC Berkeley, but quickly evolved from academic research to a movement seeking to redefine the electronics industry’s processing hardware design approach. Currently, system developers either must choose a proprietary CPU architecture, often optimized to a specific application space, or design their own CPU architecture. By pursuing their own design, however, developers give up the extensive support ecosystems that established CPUs have developed. There is a compromise: adapting a proprietary CPU architecture to gain customization while retaining much of the support ecosystem. This compromise, unfortunately, is impractical for many design teams due to high architecture licensing fees for proprietary architectures.The RISC-V initiative seeks to offer designers an alternative that permits customization and innovation while retaining many benefits of standardization. To do so, the RISC-V Foundation maintains and drives community development of the modular, open source, RISC-V processor instruction set architecture (ISA), which aims to meet application needs spanning embedded systems to server farms and beyond. The architecture’s specifications are free to download, and developers are free to implement designs based on the ISA without paying a license fee. Nor are they obligated to make their designs available to others, as with some open source initiatives. It is the ISA that is open source; individual designs, hardware architectures, and customizations can remain proprietary if developers wish.The initiative has gained considerable momentum. There are now RISC-V chips and cores available, both commercial and open source. Companies like SiFive, GreenWaves Technologies, and Microsemi have development boards for their RISC-V implementations. Development tools, software libraries, and operating system ports (including Linux) are all part of the current RISC-V support ecosystem. Leveraging all this support for a custom design, though, begins with a close look at the RISC-V ISA’s structure. Base specifications Two key documents define the RISC-V ISA: The User-level ISA Specification and the Privileged ISA Specification. Within these are the definitions of both base requirements and numerous standardized, modular extensions. The standard extensions are modular in that implementing any given standard extension in a CPU design will not interfere with the implementation of any other standard extensions. Some extensions may build on others, however, requiring that base extension be implemented as part of the desired extension.The overall design is register-based, calling for 31 general-purpose registers where all operations take place, with load-and-store access to the general memory space. Instruction sets have been defined for 32-bit, 64-bit, and 128-bit address spaces, with an additional, reduced-register-count, 32-bit instruction set defined to specifically target smaller gate count implementations for embedded system designs. Apart from the presence of additional instructions to manipulate longer word lengths, and register size matching the address space, the instruction coding for these variations is all the same. Figure 1 shows in schematic form how the core specifications and standard extensions interact. Many of the specifications are now frozen by the RISC-V Foundation, ensuring that implementations based on them will remain valid as the ISA evolves. This ensures that software written today will run on similar RISC-V cores forever. Some extensions are still in draft mode and so are subject to change. A few are reserved, i.e., placeholders awaiting future development. The 32- and 64-bit base integer ISAs are frozen, for instance, with the 128-bit and embedded variations still in draft form.The base integer ISA (I) is the foundation on which all else is built and must be present in any implementation. In addition to the base integer ISA, all standard RISC-V implementations must include at least the machine-level portion of the Privileged ISA; the supervisor-level (S) and hypervisor portions are standard extensions. However, the Privileged ISA is defined in such a way that developers can implement a custom form of privileged code execution without affecting the base integer ISA, should they wish. Figure 1 The RISC-V ISA forms a modular collection of instructions that can be implemented in a CPU design without interfering with one another. Enhancing base functionality with standard extensions The base integer (I) and machine-level privileged ISAs provide all the functionality a basic, general-purpose CPU requires. Developers can augment this base capability, though, by adding extensions to the ISA. Custom extensions are always possible, but there are standard extensions that the technical task groups in the RISC-V Foundation manage, having determined they have broad appeal to the design community and that their instructions do not conflict with other standard extensions. Developers are thus able to freely include any of the standard extensions they require in their design, without concern for conflicts in the instruction coding. These standard extensions include: N – Instructions that handle user-level interrupts (draft) F, D, and Q – Instructions for (F) single-, (D) double-, and (Q) quad-precision floating-point computations compliant with the IEEE 754-2008 arithmetic standard. Each precision’s extension depends on the lower-precision extension being present. (frozen) M – Instructions that multiply and divide values held in two integer registers (frozen) G – An implementation that includes the base integer specification (I) along with the M, A, F, and D standard extensions is so popular that the Foundation has defined the collection as G and has set the G configuration as the standard target of compiler toolchains under development. (frozen) V – Instructions to add vector instructions to the floating-point extensions (draft) L – Instructions for decimal floating-point calculations (reserved) B – Instructions for bit-level manipulation (reserved) Continue Reading Previous Rohde & Schwarz presents innovative T&M equipment for embedded systemsNext Solid Sands: SuperTest helping Graphcore accelerate the future of AI P – An extension to support packed single-instruction, multiple-data instructions (reserved) Share this:TwitterFacebookLinkedInMoreRedditTumblrPinterestWhatsAppSkypePocketTelegram C – Support for compressed instruction execution. The base integer (I) specification calls for instruction words to be 32-bits long and aligned on 32-bit boundaries in memory. Implementing the C standard extension provides 16-bit encodings of common operations and allows CPU designs to work with alignments on freely mixed 32- and 16-bit boundaries, resulting in a 25% to 30% reduction in code size. It can be implemented in any of the base integer bit widths and with any of the other standard extensions. (frozen) J – An extension to support use of dynamically translated languages (reserved) T – Instructions to support transactional memory operations (reserved) A – Instructions that atomically read-modify-write memory to support synchronization (frozen) Leave a Reply Cancel reply You must Register or Login to post a comment. This site uses Akismet to reduce spam. Learn how your comment data is processed. S – The privileged ISA’s supervisor-level extension (draft)last_img read more