A Portable, Compact, and Fault-Tolerant Processor for Spaceflight Applications

Abstract

This paper presents the Goddard RISC-V (GRV) a compact, portable, and highly customizable fault-tolerant 32-bit RISC-V processor, specifically designed for embedded space applications. The design integrates advanced fault-tolerance mechanisms to mitigate arbitrary Single Event Transient (SET) and Single Event Upset (SEU) errors while ensuring data integrity. Importantly, fault tolerance is achieved entirely at the design level, eliminating the need for SEU-hardened semiconductor processes, custom cell libraries, or specialized back-end tools. The implementation prioritizes portability and resource efficiency, enabling compatibility with various FPGA and ASIC technologies. This initiative aims to provide NASA with a suite of portable, modular, and scalable alternatives to proprietary solutions. These solutions are designed for broad adaptability across multiple platforms, such as compact scientific instruments, miniaturized deep-space technologies, CubeSats, control and automation systems, and other applications constrained by low-resource processing environments.

1. Introduction

As space missions venture deeper into the universe, the scientific observation and analysis of remote locations increasingly rely on advanced autonomy to achieve their science objectives. Emerging applications, such as Artificial Intelligence (AI) and Machine Learning (ML), necessitate substantial enhancements to spacecraft computational power to maximize the quantity and quality of scientific output. To meet these demands, the design of processors for space applications is evolving with a focus on boosting computational capabilities. Modern architectures are built upon multicore systems, incorporating multiple levels of cache memory and high-speed interconnection buses that deliver significant performance gains. Notable examples include the LEON5FT and NOELV processors developed by Frontgrade Gaisler [1,2], as well as the ongoing High Performance Spaceflight Computing (HPSC) Program led by NASA (As of April 2026, these processors are still in development or in the final stages of the qualification process. To the best of the author’s knowledge, they have not yet been officially used in any mission) [3].

Currently, one of the most commonly used processors for space applications is the LEON3FT [4]. It has been successfully utilized in several missions. One example of a platform based on this processor is the The Modular Unified Space Technology Avionics for Next Generation (MUSTANG) [5] designed by NASA Goddard Space Flight Center (GSFC). Another approach takes advantage of the increasing integration level in Field Programmable Gate Arrays (FPGAs), which now feature high-resource devices with embedded processors. The SpaceCube [6] platform exemplifies this method, utilizing the processing capabilities of embedded cores within select Xilinx FPGAs.

However, the architectures described above are not well-suited for applications such as a Data Processing Unit (DPU) for compact instruments, control systems of miniaturized actuators or mechanisms used in robotic missions and Command and Data Handling (C&DH) system tailored for platforms like Nano-Satellites or CubeSats. This is primarily due to constraints such as limited budgets, the high cost of components including licensed Intellectual Property (IP) cores, strict power consumption or footprint requirements, and the lack of a need for high-end computational capabilities. To address these challenges, a Finite State Machine (FSM) is often implemented in an FPGA. While this approach meets low power consumption demands, it poses a significant drawback: reduced design reusability. Typically, these FSMs are custom-designed from scratch for each mission, severely limiting their potential for reuse. Furthermore, even minor changes in system requirements necessitate adjustments to the FSM topology, which, in turn, triggers a fresh cycle of debugging and hardware validation. This process impacts both the project schedule and budget, adding complexity and inefficiency.

In this paper, we present GRV, a 32-bit RISC-V processor developed using Very High Speed Integrated Circuit Hardware Description Language (VHDL). This processor is specifically designed to address the challenges outlined earlier and serves as an excellent complement to the forthcoming HPSC initiative, effectively bridging a critical gap in the field. The GRV design prioritizes resource efficiency and portability rather than performance. It is not intended to compete with more capable processors in terms of performance. Every component of the architecture has been meticulously designed to minimize its resource footprint. Additionally, the design is fully independent of any specific FPGA technology, removing constraints tied to particular vendors, facilitating seamless migration of the design across multiple supported FPGA vendors including non-radiation-tolerant devices that are better suited for low cost missions. This independence is achieved through the use of technology wrappers for FPGA primitives, including pads, buffers, clock management, and memory blocks.

