A Survey of the RISC-V Architecture Software Support

RISC-V is a novel open instruction set architecture that supports multiple platforms while maintaining simplicity and reliability. Despite its novelty, the software support for RISC-V has been increasing in the last years, given that popular toolchains and operating systems already have support for RISC-V. However, although many works have been exploring the RISC-V software ecosystem, no work that raised the current state of software support for RISC-V is available. In this context, this survey reviews the contributions introduced in the last years to understand the RISC-V’s software ecosystem and its usage in both academic and industrial environments. We classified and evaluated the works into four main categories: application fields, RISC-V implementations, software architecture, and deployment features. The primary goal of this research is to provide the community with a comprehensive overview of the current state of RISC-V software support and identify and highlight the main contributions from recent work.


I. INTRODUCTION
With the increasing number of instructions of popular Instruction Set Architectures (Instruction Set Architecture (ISA)s) and the requirements of backward compatibility of older extensions, researchers from the University of California at Berkeley developed an open ISA based on Reduced Instruction Set Computer (RISC) principles. This architecture was named RISC-V [1] and seeks to provide a base ISA and optional application-specific extensions to support software engineers with a small and robust ISA [2]. In other words, it offers a stable ISA for compiler and operating system designers, enabling them to work with hardware architects to provide additional resources to meet application requirements and participate in the decisions and implementations of the RISC-V ISA specifications [2]. Nowadays, RISC-V is maintained by RISC-V International, a nonprofit organization [3].
RISC-V aims at becoming a universal ISA by supporting numerous processor sizes, from embedded controllers The associate editor coordinating the review of this manuscript and approving it for publication was Liang-Bi Chen . to high-performance computers, and a wide variety of software stacks and programming languages [2]. Moreover, given the future computing landscape, multiple platforms such as Internet-of-Things (IoT) devices and personal mobiles will likely dominate the market, requiring ISAs to support these systems [4].
Over the last decade, several studies have focused on the different issues related to the RISC-V architecture, and part of these contributions is summarized and analyzed in survey papers focused on security [5]- [8] and open-sourcing [9], [10] aspects. Although many studies have addressed the software stack for RISC-V, there is no report on the literature analyzing these studies from a unified perspective. Driven by the growth of the RISC-V ecosystem and the lack of studies concerning the current state of software for this ISA, this work seeks to fill this gap and explore the state-of-theart software support for RISC-V architectures. This survey analyzes works carried out in the last five years to understand the RISC-V's software ecosystem and its usage in academic and industrial environments. The main contributions of this research are: (i) providing the community with a comprehensive overview of the current state of the RISC-V software ecosystem, and (ii) identifying and highlighting the main contributions of recent work.
The remainder of this work is organized as follows. Section II summarizes the RISC-V ISA and Section III describes the methods applied to conduct this review. Next, Sections IV and V cover application fields and the RISC-V implementations, respectively. Finally, Sections VI and VII cover a set of software support characteristics and deployment features. Concluding, Section VIII presents the final remarks.

II. RISC-V
Unlike prior ISAs, RISC-V relies on a modular design by providing a frozen base ISA core (RV32I), along with extensions that provide additional functionalities. Moreover, it supports a full software stack, providing a stable target to compiler writers, operating system developers, and assembly language programmers [2]. A modular design enables optional standard extensions that the hardware can include if specified by the system's requirements, facilitating the development of small or large-scale applications and compilers to generate more reliable code. Besides, when RISC-V needs to include new instructions to the ISA, they are kept optional and nonrequired for all future RISC-V implementations, contrary to incremental ISAs [2].

A. THE BASE ISA
The RISC-V ISA provides four primary base integer (I) variants: RV32I (for 32-bit), RV32E (for 32-bit with 16 registers), RV64I (for 64-bit), and RV128I (for 128-bit). The base instruction sets provide the minimum requirements for running a processor and can run an operating system. It uses a two's-complement representation for signed integer values, and data is stored in memory using the little-endian system but allows non-standard alternatives to provide a big-endian memory system [1].
Besides the base ISAs, the RISC-V specification provides further functionalities through extension modules, such as M, for multiplication and division instructions; A, for atomic instructions; F, for floating-point instructions; D, for double-precision floating-point instructions; G, comprising the group of previously mentioned extensions; Q, for quadprecision floating-point instructions; L, for decimal floatingpoint instructions; C, for compressed instructions; B, for bit manipulation instructions; J, for dynamically translated languages support; T, for transactional memory support; P, for packed-Single Instruction Multiple Data (SIMD) (Single Instruction/Multiple Data) instructions; V, for vector operation instructions; N, for user-level interrupt support; H, for hypervisor support; and S, for supervisor-level instructions [3].

B. INSTRUCTION FORMAT
The RV32I base ISA has four instruction formats (R/I/S/U) and two variants (B/J) based on the handling of immediate operands. All of them have a fixed length of 32 bits and must be aligned on a four-byte boundary in memory [1]. Thus, the six instruction formats are: • R-type, for register-register instructions. • I-type, for register-immediate and load instructions. • S-type, for store instructions. • U-type, for instructions with a large upper immediate. • B-type, for conditional branch instructions. • J-type, for unconditional jump instructions. Given that the six instruction formats have regular encoding, the decoding of instructions is much more straightforward than ARM or x86 architectures. For example, RISC-V provides three register operands at the same position in all formats, simplifying the decoding process. In addition, the specified registers to be read or written are always in the same position in all instructions, enabling register access to start before the instruction decoding phase [1], [2].