GRV leverages one of the most significant features of the RISC-V ISA specification: its modularity [7,8]. This modularity allows the processor to cover a broad range of applications while promoting software reuse. Thanks to the open and modular nature of RISC-V, designers can implement architectures tailored to their specific applications, ranging from low-performance, low-power microcontrollers to high-performance processors. New instructions are introduced as optional extensions rather than necessitating a complete overhaul of the ISA, ensuring flexibility. Furthermore, RISC-V systems have the capacity to evolve, with the specification spanning 32-bit to 128-bit architectures. Scalable hardware reduces costs, enables designers to work with familiar tools, and shortens development timelines. Additionally, upgradeable hardware extends the system’s lifespan, minimizing the time and resources needed for replacement technologies.

The remainder of this article is structured as follows. Section 2 reviews related work on fault-tolerant design methods, analyzing the key ideas behind each processor. Section 3 introduces the GRV processor, highlighting its main features and providing detailed information about its architecture. Section 4 presents the fault-tolerant techniques integrated into GRV to mitigate the effects of radiation in space environments. Section 5 details the methodology and experimental work performed to validate the design, including performance evaluations. Section 6 reports the implementation results across different FPGA vendors. Finally, Section 7 concludes this article by summarizing the key findings of this work.

2. Related Work

The current state of RISC-V bears notable similarities to the evolution of the Scalable Processor Architecture (SPARC) during the 1990s. However, the current trajectory of RISC-V appears even more promising than that of SPARC during its formative years. This is attributed to its modular ISA design, a rapidly growing software ecosystem backed by an active and dynamic community, and an unprecedented surge of open-source intellectual property and commercial advancements.

The LEON family of processors can be considered a precursor specifically tailored to the space industry. At that time, the European Space Agency (ESA) adopted SPARC as it was the only solution available that offered both openness and robust software support. Since then, the European space industry, along with a substantial portion of the global space community, has depended on LEON-based systems, accumulating extensive flight heritage and fostering a well-established software and hardware ecosystem. The LEON processors have undergone significant advancements since the introduction of the LEON2FT version, achieving substantial performance improvements while leveraging technological progress in manufacturing processes to enhance their radiation resilience [9]. In the original LEON2FT design, all on-chip registers were protected with Triple Modular Redundancy (TMR), while the cache memories, register window, and external memory interfaces were equipped with Error Detection and Correction (EDAC) mechanisms to mitigate radiation effects [10].

With the development of RISC-V, numerous open-source processor cores have emerged in both academic and commercial markets [11]. Di Mascio et al. present a roadmap for adopting RISC-V in space, arguing that the ISA’s openness and modularity make it well suited to a range of spacecraft roles from low-power microcontrollers to AI-capable payload processors [12]. Their survey of open-source cores, toolchain maturity, and ecosystem gaps highlights fault tolerance and technology readiness as primary barriers to wider space adoption. This work complements our contribution by motivating the need for architecture-level demonstrations and targeted verification: whereas Di Mascio et al. identify the high-level opportunities and challenges for RISC-V in space, our paper provides a concrete, verified implementation of a RISC-V processor (GRV) with integrated TMR/EDAC and instrument interfaces that directly addresses the fault-tolerance and TRL concerns they raise.

However, to the best of the author’s knowledge, there are currently very few publicly available RISC-V processors featuring fault-tolerant architectures. The SHAKTI-F processor [13], developed by the Indian Institute of Technology, is an open-source RV32I processor written in Verilog that utilizes Error Correcting Codes (ECC) to address errors in registers and memory systems. DuckCore [14] incorporates an enhanced Single Error Correction and Double Error Detection (SECDED) code and builds upon the architectural principles of SHAKTI-F. In [15], a low-power three-stage pipelined RISC-V processor, which utilizes Hamming codes to safeguard memory elements and TMR to protect the Arithmetic and Logic Unit (ALU) as well as the control unit, is presented. Mong Tee Sim et al. [16] utilized dual-core lockstep technology, built upon the RV32I core, to achieve fault tolerance. Rogenmoser et al. [17] present Trikarenos, a TSMC 28-nm RISC-V SoC whose ECC scrubbing and triple-core lockstep protections were validated through neutron and proton irradiation and gate-level fault injection, yielding quantitative SEU cross-sections and demonstrating the effectiveness of combined architectural and memory-level mitigation strategies.