C. PRIVILEGE LEVEL
The hardware must provide the Operating System (OS) mechanisms that enable the processor to change its execution privilege status, such as going from the user mode to the supervisor mode, and provide protection across different software components [11]. RISC-V supports three privilege levels of execution to protect different software stacks, enabling multiple software stacks to run with different privileges levels. Attempts to perform operations not permitted by the current privilege level will result in exceptions and require handling by an underlying execution environment. The highest and mandatory privilege level of the RISC-V hardware platform is the Machine-Mode (M-Mode), which is inherently trusted and has all low-level access to the system. Besides M-Mode, RISC-V supports Supervisor-Mode (S-Mode) intended for OS usage, and User-Mode (U-Mode) for conventional applications. In addition, each privilege level has a set of privileged ISA extensions with support for optional extensions. This extension enables, for instance, having the S-Mode extended to support a hypervisor execution environment [12].

D. REGISTERS
RISC-V has 32 registers (x0-x31), whose names are determined by the RISC-V's Application Binary Interface (ABI). Register zero is hardwired and always holds the value zero, mainly to simplify the ISA. The ra and sp registers hold the return address and stack pointer, respectively. Registers t0-t6 hold temporary values that are not guaranteed to persist after a function call, and s0-s11 hold persistent values across function calls. Finally, registers a0-a1 hold the first two arguments of a function and return value, and a2-a7 hold any remaining arguments [2].

E. CONTROL AND STATUS REGISTER
The Control and Status Registers (CSRs) are system registers to control and monitor the machine's current state. VOLUME 10, 2022 CSRs can be read or written through specific Control and Status Register (CSR) instructions, and have restrictions for low-privilege levels. A RISC-V implementation may contain additional CSRs, accessible to a subset of the privilege levels. Any attempt to either access a CSR without the appropriate privilege level or to write into a read-only CSR raises an illegal instruction exception [12].

F. EXCEPTIONS AND INTERRUPTS
Both exceptions and interrupts on RISC-V processors are considered traps. As exceptions and interrupts happen during runtime, the processor provides mechanisms to make an unscheduled procedure call to an arbitrary address [11]. RISC-V classifies traps into two main categories: synchronous and asynchronous. Synchronous traps are exceptions resulting from an instruction execution, such as accessing an invalid memory address or executing an invalid instruction. Asynchronous traps are interrupts and are external events that occur asynchronously to the instruction stream. RISC-V sets the most significant bit of the mcause control status registers to identify whether the trap is synchronous or asynchronous, and the least significant bits for identifying which interrupt or exception occurred [2].
RISC-V has three sources of interrupt: software, timer, and external interrupts. Software interrupts enable programmers to interrupt a given Central Process Unit (CPU), allowing efficient Inter-Process Communication, while timer interrupt is triggered when a hart (i.e., hardware thread) time comparator exceeds or equals the global timebase register. External interrupts, in turn, are asserted by a platform-level interrupt controller [12]. The mechanisms for raising and clearing interrupts can vary according to the hardware platform, given that they can use different memory maps and demand divergent features from their interrupt controller [2]. However, all RISC-V systems handle exceptions and mask interrupts in the same way.

G. ADOPTION AND MOTIVATION
RISC-V International is a nonprofit organization and counts with more than 40 sponsoring companies [3]. For the past decade, NVIDIA has been shipping their Graphics Processing Units (GPUs) with proprietary microcontrollers called Falcon, but since 2016, NVIDIA is evaluating RISC-V for their GPUs [14]. Western Digital open-sourced the SweRV Core, an industry-qualified processor featuring a 32-bit inorder, 2-way superscalar design with a 9-stage pipeline core [15]. In 2019, Alibaba revealed its first embedded high-performance 64-bit RV64GCV RISC-V-based processor, which includes a set of custom extensions [16], [17].
Due to the recent US restrictions on its ARM design, Huawei HiSilicon released their first RISC-V-based board together with the Harmony OS in May 2021 [18]. With LEON SPARCv8 being the dominant architecture in European avionics and facing difficulties in leveraging software from the commercial domain, the Dependable Real-time Infrastructure for Safety-critical Computer (De-RISC) project introduces the RISC-V architecture for aviation and space environments by using fault-tolerant techniques and supporting compute-intensive applications [19]. Further, apart from Apple's recent switch to ARM-based System-On-Chip (SoC), it has recently demonstrated an interest in exploring the RISC-V architecture [20].
Apart from industrial motivation and adoption, academic development is also in progress. For example, the PULPino processor from the Swiss Federal Institute of Technology (ETH Zurich) is ready for industrial standards. PULPino is optimized for low-power consumption, concentrating on providing IoT solutions [21], [22]. Given this background, the institution of technology Semico Research Corp. estimates that, in 2025, the market will have around 62.4 billion RISC-V cores worldwide [13], [23], represented in Figure 1.