Böhmer et al. present neutron-beam tests of the NEORV32 RISC-V SoC on Flash-based FPGAs, demonstrating that ECC protection of instruction and data memories substantially improves operational reliability and that register-level TMR provides further gains at increased resource cost [18]. This approach aligns with our design goals. However, unlike their FPGA-toolchain-based protections, we implement ECC, TMR and related mitigations directly at the RTL level, which gives us finer control over area and timing trade-offs. Cora et al. [19] propose a selective-hardening methodology that identifies the most fault-sensitive modules of a NEORV32 soft processor and applies TMR/ECC only to those components, achieving reliability comparable to full-chip redundancy with lower area and timing overhead. Barbirotta et al. [20] demonstrate how Interleaved-Multi-Threading can be adapted to provide temporal redundancy and fault tolerance in a Klessydra-T13 RISC-V soft core, detailing the required microarchitectural support.

3. The GRV Architecture Design

This section provides a detailed overview of the GRV processor architecture, organized into subsections that focus on the core system components: the pipeline, system bus, memory interfaces, floating point unit, debug unit and the implementation of error-detection and fault-tolerant features.

The GRV processor is a 32-bit design fully compliant with the RISC-V ISA Specification. It utilizes a Harvard architecture with separate instruction and data buses. The processor interfaces with the Advanced High-performance Bus (AHB) via the Load Store Unit (LDSTU). Local resolution mechanisms handle access conflicts between the data and instruction interfaces, ensuring that only one AHB master interface is connected to the bus. A block diagram of the GRV architecture is presented in Figure 1.

3.1. Pipeline

The GRV processor features a single-instruction issue pipeline with three stages. Each instruction requires a minimum of three cycles to progress through the pipeline, one cycle per stage. However, certain instructions cannot be completed within a single cycle during the Execute Stage (EX), causing the pipeline to stall until execution is fully completed. The pipeline’s block diagram is presented in Figure 2, with a detailed description of its stages provided below:

• (IF) Instruction Fetch. The design incorporates two Instruction Prefetch Buffers (IPBs) arranged in a ping-pong configuration, each capable of storing a configurable number of instructions, with a default capacity of four. Instructions are fetched from memory and loaded into the active IPB, becoming valid by the end of this stage before being latched in the subsequent stage. The pipeline temporarily stalls when a branch, jump, or trap occurs, halting operation until the IPB is replenished.
• (DE) Decode. This stage analyzes the fetched instruction, determining its type and operands. It identifies the operation to be performed, the number of operands, and the registers involved. Additionally, the necessary resources are allocated accordingly.
• (EX) Execute. Arithmetic Logic Unit (ALU) operations, along with logical and shift functions, are executed during this stage. Memory accesses, Floating Point calculations, Bit-Manipulation operations, and other extension instructions requiring more than one cycle to complete will cause the pipeline to stall until their execution is finished. The results of ALU, logical, shift, or memory operations are then written back to the register file.

GRV processor supports several ISA extensions, hardware multiply and divide, privileged, compressed instructions, and debug, among others.

Table 1. RISC-V extensions supported by GRV.

Extension	Description
A	Atomic Instructions
C	Compressed Instructions
E	Embedded, 32-bit ISA with 16 registers
I	Integer, Base 32-bit ISA
M	Multiplication and Division
U	Less-privileged User-Mode
Zifencei	Stream Synchronization Instructions
Zfinx	Single-Precision Floating-Point in Integer Register
Zicntr	Base Counters
Zicond	Integer Conditional Operations
Zicsr	Control and Status Register Access Instructions
Zihpm	Hardware Performance Monitors
Zmmul	Integer Multiplication-only Instructions
Smppmp	Physical Memory Protection
Smcntrpmf	Counter Privilege Mode Filtering
Sdext	External Debug
Sdtrig	Trigger Module
Zba	Shifted-Add Bit-Manipulation
Zbb	Basic Bit-Manipulation
Zbc	Carry-Less Multiplication Instructions
Zbs	Single-Bit Instructions
Zbkb	Bit-Manipulation Instructions for Cryptography
Zbkc	Carry-Less Multiplication Instructions for Cryptography
Zbkx	Crossbar Permutation
Zknh	NIST Hash
Zkne	NIST AES Encryption
Zknd	NIST AES Decryption
Zksed	ShangMi Block Cypher
Zksh	ShangMi Hash

presents the full list of extensions supported by GRV.

3.2. System Bus

The GRV processor is designed for integration into System-on-Chip (SoC) architectures structured around the Advanced Microcontroller Bus Architecture (AMBA) 2.0. Leveraging a widely adopted standard like AMBA ensures seamless incorporation of heritage components, thereby minimizing development time and enhancing overall system reliability.