III. MATERIALS AND METHODS
In order to carry out this survey and identify the current state of the RISC-V software support, we conducted a bibliographic survey using the following materials and methods. First, we performed a search on the IEEE, ACM, Springer, and Usenix digital libraries using the query: ("RISC-V" AND ("Software" OR "Operating System" OR "OS")). We limited the search to retrieve works published in the last five years. Furthermore, we applied the impact of the publication channel and the normalized number of citations received by each work to select the ones to be analyzed.
After the search and selection phase, we categorized the RISC-V software ecosystem as shown in Figure 2. From top to bottom, we first explore the variety of environments RISC-V is applied and then continue to explore available implementations that have been proposed. We then further explore the different software architectures that have been ported or implemented on RISC-V and the deployment characteristics, such as security, reliability, and power features. This work will further explore these categories in the following sections: application fields (Section IV); RISC-V implementations (Section V); and software support, including software architecture, OS support, file systems, network stack, and uncategorized features (Section VI). In addition, we analyzed the additional features, including the support for security, reliability, and low-power operation (Section VII).

IV. APPLICATION FIELDS
The space industry has had difficulties leveraging software from the commercial domain and is now considering alternative architectures in a larger commercial market [19]. Furthermore, with the introduction of SoC and multi-core processors, this industry now seeks to migrate components to a higher level of integration, introducing a new set of issues that needs to be solved. A modular architecture, such as RISC-V, enables designers to extend the processor and implement functionalities tailored to their application requirements, making RISC-V highly adaptable to various environments.
The De-RISC project introduces a novel RISC-V hardware/software platform meeting the requirements and  functionalities imposed by the space environment. De-RISC meets reliability by designing its Multiprocessor System-on-Chip (MPSoC) with fault-tolerance techniques to provide a correct operation in the presence of faults [24].
The SELENE project, depicted in Figure 3, proposes a reliable platform for safety-critical computing. It is built on opensource technology and enables designers to adapt the system to a specific requirement domain, integrating applications of different criticalities and demands, achieving a diverse set of redundancy and performance [25]. Furthermore, the openness of RISC-V improves component reuse and prevents the need for developing projects from scratch, increasing productivity and reducing cost [26].
With the increase of embedded device deployments and the expected growth of the Industrial Internet-of-Things (IIoT) market to reach 1.11 trillion US dollars by 2028 [27], [28], IoT devices have become a fundamental part of the lives of billions of people around the world. Securing these devices without loss of performance or increasing power usage has become a matter of discussion with the accelerating growth of connected devices. In this regard, the RISC-V community has investigated several security issues for constrained devices. Solutions addressing high-level goals identified by NIST IR 8228 [29], authenticated secure-boot images while verifying updates during runtime [30], hardware enforcement and memory isolation mechanisms [31], and post-quantum solutions [32] are all available for the RISC-V architecture.
Apart from security and reliable applications, RISC-V has a set of research fields concerning AI-based applications. In [33], the authors seek to provide a heterogeneous processor design for Convolutional Neural Network (CNN)-based applications by proposing a domain-specific architecture design and an accelerator for the inference of CNNs, adhering to low-power characteristics. The SiFive Intelligence X280 is a multi-core RISC-V compliant processor that optimizes Artificial Intelligence and Machine Learning (AI/ML) inferencing computing. X280 uses the vector extension and SiFive Intelligence extensions, making the core suitable for high-throughput single-threaded and power-constrained applications [34]. Finally, the work [35] uses a RISC-V-based architecture to provide a platform for Robot Operating System (ROS)-based applications.
The RISC-V architecture is also being applied in approximate computing solutions. The work [37] proposes a methodology to help designers to select the most optimized Floating-Point Unit (FPU) configuration that meets a given threshold for an specific application. Similarly, the work [38] presents an automated quality-driven methodology that combines different approximate computing techniques to explore and apply error-tolerant sections to applications.
RISC-V is highly adaptable for various contexts, given the open specification, modularity, and the community. It enables designers to deploy from small, low-cost embedded devices to a large-scale system with custom extension support meeting the requirements imposed by the system.

V. RISC-V IMPLEMENTATIONS
Despite the requirements of a general-purpose processor, RISC-V enables domain-specific implementations to exist, either by implementing the RISC-V base ISA with custom characteristics or implementing a new extension.

A. PROCESSOR CORES
The PULPino project provides three RISC-V core implementations: (i) a 32-bit 2-stage pipeline named Ibex (formerly named Zero-riscy), (ii) a 4-stage pipeline core named CV32E40P (formerly named RI5CY), and (iii) a 64-bit 6-stage core named CVA6 (formerly named Ariane). Ibex, maintained by lowRISC and illustrated in Figure 4, is well suited for embedded control applications and supports the Integer (I) or Embedded (E), Integer Multiplication and Division (M), Compressed (C), and Bit Manipulation (B) extensions, and is available as a SystemVerilog project [36], [40]. The CV32E40P core, depicted in Figure 5, implements the RV32IMFC ISA and the Xpulp extension for higher code density, performance, and energy efficiency characteristics [36], [41]. Finally, the CVA6 core, illustrated in Figure 6, implements the RV64IMAC ISA, focuses on reducing the critical path, and supports a configurable size and separate Translation Lookaside Buffer (TLB) [39].
SonicBOOM ( Figure 7) is a Register-Transfer Level (RTL) implementation of an RV64GC superscalar out-of-order core written in Chisel3. SonicBOOM improves the architectural characteristics of BOOMv2 and seeks to provide a stateof-the-art platform for high-performance research. The Son-icBOOM core optimizes the execution path and redesigns the instruction fetch unit with a hardware Tagged Geometric (TAGE) branch predictor algorithm. Further, SonicBOOM's load-store unit provides multiple loads per clock cycle and achieves 6.2 CoreMark/MHz [42], [43].
NOEL-V is a synthesizable VHSIC Hardware Description Language (VHDL) processor with support to the 32-and 64-bit RV{IM,IMAC,GCH} ISA, with single-or dual-issue features. The core is available as part of a subsystem that includes system peripherals and is configurable to use RISC-V extensions. The NOEL-V dual-issue processor allows two instructions per clock cycle and implements advanced branch prediction capabilities [19], [44].
In [33], the authors proposed a CPU based on the lowpower 2-stage pipeline Hummingbird E200 RISC-V core, which implements the RV32IMAC ISA.
The authors of [46] presented the HARV processor, with support to the RV32I ISA and focus on reliability. This processor core employs fault tolerance techniques in its internal structures, i.e., error-correcting code in all registers and Triple Modular Redundancy (TMR) in the controller and the Arithmetic Logic Unit (ALU), to provide reliability.
In June 2021, SiFive announced the P270 and the P550 cores to their Performance family. P270 is an 8-stage, dual-issue, efficient in-order pipeline core compatible with RV64GCV ISA. P550 features 13-stage, tripleissue, out-of-order pipeline core implementing the RV64GC ISA and delivering a SPECInt 2006 score of 8.65/GHz, the highest performance RISC-V processor available to date [47]- [49].

B. SOC PLATFORMS
The PULPino project provides a set of complete system platforms: (i) PULPino ( Figure 8) and PULPissimo (Figure 9),   two platforms based on a single-core microcontroller, (ii) OpenPULP ( Figure 10), a multi-core IoT processor, and (iii) Hero ( Figure 11), a multi-cluster heterogenous accelerator, which combines a parallel many-core accelerator VOLUME 10, 2022  on an Field-Programmable Gate Array (FPGA) with a hard ARM Cortex-A multi-core host processor.
The FE310-G000 SoC by SiFive, illustrated in Figure 12, has an E31 core with a single-issue in-order pipeline and implements the RV32IMAC ISA. The E31 core peaks a sustainable execution rate of one instruction per clock cycle. The FE-3100-G000 features two Universal Asynchronous Receiver-Transmitter (UART) devices for serial communication, three Quad Serial Peripheral Interfaces (QSPIs), three Pulse-Width Modulation (PWM) ports, and support to lowpower operations [50]. The HiFive1 is one of the first commercial available RISC-V boards, which features the FE310-G000 SoC. The work [51] proposes a set of novel approaches that enhance Virtual Prototype (VP) design flow using the HiFive1. Similarly, the work [38] proposes an automated quality-driven methodology which supports the HiFive1.
The PolarFire SoC FPGA by Microchip is a low-power, thermal efficient, and defense-grade security device for intelligent, connected systems. The SoC has a 5-stage singleissue in-order pipeline RISC-V and does not suffer from Meltdown and Spectre exploits of common architectures. PolarFire cores are deterministic and coherent with the memory subsystem, enabling Linux and real-time capable applications to execute. The SoC implements the RV64GC and RV64IMAC ISAs [54].
The work [30] uses a Universal Sensor Platform (USeP) SoC to meet IoT requirements, which features a RISC-V processor and integrates peripherals with a scalable subsystem as a Three Dimensional System-in-Package (3D-SiP).
The Sipeed MAix-GO development board, employed by [55], features a Kendryte K210 SoC, with a dual-core RV64GC processor, including support to a single and doubleprecision FPU.

C. EMULATORS AND SIMULATORS
The open-source QEMU project is a generic machine emulator and virtualizer, providing a virtual model of an entire machine to run a guest OS. QEMU supports 32-and 64-bit RISC-V implementation and several different   machines, including Microchip's PolarFire SoC, SiFive's HiFive Unleashed, and Shakti C platform [56].
Gem5 is an open-source modular simulator for computer architecture research, including system-level architecture and processor microarchitecture. Gem5 support to RISC-V privileged ISA specification is still in development [57].
Spike is a RISC-V ISA simulator with a functional model of one or more RISC-V hardware threads. It supports a large set of RISC-V extensions and eases simulating new instructions by letting the user describe the functional behavior and add the opcode and opcode masks [58].
RISC-V Assembler and Runtime Simulator (RARS) is built on top of MIPS Assembler and Runtime Simulator (MARS) and extends the software to enable features such as instructions hot-load of RISC-V extensions [59]. Similarly, WebRISC-V [60] provides a web-based server-side simulation of a 5-stage pipeline RISC-V implementation. The application enables writing simple assembly programs and visualizing data in registers, memory, and the internal state of the pipeline. Ripes is an open-source visual computer architecture simulator built around the RISC-V ISA [61], providing multiple microarchitectural models to explore a typical VOLUME 10, 2022 pipeline processor. Similar simulators include Jupiter [62] with support to RV32IMF ISA, Vulcan [63] with support to RV32IMAF ISA, and the emulsiV simulator [64], intended for teaching basics of computer architecture.