GRV-based System-on-Chip (SoC) architectures feature the Advanced High-Performance Bus (AHB) and the Advanced Peripheral Bus (APB). The AHB bus connects key components, including the GRV processor, memory controller, and other high-bandwidth devices such as SpaceWire links, Ethernet 10/100 interfaces, and CAN-2.0 interfaces. Additionally, the Debug Module (DM) is integrated into the AHB bus. The APB Bridge acts as a follower on the AHB bus and as a leader on the APB bus, facilitating access to on-chip registers in peripheral devices such as Universal Asynchronous Receiver/Transmitter (UART) interfaces, Pulse Width Modulation (PWM), Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C), timers, and general-purpose I/O ports. This architecture enables straightforward integration of new modules by connecting them to either the AHB or APB bus.

The LDSTU, which integrates the instruction and data engines, arbitrates and controls bus accesses to the various memory spaces, memory controllers, and peripherals. The system is designed to manage memory-access faults autonomously: single-bit upsets are corrected transparently by the EDAC logic, while non-recoverable errors are reported to the processor as traps for software handling. This approach minimizes routine processor intervention, confines exception handling to genuinely unrecoverable conditions, and preserves deterministic bus behavior during normal operation.

3.3. Memory Interface

GRV offers a range of memory controllers designed for seamless integration with various types of memory, including Static Random-Access Memory (SRAM), Synchronous Dynamic Random-Access Memory (SDRAM), Programmable Read-Only Memory (PROM), Magnetoresistive Random-Access memory (MRAM), SPI FLASH, and NAND FLASH. Additionally, Tightly Coupled Memories (TCM) can be directly connected to the system bus.

3.4. Multiplier and Divider

GRV provides hardware support for multiplication and divide operations, when the M Extension is enabled. Several multiplier implementations are provided, making it possible to choose between area, delay and latency. The latency of multiplication instructions varies by implementation, ranging from 4 to 35 clock cycles. The divider uses the Serial Restoring Algorithm, and it takes 36 clock cycles to complete an operation [21].

3.5. Floating Point Unit

The GRV processor integrates an IEEE-754 [22] compatible single-precision Floating Point Unit (FPU) designed for use with the Zfinx extension. Prioritizing minimal area footprint, the FPU architecture leverages iterative computation techniques to optimize resource utilization [23].

3.6. Debug Module

GRV incorporates a Hardware Debug Support Unit compliant with the minimal RISC-V Debug Specification version 1.0. It supports the Execution-Based Debug Scheme and System Bus Access, providing full CPU control, including halting, resuming, and single-step functionalities. Through the Program Buffer and System Bus Access, it enables access to all core registers and the entire address space. The unit is compatible with the Open On-Chip Debugger (OpenOCD) and GDB, and it is accessible via a standard JTAG Joint Test Action Group (JTAG) interface.

4. Error Detection and Fault Tolerance

GRV is specifically designed for radiation-hardened applications and incorporates extensive Fault Tolerance (FT) mechanisms to mitigate the effects of SETs and SEUs. These mechanisms provide robust error detection and handling without relying on an SEU-hardened semiconductor process, custom cell libraries, or specialized synthesis tools. The primary objective of GRV is to detect and tolerate single errors in any on-chip register without requiring software intervention while also suppressing the effects of SEUs in combinational logic.

To achieve these goals, the design integrates a comprehensive set of protection features, including RTL-level TMR and EDAC, whose implementation and rationale are detailed below. The chosen techniques draw on a substantial heritage of proven approaches deployed in multiple NASA missions and on lessons learned from the wider space-agency community during the rapid adoption of FPGA-based systems [24,25,26,27,28]. This accumulated operational experience and interagency knowledge exchange informed the selection, tuning, and validation strategy for GRV FT suite.

4.1. Triple Modular Redundancy (TMR)

In a typical implementation, GRV contains approximately 4500 flip-flops, used for temporary storage and FSMs. To protect these elements against SEU-induced errors, all on-chip registers can be implemented using TMR directly in the VHDL-RTL source code, without requiring any specialized cell library or synthesis tool [10]. This approach utilizes three registers operating in parallel, with a voter selecting the majority result as illustrated in Figure 3. Since the flip-flops are continuously clocked, any SEU-induced register error is automatically corrected within a single clock cycle, ensuring the voter output remains accurate and glitch-free. This scheme inherently provides error masking and error removal, preventing transient glitches at the output when an SEU occurs. The TMR feature can be configured through a VHDL generic in the design’s configuration record. When set to true, all on-chip registers are implemented using TMR.