D. DISCUSSION
This section reviewed different RISC-V implementations to comprehend the RISC-V ecosystem and the available research towards the open ISA. Given RISC-V's open specification, multiple implementations tackle specific problems for a given application field, making RISC-V highly adaptable. Besides the presented RISC-V cores and SoCs, there are others not mentioned in this work that has shown to be production-ready, supporting low to high-performance computing requirements.

VI. SOFTWARE SUPPORT
The ISA interface encompasses the machine language instructions that a computer can run, acting as a boundary between the hardware and software layer [65], represented in Figure 13. In RISC-V's privilege layer, both the user application and the OS can access the ISA directly, as RISC-V provides a subset of instruction repertoire per layer.
The ABI defines a standard for binary portability across programs by defining the system call interfaces to the OS, and hardware resources available in the system through the ISA [65]. This allows binaries compiled to a specific ABI to run without modifications in a different system with the same ISA and OS.
The following subsections seek to evaluate and review works that address different types of software architecture to understand the scope of end-user application and OS support.

A. SOFTWARE ARCHITECTURE
The software architecture relates to its structure, how these components are separated, and their interrelationships. Software engineers seek to structure software to meet current and future demands, making the system reliable, manageable, adaptable, cost-effective, and scalable [67].

1) BARE-METAL APPLICATIONS
Applications running on bare-metal systems have direct access to the processor and peripherals. These applications are not managed by an OS layer, enabling applications that require runtime guarantees along with constraint hardware to function as expected.
The work [66] extends their previous work on COAST [68], which explores Commercial Off-the-Shelf (COTS) systems to provide an automated compiler modification, bringing support to several new processing platforms, such as

RISC-V and Xilinx
SoC-based products. The compiler inserts dual-or triple-modular redundancy during the compilation phase, enabling the software to correct errors during runtime. The proposal is attractive for applications requiring tolerance against Single Event Effect (SEE) and is well-suited for processing in a high radiation environment. Although the tool provides both Duplicate With Compare (DWC) and TMR mechanisms, the default configuration uses Variables 3 (VAR3) protection mechanism. Figure 14 illustrates the COAST architecture.
Stahl et al. [69] propose a driver development flow to ease the definition of hardware/software interfaces without a fixed register layout and reduce the development effort and memory usage of an Microcontroller Unit (MCU). The proposal uses a Domain-Specific Language (DSL) to describe the behavior using features such as bit field arrays and hierarchy. In addition, the work proposes a heuristic, code analysis, and generation technique to find an optimized register layout that exploits its performance and memory footprint. The proposal uses PULPino General-Purpose Input/Output (GPIO) and Serial Peripheral Interface (SPI) drivers and has reduced the estimated run time by 52%, 32% reduction of memory accesses, while the driver code size is reduced by 22%.

2) OPERATING SYSTEMS
Zhang et al. [70] propose an automatic kernel code synthesis and verification technique framework, which seeks to build a verifiable OS kernel with a high degree of proof automation. The proposed framework enables a software developer to write the required specification of the kernel and translates the corresponding specification into C code. The authors provided a kernel named iv6, which combines exokernel architectural aspects with characteristics of a mathematically proven and trustworthy microkernel. The kernel initializes in RISC-V's M-Mode, runs in a separate address space from userspace, and uses identity mapping techniques for the kernel along with additional characteristics.
In addition to the OS architecture, the work [71] explores the building blocks of the development cycle of an opensource OS for the 64-bit little-endian RISC-V architecture, proposing a custom Linux distribution from Linux From Scratch (LFS) with independent userspace and a package manager written in Lua programming language. The proposal seeks to provide a Linux-based distribution for open-source hardware and is the first OS targetting RISC-V.
Implementations of a RISC-V architecture with hardware/software co-design are also available, such as the work proposed by [72], which captures possible applicationkernel interaction as a Finite-State Machine (FSM) and integrates the Real-Time Operating System (RTOS) semantics directly into the processor pipeline. The proposal significantly improves event latencies, interrupt lock times, and memory footprint at a moderate cost of FPGA resources.
Malenko and Baunach [73] employ a microkernel-based operating system named SmartOS, which seeks to provide basic functionality in privilege-mode while other functionalities run in user-mode. Further, to evaluate the reliability of a RISC-V-based SoC, the work [74] compares five algorithms against a Linux-based OS and a bare-metal implementation by using a lowRISC implementation on a Xilinx FPGA.
The work [75] aims at providing a basic microkernel for the RV32I ISA. The microkernel has support to trap handling and multiple RISC-V privilege modes. The work is focused on enabling students and lecturers to enrich further their comprehension of computer architecture and OS development.

3) DEVELOPMENT TOOLS
The work [76], illustrated in Figure 15, proposes a design method to generate domain-specific many-core architectures with provided frameworks and automated steps using software tools. The solution facilitates engineering and creates many-core architectures with different configurations, including core augmentation through instruction extensions and custom accelerators.
Torres-Sanchez et al. [55] evaluate the development environment toolchains and debugging process concerning the Sipeed MAix-GO development board and Tiny YOLO v2 support by deploying a low-power IoT edge application, achieving reasonable cost and performance characteristics.
Herdt and Drechsler's proposal [51] provides an automated formal verification tailored for SystemC-based virtual prototype on top of a RISC-V ISA and significantly improves verification quality, reducing overall verification effort.
Furthermore, the work [77] provides a library to run lightweight and energy-efficient neural networks. The framework automates deployments on MCUs with and without an FPU. Finally, the work [78] proposal enables ISA designers to iteratively refine and evaluate ISA specifications, allowing the improvement upon each result.

B. OPERATING SYSTEM ARCHITECTURE
With the growing complexity of computer hardware, the operating system provides an abstraction layer to the user, acting as an interface between applications and computer hardware, enabling programmers to develop software without knowing much of the underlying details and executing software efficiently. The ISA defines the OS capabilities, as it defines the available instructions to the application. RISC-V has a defined subset of OS support as well as user and machine instructions [65], [79].

1) MEMORY MODEL
The work [76] uses scratchpad memory to avoid having to deal with cache coherence issues. Further, all cores and components in the architecture share the same address space. The memory module routes memory accesses to the data cache or another component through a crossbar network.
The SmartOS employed by [73] organizes the memory with the linker script to structure the Task Control Blocks (TCB), Resource Control Blocks (RCB), and Event Control Blocks (ECB) arrangements and the regions for task stack, data, and entry function.
The cache controller of NOEL-V supports a store buffer First In, First Out (FIFO) with one cycle per store and a wide Advanced High-performance Bus (AHB) data width support to enable start stores and fast cache refill [19].
Trippel et al. [78] propose a memory verification model to check for bugs on hardware and software memory models by providing a tool capable of verifying High-Level Language (HLL), compilers, and ISAs. Further, the authors present potential inefficiencies of the RISC-V ISA specification and identify possible solutions to mitigate these inefficiencies.

2) SCHEDULER SUPPORT
A processor scheduler assigns processes to be executed by the processor at a given time, meeting system response time, throughput, and processor efficiency objectives and allowing multiple processes to exist concurrently in a multiprogramming system. Furthermore, schedulers can also have real-time features, which guarantee that high-priority tasks execute within a specific time constraint.
The work [81] implements an improved version of a deterministic coprocessor task scheduler based on the Earliest-Deadline First (EDF) algorithm. In addition, the work adds support for CPUs to run two or four real-time tasks in parallel, improving real-time system performance and reducing resource costs using the Heap Queue sorting architecture for the Ready Queue implementation. The improved coprocessor and the task scheduler were described in SystemVerilog and verified by simulations and a simpler version of the Universal Verification Methodology (UVM).
Naylor et al. [82] explore the potential of a distributed soft-processor overlay to deliver appropriate performance for FPGA clusters. In addition, the work uses an FPGA-optimized hyperthreaded RISC-V soft-core, named Tinsel, and implements a barrel-scheduled multithreaded core that uses a large subset of the RV32IMF ISA. Tinsel tolerates inherent latencies of a floating-point operation and off-chip memory access. Further, it provides a programming environment through an interface on top of the Tinsel Application Programming Interface (API), abstracting architectural details and handling graph mapping onto the overlay.
Tasks in SmartOS, employed by [73], are preemptive with unique static priorities defined at compile-time, and active priorities dynamically modified by the resource manager and used by the scheduler. Further, SmartOS's kernel uses a TCB structure for managing tasks.

3) INTER-PROCESS COMMUNICATION
Processes may need to communicate with one another, requiring the OS to provide a communication mechanism, preventing race conditions and ensuring the proper sequence of communications. The communication should be well-structured and preferably without using interrupts. The communication the OS provides is known as inter-process communication [65], [79].
Du et al. [80] use the SiFive U500 SoC with the RV64IMAFD ISA to add support for a secure and efficient cross-process call architecture. The proposed architecture is illustrated in Figure 16. The work proposes a hardware-assisted OS primitive named XPC, which uses an asynchronous Inter-Process Communication (IPC) across different address spaces and enables a direct switch between IPC caller and callee without trapping into the kernel. XPC improves throughput using a new address-space mapping mechanism and provides a multithreading API with the migration thread model. The work supports split thread state, per-invocation C-Stack, and Android's Ashmem subsystem. The authors assessed performance, achieving a 0.3ms latency for 4KB data, with a 1.6x improvement, mainly from the secure zero-copying message transfer. XPC is compatible with traditional address-space isolation and can easily integrate with existing OS kernels.
The work [83] proposes in-process isolation based on dynamic memory protection domains. Software components can rely on enforced security by using a set of provided protection keys and associate memory, supporting usage rights and entry points.