4.2. EDAC Protection

The FPGA’s external and internal memory blocks are safeguarded by an on chip EDAC unit, which also provides dedicated error injection capabilities. This unit is capable of correcting single-bit errors and detecting double-bit errors within each 32-bit word [29]. If an uncorrectable error (double-bit error) is detected, a memory exception is signaled to the processor. The resulting trap is always precise, ensuring simplified software recovery via rollback or roll-forward, as no instructions have been executed beyond the point of error. In contrast, correctable errors do not trigger an exception. The equations below define the generation of EDAC check bits.

$$\begin{array}{c}\hfill CB0=D00\oplus D04\oplus D06\oplus D07\oplus D08\oplus D09\oplus D11\oplus D14\oplus D17\oplus D18\oplus D19\oplus D21\oplus D26\oplus D28\oplus D29\oplus D31\\ \hfill CB1=D00\oplus D01\oplus D02\oplus D04\oplus D06\oplus D08\oplus D10\oplus D12\oplus D16\oplus D17\oplus D18\oplus D20\oplus D22\oplus D24\oplus D26\oplus D28\\ \hfill CB2=D00\oplus D03\oplus D04\oplus D07\oplus D09\oplus D10\oplus D13\oplus D15\oplus D16\oplus D19\oplus D20\oplus D23\oplus D25\oplus D26\oplus D29\oplus D31\\ \hfill CB3=D00\oplus D01\oplus D05\oplus D06\oplus D07\oplus D11\oplus D12\oplus D13\oplus D16\oplus D17\oplus D21\oplus D22\oplus D23\oplus D27\oplus D28\oplus D29\\ \hfill CB4=D02\oplus D03\oplus D04\oplus D05\oplus D06\oplus D07\oplus D14\oplus D15\oplus D18\oplus D19\oplus D20\oplus D21\oplus D22\oplus D23\oplus D30\oplus D31\\ \hfill CB5=D08\oplus D09\oplus D10\oplus D11\oplus D12\oplus D13\oplus D14\oplus D15\oplus D24\oplus D25\oplus D26\oplus D27\oplus D28\oplus D29\oplus D30\oplus D31\\ \hfill CB6=D00\oplus D01\oplus D02\oplus D03\oplus D04\oplus D05\oplus D06\oplus D07\oplus D24\oplus D25\oplus D26\oplus D27\oplus D28\oplus D29\oplus D30\oplus D31\end{array}$$

(1)

4.3. Processor Register File

Given that most RISC-V instructions involve two source operands and one destination operand, the GRV processor incorporates a three-port register file, comprising two read ports and a single write port, to accommodate the architectural requirements. The GRV processor offers flexibility in register file implementation, allowing it to be constructed using either flip-flops or internal memory blocks within the FPGA. This adaptability enables users to optimize the design based on the FPGA’s specific characteristics. For example, the RTG4, a large device with inherently TMR-protected flip-flops, is well-suited for this configuration, eliminating the need for additional radiation protection in internal memory blocks. Furthermore, when the flip-flop implementation is used in other FPGAs, the TMR feature remains fully functional.

When memory blocks are used for implementation, each register is safeguarded by a 7-bit EDAC checksum (as shown in Section 4.2), enabling detection and correction of SEU errors within the register file. EDAC bits are validated each time a fetched register value is used in an instruction. If a correctable error is detected (Figure 4c), the pipeline is flushed and the erroneous data is corrected prior to use. The corrected register value is then written back to the register file during the execute stage. The pipeline subsequently restarts at the point of the failing instruction. This restart mechanism resembles a trap, with the key distinction being that control is transferred directly to the address of the failed instruction rather than to a trap vector. The correction process introduces a two-clock-cycle delay but remains invisible to software. Conversely, if an uncorrectable error is detected (Figure 4d), a register file error trap is generated. The pipeline restart imposes minimal implementation overhead, as it leverages the existing logic for standard trap handling. Figure 4b illustrates the pipeline behavior under normal trap conditions. The register file features two read ports, necessitating the implementation of two error-detection units. With only a single write port, a single correction unit suffices. Consequently, if multiple correctable errors are detected, the instruction is re-executed for each error, with one register value corrected and written back per iteration.