4) ADDITIONAL FEATURES
The Sipeed MAix-I development board employed by [55] features a highly integrated Espressif ESP8285 SoC with complete self-contained Wi-Fi networking capabilities.  Du et al. [80] use lwIP, a small independent implementation of the TCP/IP protocol suite, as a network stack server for the microkernel and a loopback device driver to pack and send to the network device server.
Liu et al. [84] propose a secure runtime system named SeRot, illustrated in Figure 17, which addresses primitives to support unmodified applications. SeRot uses the Linux Kernel Library (LKL) network stack to provide network functionalities to the application. It also enables applications to access a file system by using LKL for accessing and managing file system calls.

C. DISCUSSION
Even with little time in the market, RISC-V's software ecosystem includes compilers, state-of-the-art OSs, and system generation tools to ease hardware/software interfacing. In addition, the open specification of RISC-V has made it possible for one to support and implement robust software architectures to meet a range of requirements.
With the increasing demand for computing power, the simplicity of the RISC-V ISA enables OS engineers to support the architecture and contribute to its specification. On the other hand, the growing complexity of architectures such as x86 makes it difficult for developers to keep up and contribute to the development of the ISA.
RISC-V's openness has led to a wide range of RISC-V applications, including academic and industrial usage, helping researchers to explore the benefits of an open ISA for software development. Overall, the works presented have shown how RISC-V can support software and operating systems with sophisticated memory models, inter-process communication, compiler techniques, and toolchains.

VII. DEPLOYMENT FEATURES
To further investigate the RISC-V software ecosystem, this section reviews the works that tackle security, reliability, and power management characteristics of RISC-V in order to improve the executing software.

A. SECURITY
Hunt et al. [86] argue that hardware enforcement isolation mechanisms have historically been the basis for a secure system. However, providing redundant protection for isolation by combining software and hardware techniques can improve system security. Zhang et al. [70] implement a Kernel Page- Table Isolation (KPTI) with a channel for accessing userspace from the kernel space by a block of a shared memory region. Further, the framework reduces the impact of human error during the development phase. Similarly, the work [73] explore memory isolation techniques and implement a hardware/software co-design approach for memory isolation by providing two hardware components: Device Driver Isolation Module (DDIM) and System Call Tracing Module (SCTM).
Hwang et al. [87] provide a kernel hardware-based monitoring platform and a hardware interface architecture to overcome the semantic gap problem in a RISC-V core. The work introduces a platform called RiskiM to ensure kernel integrity, and an interface architecture named Program Execution Monitor Interface (PEMI). In order to overcome the semantic gap issue, PEMI provides all internal states of the host system to RiskiM to fulfill its monitoring task and protect the kernel in the presence of attacks. Furthermore, Sisejkovic et al. [88] implement a hardware/software solution using the 64-bit 6-stage in-order, single-issue Ariane core. The work proposes a hardware design protection against hardware Trojans inserted during the production phase through netlist obfuscation provided by logic locking.
In [89], Fischer et al. exploit hardware misconfigured access control of the Read-Only Memory (ROM) as well as incorrect implementations of SoC firmware. The work explores memory overwrites of peripheral regions and has found no code that implements the Counter (CTR) block cipher mode.
Auer et al. [30] address three high-level goals, identified by the NISTIR 8228 report, to provide a secure architecture on IoT devices. The work uses a secure-boot mechanism with a certificate chain to authenticate boot images, and the update verification happens during runtime. Furthermore, in order to explore and present a compatible RISC-V with Trusted Execution Environment (TEE) featuring security algorithm accelerators, the work [90] uses a 64-bit RISC-V with the IMAFDC ISA implementation, along with a Rocket chip generator as a hardware platform. The work features SHA-3 and Ed25519 accelerators and provides a procedure for the software to authenticate a Linux bootloader.
Similarly, Siddiqi et al. [91] use a lowRISC FPGA implementation to propose a hardware/software-based solution to secure system integrity. In addition, the work provides a solution for securing the processor by implementing a self-authenticated secure boot and provide Information Flow Tracking (IFT) to detect and stop memory corruption attacks.
Dessouky et al. [92] provide a testbed of real-world software-exploitable RTL bugs based on RISC-V SoCs, exploring TLB, cache, and memory attacks to identify specific vulnerabilities classes. To further explore microarchitectural security, the authors conducts two case studies on the Ariane and PULPissimo SoC. Furthermore, to encourage SoC security research, Fischer et al. [89] employs the Ariane SoC RTL to investigate hardware vulnerabilities in SoC designs.
With difficulty in ensuring the trustworthiness of the fabrication process of silicon devices, Bolat et al. [85] propose an architectural protection mechanism, shown in Figure 18. The mechanism detects hardware Trojans infesting the instruction and data memories of the system by shielding the communication of the processor and memory.
The work [93] investigates undocumented instructions on RISC-V and ARM ISAs and propose two methods to look for undocumented instructions. Both methods execute a single instruction in a controlled manner, allowing the processor to determine if the instruction is valid by comparing the results to the ISA specification.
Fell et al. [94] explore side-channel attacks and investigate the impact of source-code obfuscation techniques to verify what information leakage is exploitable. The work proposes a compiler-based technique to mitigate leakage by employing an extension to the LLVM compiler.
Nyman et al. [95] extend the RISC-V ISA with seven new Storage Region Stack (SRS) management instructions to provide context-specific enforcement. The authors modify the instruction decode stage of the processor pipeline to interpret the new instructions. Similarly, the work [91] modifies the execute stage of the processor pipeline to add support to tag propagation and tag check features.
Finally, the work [95] proposes a Runtime Scope Enforcement (RSE) approach to mitigate all known Data-Oriented Programming (DOP) attacks efficiently on memory-unsafe programming languages. The proposed technique enforces memory safety constraints during compile-time, resulting in a low-performance overhead.