5. System Validation

To ensure architectural correctness and functional reliability, the processor underwent a comprehensive system validation campaign encompassing simulation, formal verification, and standards-based compliance testing. Central to this effort was conformance with the RISC-V ISA as defined by RISC-V International. The processor successfully passed validation using the RISC-V Compliance Framework (RISCOF) v1.23.4 [30], a modular Python v3.14 based infrastructure that facilitates rigorous compliance testing of RISC-V implementations. RISCOF compares the processor’s behavior against a trusted reference model and orchestrates test execution across multiple privilege levels and ISA extensions. The test suite included coverage of base integer instructions, control and status register (CSR) interactions, trap and exception handling, and optional extension functionality. The overall flow of the GRV verification using RISCOF is shown in Figure 5.

Achieving full compliance through RISCOF not only confirms the processor’s adherence to ISA specifications but also reinforces its readiness for deployment in broader system-level contexts. The reproducibility and depth of RISCOF’s testing regime provide a reliable baseline for future verification campaigns, performance tuning, and certification pathways. This milestone contributes to interoperability assurance within the RISC-V ecosystem and supports integration into mission-critical platforms that demand predictability and robust architectural alignment.

The next step was the development of low-level drivers for the peripherals integrated into GRV. A corresponding set of simulations was conducted to verify the correct integration and functional behavior of these devices.

As noted in Section 4, the fault-tolerance mechanisms employed in GRV are rooted in substantial flight heritage and a body of lessons learned exchanged across the space-agency community. Consequently, their behavior is well understood and considered proven. By leveraging these proven approaches and the cross-agency knowledge exchange, GRV inherits both tested design patterns and validated operational practices that reduce integration risk and accelerate qualification. We verified the correct integration of the fault-tolerance mechanisms in GRV through extensive RTL-level fault-injection campaigns conducted using VUnit [31,32], an Open-Source VHDL Verification Methodology (OSVVM) [33,34]. By leveraging the randomization and test-component capabilities provided by these frameworks, we performed both randomized and targeted single-bit and component-level injections to exercise the processor’s error-detection, correction, and recovery paths under realistic timing and interaction conditions. OSVVM’s RandomPkg and associated utilities supplied the constrained-random stimulus generation and coverage instrumentation required to drive a broad and statistically meaningful range of fault scenarios. Because TMR is implemented at the RTL level and protected components expose a configurable regid VHDL generic, injections could be precisely directed to individual registers and modules, enabling the TMR and EDAC mechanisms to be evaluated independently as well as in combination.

A full radiation campaign to correlate these simulation-derived results with measured SEU cross-sections and field Mean Time Between Failures (MTBF) estimates is planned as future work, to be conducted during the instrument-level testing and integration campaign [35].

A custom test board, shown in Figure 6, was developed to support functional validation of the GRV processor in conjunction with Lattice CertusPro FPGAs. The board provides a controlled laboratory platform for evaluating architectural behavior and communication interfaces under representative operating conditions. It incorporates multiple on-board memory types, SRAM, MRAM, and SPI-Flash with flexible memory mapping and selectable boot sources, enabling direct emulation and targeted testing of the various memory controllers supported by GRV. Its design supports seamless integration with external instrumentation, allowing detailed observation and automated performance analysis during verification campaigns. Standard mezzanine connectors, level shifters, and jumper-selectable interfaces ensure compatibility with a wide range of peripherals and simplify transitions to and from third-party development boards. In addition, dedicated probe headers, trigger I/O, and debug interfaces (JTAG, UART, SPI, I²C) provide robust access for instrumentation-driven, reproducible experiments.

6. Results

This section presents the GRV’s performance and resource utilization across multiple space-qualified FPGAs, highlighting its compact and efficient architecture.

6.1. Performance

Figure 7 compares the CoreMark/MHz [36] results for the processors evaluated in this paper. The GRV achieves a CoreMark/MHz score of 1.05, reflecting its balanced optimization for computational efficiency and low power. These results show that GRV is well suited for C&DH, small-instrument data processing, and mechanism-control tasks. Its deterministic execution, low-power profile, and RTL level fault tolerance make it a strong fit for resource constrained, reliability critical workloads. GRV is not intended to compete with complex architectures such as cache-rich, dual-issue designs with branch prediction. Its primary goal is to provide a low-power, low-resource solution that increases reusability and reduces development cost and time. By contrast, the SiFive X280 attains the highest efficiency in the set (CoreMark/MHz 5.8), reflecting its role as the most powerful design and its status as the commercial equivalent of NASA’s HSPC class; this makes the X280 better suited to high-throughput payload and data-processing tasks at the expense of greater area and power.