B. RELIABILITY
Fault injections can be applied to measure coverage and latency parameters, explore error propagation, and analyze the system workload and fault handling capabilities. In addition, different fault injection models can be utilized to exploit reliability characteristics of given hardware [96], requiring countermeasures to avoid and protect such exploits.
Laurent et al. [97] examine fault injection at the microarchitectural layer and propose a cross-layer approach. The authors inject single-bit faults in the experiments to simulate faulty behaviors in a lowRISC processor. The simulation results show behaviors of forwarding capabilities, speculative execution, and writing in a General-Purpose Register (GPR) during branch instruction. The authors also review software fault models and provide alternatives to bypass the countermeasures set by data-and control-flow integrity.
In [98], the authors inject faults on a 64-bit, 5-stage pipeline, lowRISC processor to highlight the importance of hidden registers in the processor pipeline. They provide countermeasures against hidden registers attacks by exploring the multiplier unit and forwarding characteristics, which are invisible from the software point of view and entirely dependent on the processor implementation. In the context of coverage analysis and fault simulation, the work [99] introduces a metric for RISC-V instructions and registers coverage. The work analyzes and compares three available RISC-V test suites and combines them into a unified tool.
The work [100] seeks to provide an efficient solution for fault effect analysis and simulation by introducing a virtual prototype-based approach. Bit flips are performed into the fetched/executed instructions, the GPRs and CSRs of a RISC-V processor and simulated to analyze the impact during software execution. In contrast, the work [74] found VOLUME 10, 2022 that Single Event Upsets (SEUs) barely affect the number of silent data corruption in the presence of an OS. Similarly, the work [101] evaluates the reliability of running software applications against SEUs that affect the configuration and processor memories. The work compares the utilization of hardened-by-replication software with the baseline version in a set of benchmarks.

C. LOW-POWER
The IoT is one of the fastest-growing approaches among embedded systems. Devices used in IoT need to meet communication and energy efficiency requirements. In this context, Liu et al. [33] propose a domain-specific architecture design for Convolutional Neural Network-based IoT applications, with a heterogeneous processor design and accelerator for the inference of CNNs.
The methodology proposed in [38] seeks to minimize energy consumption and meets the defined threshold for a given application-level metric. Furthermore, the toolkit proposed in [77] takes multi-layer perceptrons trained with Fast Artificial Neural Network (FANN) to generate code for energy-efficient neural networks on microcontrollers.
Imianosky et al. [102] evaluate CCSDS 123 Compressor performance and power consumption on RISC-V and ARM architectures by executing the algorithms in FreeRTOS and Zephyr OSs. The authors concluded that RISC-V uses less power when compared to the ARM processor, while ARM offers higher performance. The work also showed that FreeRTOS has a lower overhead to the algorithm execution than Zephyr when executed on a RISC-V processor.
The SoC adopted by [30] has low-power characteristics, enabling designers to perform power-tradeoffs at runtime by adjusting the back-gate bias voltage. In contrast, the work [51] proposes methods to aid decisions that significantly impact the power consumption strategies by validating firmware-based power management implementations.
The proposal presented in [103] is well-suited for lowintensity tasks at low data rates and uses a microcontroller running at 25MHz. Further, the work presents ultra-lowpower comparator circuits, which run on low frequencies to improve the power overshoot identification. Similarly, the work [55] keeps the CPU below 350mW when running facedetection routines and 35mW when the CPU is waiting for interrupts.

D. DISCUSSION
This section sought to review works that tackled or have similarities with security, reliability, and low-power characteristics. RISC-V enables designers to implement novel resources to improve the processor architecture features.
Due to the RISC-V nature of supporting a variety of environments, several works took advantage of the open ISA to provide security, reliability, and power efficiency solutions to secure processes as well as to run applications in an environment with low-power requirements.

VIII. CONCLUSION
Despite the novelty of RISC-V, a large variety of works aims at adapting and using RISC-V architectures to explore the capabilities of an open ISA. The different implementations of RISC-V aspire to improve or extend the fundamental specifications to satisfy peculiar computing needs. Low-level programming environments strive for a stable specification to comply with high-level programming environments. RISC-V's specification has primarily fulfilled these environments by providing engineers and researchers with a reliable ISA base. In addition, RISC-V's goal of supporting a broad set of computing environments has enabled enterprises and academia to tackle specific software requirements with low cost and flexibility.
This survey demonstrated how RISC-V is prevalent in works that seek to tackle specific requirements and how the community can benefit from an open architecture specification. Furthermore, given RISC-V's novelty and the rich software ecosystem, the community has well received and contributed to adopting RISC-V architectures into a wide range of systems, from small and constrained devices to largescale computers.