6.2. Resource Utilization

The resource utilization and power estimation results for the GRV implementation on multiple space qualified FPGAs, along with the corresponding FT-version results, are presented. The design incorporates several RISC-V extensions, including: M, U, Zicntr, Zihpm, Zfinx, Zifencei, Sdext, Sdtrig, and FPU. Additionally, the architecture integrates an external memory controller, comprehensive debug support, and a peripheral suite comprising dual UARTs, general-purpose I/O port, system timers, interrupt controller and Machine TIME register (MTIME).

Table 2. GRV resource utilization and power estimation for various space-qualified FPGA vendors.

FPGA	Resource/Parameter	Utilization (GRV)	Utilization (GRV-FT)
Microchip RTProASIC3 RT3PE3000L	Core Cells	27,002/75,624 (35.7%)	54,036/75,624 (71%)
	RAM4K9	6/112 (5%)	12/112 (10%)
	Frequency	32 MHz	16 MHz
	Power (mW)	76	116
Microchip RTG4 RT4G150	4LUTs	4896/151,824 (3.22%)	4896/151,824 (3.22%)
	DFFs	3216/151,824 (2.11%)	3216/151,824 (2.11%)
	RAM64x18	1/240 (0.5%)	2/240 (1%)
	RAM1K18	0/236 (0%)	0/236 (0%)
	Frequency	75 MHz	75 MHz
	Power (mW)	198	198
Lattice CertusPro-NX LFCPNX-100	SLICE	2512/79,872 (5%)	2512/79,872 (5%)
	LUT4S	8369/79,872 (11%)	8369/79,872 (11%)
	Registers	4552/80,769 (6%)	9140/80,769 (11.31%)
	EBR	2/208 (1%)	4/208 (2%)
	Frequency	100 MHz	50 MHz
	Power (mW)	160	245

shows that the FT implementation on the Microchip ProASIC3 and Lattice CertusPro-NX devices results in a significantly larger design, increasing flip-flop usage by approximately 100% due to the TMR implementation. Because the RTG4 FPGA provides built-in TMR across all device flip-flops, the GRV does not employ its own TMR option. As a result, the flip-flop utilization remains unchanged, with similar values in both versions, and the maximum achievable frequency shows no significant variation. The FT version exhibits increased memory block utilization because the EDAC protected processor register file memory allocates extra blocks to store the checkbits.

7. Conclusions and Future Work

The GRV processor represents a purpose-built solution for resource-constrained and mission-critical instrumentation platforms. Its compact, low-power architecture offers an effective balance between computational performance and area efficiency. GRV’s modular and fault-tolerant design presents a versatile and resource-conscious solution for deployment within spaceborne and high-reliability scientific instruments. A key architectural advantage of GRV lies in its demonstrated portability across multiple FPGA families, including both commercial and radiation-hardened variants. This cross-platform synthesis capability not only accelerates early-stage prototyping and qualification but also enables mission teams to adopt common processing frameworks across evolving deployment contexts. By reducing non-recurring engineering efforts and supporting a flexible integration path, GRV contributes significantly to advancing reconfigurable computing in space applications. Its modularity, efficiency, and synthesis portability position GRV as a scalable processing element for future-generation instrumentation with extended performance and reliability envelopes.

Initial integration efforts within instruments such as the Lunar Neutron Orbiting Observatory for Neutron Spectroscopy (LOONS) [37] and the Solar Neutron TRACking (SONTRAC) [38] demonstrate GRV’s versatility in supporting scientific objectives ranging from particle tracking to spectroscopic imaging. These efforts have focused on two parallel activities: the development of glue logic to interface GRV with instrument-specific electronics and specialized sensors, and the development of on-board software algorithms to perform preliminary data reduction and feature extraction prior to downlink. As a cornerstone of next-generation instrumentation, GRV significantly advances spaceflight computing by demonstrating how domain-tailored processor architectures can enable robust, scalable, and power-efficient mission solutions.