Space Computing: Radiation-Tolerant RISC‑V and SSCCS

Software-defined fault tolerance and coordinate-addressed storage for orbital environments

Author
Affiliation

SSCCS Initiative

SSCCS Initiative

Published

August, 2026

Abstract

This document projects the SSCCS computation vision onto RISC-V platforms whose designs are public, with space computing as the applied vision layer. The core is computation as structural observation: radiation-tolerant RISC-V platforms extended by SSCCS Fields for software-defined fault tolerance. The same coordinate discipline extends to storage and transmission, which are developed in their own documents and referenced here only where the computation layer depends on them. Hardware-level radiation hardening on current RISC-V platforms provides essential protection against single-event effects, but it is static: once fabricated, the protection mechanism cannot adapt, and it incurs area and power overhead. SSCCS adds a software-defined layer in which Fields, executable and cryptographically signed binaries encoding constraint predicates and transition matrices, are composed, sandboxed, and updated post-deployment, enabling adaptive temporal and spatial redundancy, semantic error detection beyond bit-wise ECC, and reduced SWaP. Chton extends the same structural principle to storage: the coordinate is the address, so there is no index to update, traverse, or corrupt. The RISC-V verification path is exercised by ExaVerif on the OpenHW CVA6 and Ibex cores [1] [2]. The report outlines architectural integration via OpenHW’s XIF interface and positions the synergy as a strategic response to ESA TRISTAN’s call for “deterministic, safe, and mixed-criticality aware” space processors [3].

Other Formats

PDF

LLMs

Introduction

Spaceborne and safety‑critical computing systems require high reliability under ionizing radiation. Recent years have seen the emergence of several radiation‑tolerant RISC‑V implementations employing hardened flip-flops, SECDED ECC, and Triple Modular Redundancy (TMR) to mitigate Single Event Upsets (SEUs); the current platforms are surveyed below. However, hardware hardening is static: once fabricated, the protection mechanism cannot adapt to new error patterns or mission phases, and it incurs significant area and power costs.

Concurrently, the SSCCS paradigm redefines computation not as instruction sequencing, but as the observation of stationary structures under dynamic constraints [4]. Central to this model is the Field, a mutable substrate that governs which states are admissible. Crucially, the SSCCS Whitepaper establishes that Fields are not merely abstract logic; they are first-class executable binaries that can be encrypted, signed, and sandboxed [4].

This report explores how the binary nature of SSCCS Fields could offer a unique solution to the rigidity of traditional Radiation Hardening by Design (RHBD). By loading “Fault Tolerance Fields” onto a radiation-tolerant RISC-V platform, adaptive, software-defined resilience could be achieved, evolving with the mission environment while reducing hardware overhead and enhancing resilience against complex failure modes like Multi-Bit Upsets (MBUs) and semantic corruption.

Note

Terminology Clarification: This report distinguishes between:

  • Radiation-Hardened (RH): Full tolerance to extreme environments (deep space, >100 krad, LET > 80 MeV·cm²/mg)
  • Radiation-Tolerant (RT): Mitigation for Low Earth Orbit (LEO) and cubesat environments (<50 krad, LET < 40 MeV·cm²/mg)

Current radiation-tolerant platforms target the RT regime; SSCCS Fields provide complementary semantic protection applicable to both regimes.

Scope: The Computation Vision, with Space as the Vision Layer

This document is a projection: the SSCCS computation vision, laid on RISC-V platforms whose designs are public (the RISC-V ISA, OpenHW CORE-V cores), with space computing as the vision layer on top. The core is computation as structural observation, software-defined fault tolerance through SSCCS Fields, and exhaustive verification by ExaVerif. The space context supplies the requirements that make the vision concrete: radiation tolerance, deterministic worst-case latency, and SWaP.

Focus Component Role
Computation Radiation-tolerant RISC-V + SSCCS Fields Software-defined fault tolerance: adaptive redundancy, semantic error detection (this document)
Identity and addressing synTagma / Tagma Coordinate substrate: 11,172 structurally valid 16-bit coordinates, ~300-gate decoder (design space until synthesized)
Verification ExaVerif Exhaustive verification of the RISC-V custom-instruction encoding space on OpenHW cores

The same coordinate discipline extends beyond computation to storage and transmission. Those surfaces are developed in Space-Grade Storage and Tagma Signal [5], with neXus coordinating the runtime [6]; this document references them only where the computation layer depends on them.

Realization subject. SSCCS is the paradigm and the foundation identity; it is not itself an executable. The computation vision is realized by the open-core stack, synTagma for the coordinate substrate, ExaVerif for verification, and the OpenHW CORE-V engagement as the route to silicon [7]. The full realization of the SSCCS concept is specific hardware: the Tagma hardware contract already specifies the combinational decoder and pipeline attachment [8].

Radiation‑Tolerant RISC‑V Platforms

Hardware hardening is the current baseline for radiation tolerance [9] [10] [11] [12]. Recent RISC‑V platforms combine hardened sequential elements, SECDED ECC, and Triple Modular Redundancy (TMR) to mitigate single‑event effects at the cost of area, power, and design‑time fixation. Two limitations are common across the field:

  1. Hard‑coded redundancy: protection mechanisms are fixed in hardware, preventing adaptation to varying radiation environments or mission phases.
  2. Semantic blindness: hardware‑level error detection (ECC, voters) operates on bits, not on application‑level semantics. A multi‑bit upset that results in a physically impossible state (e.g., velocity exceeding escape velocity) may go undetected.

The landscape below consolidates the current platforms and research contributions together with the SSCCS synergy opportunities that this document develops.

Study Approach Key Contribution Synergy
StarRISC [9] [10] RHBD with hardened flip‑flops + SECDED ECC Demonstrated functional operation after 100 kRad TID Ideal target for Field sandboxing via PMP; minimal area overhead for Field accelerator
PIC64‑HPSC (Microchip/NASA) [[13]] High‑performance RISC‑V with vector extensions 8× SiFive X280 cores, Vector Extension, up to 2 TOPS AI/ML SSCCS Fields for semantic validation of AI inference outputs in autonomous navigation
CORE‑V MCU (OpenHW) [[14]] Ultra‑low‑power RT RISC‑V for cubesats RV32IMC, PMP, SECDED ECC, 512KB SRAM Reference platform for Field binary loading and XIF integration
On‑Demand Lockstep (Simões et al., 2024) [15] Dynamic redundancy: cores operate in lockstep only when error rate exceeds threshold Reduces power overhead by activating redundancy only during high‑radiation periods SSCCS Fields can implement policy logic for mode switching decisions
MFID Decoder (Ghosh et al., 2025) [16] Multi‑bit fault‑tolerant instruction decoder using parity + ECC Protects against MBUs in instruction decode stage Complements SSCCS semantic validation at application layer
TRISTAN Roadmap (ESA, 2025) [3] European RISC‑V ecosystem strategy Supply chain resilience, certification framework, mixed‑criticality requirements SSCCS binary signing aligns with TRISTAN’s “trusted software stack” requirements

Threat Model and Security Assumptions

Before detailing the SSCCS integration, this section defines the adversarial and environmental assumptions:

Radiation Environment Model

Parameter LEO/CubeSat Regime Deep‑Space Regime
Total Ionizing Dose (TID) 5–30 krad(Si) 100–1000 krad(Si)
Linear Energy Transfer (LET) < 40 MeV·cm²/mg > 80 MeV·cm²/mg
Dominant Faults SEU, occasional MBU MBU, SEL, cumulative degradation

Dose and LET figures are cited from the space radiation literature and are not independently verified in this document.

Adversarial Capabilities

  • Passive: Natural radiation causing SEUs/MBUs in logic, memory, or interconnect
  • Active (theoretical): Fault injection via directed energy or compromised software updates

SSCCS Security Assumptions

  1. Root of Trust: Public verification key stored in OTP; immutable after fabrication
  2. Field Signing: All .field binaries signed with Ed25519 or ECDSA-P256; verification before execution
  3. Memory Isolation: PMP enforces strict read/write/execute permissions for Field code, data, and Segment storage
  4. No Side‑Channel Leakage: Field execution time bounded; no data‑dependent branching in constraint predicates

The Core Enabler: SSCCS Fields as Executable Binaries

The synergy with a radiation-tolerant RISC-V platform relies entirely on the properties of SSCCS Fields described in Section 2.3.3 of the SSCCS Whitepaper [4].

Dual Nature of Fields

In SSCCS, a Field \(F = (C, T)\) consists of a constraint predicate \(C\) and a transition matrix \(T\). While logically these define admissibility, physically:

Property Description
Executable Binaries A Field is compiled into a platform-independent binary format (.field) containing bytecode for constraint evaluation and transition weighting
Cryptographic Integrity Fields are digitally signed. This ensures that only authorized fault-tolerance policies (e.g., from Mission Control) are executed on the spacecraft, preventing malicious or corrupted updates
Sandboxing Fields execute in isolated environments via PMP. A faulty or compromised Field cannot corrupt the underlying Segment data or other Fields, providing inherent structural isolation [4]

Conceptual .field Binary Format

# Header structure for SSCCS Field binaries
field_header:
  magic: "SSCCS_FLD"          # 8B identifier
  version: uint16             # Format version (current: 0x0100)
  signature_alg: uint8        # Ed25519=1, ECDSA-P256=2
  constraint_type: uint8      # Dimensional=1, Algebraic=2, Semantic=3 [[@lee2026]]
  code_offset: uint32         # Byte offset to constraint bytecode section
  data_offset: uint32         # Byte offset to T-matrix/parameters section
  code_size: uint32           # Size of bytecode section (bytes)
  data_size: uint32           # Size of parameter section (bytes)
  timeout_cycles: uint16      # Max execution cycles for constraint eval
  signature: byte[64]         # Cryptographic signature over header+payload

Dynamic Composition

Fields support algebraic composition (Union, Intersection, Product) at the binary level [4]. This allows for runtime reconfiguration of fault tolerance strategies. For example:

Mode Field Configuration Use Case
Normal Mode Field_ECC_Light (minimal checking) Low-radiation environment; maximize performance
Solar Storm Mode Field_ECC_Heavy ∩ Field_Temporal_Vote High-radiation period; strict temporal redundancy
Autonomous Nav Mode Field_Semantic_Nav ∪ Field_Voting_Swarm Multi-spacecraft coordination with semantic validation

This capability transforms fault tolerance from a hardware feature into a software-defined service.

Figure 1: SSCCS Field composition operations: union, intersection, and product for dynamic fault tolerance configuration

Synergy: Software-Defined Radiation Hardening (SDRH)

As a hypothetical integration scenario, a hybrid architecture is conceivable in which a radiation-tolerant RISC-V core provides the physical baseline resilience, while SSCCS Fields provide the adaptive, semantic resilience layer.

Temporal Redundancy via Observation Fields

Traditional TMR uses three physical cores. SSCCS enables Temporal TMR using a single core via the OBSERVE primitive. A “Stability Field” can be defined to require that a Segment’s value remains consistent across multiple observations within a time window.

Figure 2: Temporal redundancy pipeline: Stability Field detects SEUs through repeated observation and comparison 
// Conceptual Rust-like pseudocode for a Stability Field
let stability_field = Field::new()
    .with_predicate(|segment| {
        let val_t0 = observe(segment);
        let val_t1 = observe(segment); // Re-observe
        val_t0 == val_t1 // Admissible only if stable
    })
    .with_timeout(50) // Max 50 cycles for evaluation
    .sign_with(mission_control_key);

Quantitative Analysis of Temporal Redundancy Overhead

The area overhead for SSCCS temporal redundancy is estimated at 8–12% relative to a baseline CV32E40P core, broken down as follows:

Component Resource Estimate Area Contribution
Constraint Evaluation Unit (CEU) ~500 LUTs (range checkers 200 + arithmetic 300) ~3.1%
Transition Matrix Unit (TMU) ~800 LUTs (4 multipliers + accumulator) ~4.9%
Field Descriptor Table (FDT) 1 KB SRAM ~2.0%
Segment Cache 2 KB SRAM ~1.0%
Total ~11%

This is dramatically lower than the ~200% area penalty of full TMR.

SEU Detection Probability: With a single observation, the probability of an undetected SEU is \(p\) (the raw upset rate). With a Stability Field requiring two agreeing observations, the probability of an undetected SEU becomes \(p^2\) (assuming independent upsets). For example, if \(p = 10^{-6}\) per cycle, temporal redundancy reduces undetected upset probability to \(10^{-12}\) per dual‑observation window.

Latency Model:

  • Best case (cache hit, simple constraint): 3–5 cycles
  • Typical case (cache hit, moderate constraint): 8–12 cycles
  • Worst case (memory fetch + semantic validation): 15–30 cycles

A configurable timeout_cycles field in the Field header prevents indefinite stalls.

Semantic Predictability Framework

Traditional fault tolerance operates at the bit level (ECC corrects flipped bits). SSCCS Fields operate at the semantic level (constraints validate physically admissible states). This enables a two‑tier defense:

Radiation Event → Hardware Layer → SSCCS Layer → System Response
SEU in register → ECC detects/corrects → Field predicate passes → Normal execution
MBU in memory  → ECC fails (valid codeword) → Semantic constraint fails → Safe fallback
Logic corruption → Voter disagreement → Temporal Field retry → Recovered state

Example: Navigation Coordinate Validation

// Semantic Field for spacecraft velocity constraint
let nav_field = Field::semantic()
    .with_constraint(|state: NavState| {
        // Physical law: |Δv| ≤ thrust_capacity × Δt
        let dv = state.velocity - state.prev_velocity;
        dv.magnitude() <= state.thrust_max * state.dt
    })
    .with_recovery(|state| {
        // Fallback: revert to last known-good state + alert
        state.revert_to_checkpoint();
        Alert::emit("Semantic violation detected");
    });

This approach directly addresses ESA’s concern about “non‑deterministic latency in mixed‑criticality systems” [3] by providing deterministic semantic validation independent of memory contention.

Distributed Voting with Signed Fields

In a multi-core or swarm configuration, SSCCS Fields enable Software-Defined Consensus. A “Voting Field” can be broadcast to multiple radiation-tolerant RISC-V nodes. Each node observes its local Segment and projects a value. The Field’s transition matrix \(T\) aggregates these projections using a majority vote or weighted average [4].

Advantage Description
No Hardware Voter The voting logic is contained within the Field binary
Cryptographic Security Since the Field is signed [4], a compromised node cannot inject a malicious voting algorithm
Adaptive Topology Voting weights can be updated on-orbit to account for node degradation

Architectural Implementation on OpenHW CORE-V

To explore the feasibility of this synergy, implementing SSCCS runtime support on the OpenHW CORE-V platform might be considered as a potential pathway, leveraging the eXtension Interface (XIF) [17].

Custom Instructions for Field Execution

Efficient execution of Field binaries would require hardware acceleration for the OBSERVE and COLLAPSE operations. Two custom instructions could be introduced via XIF:

Instruction Operation Description
OBSERVE rd, rs1, rs2 Project Segment Reads Segment at rs1, applies Field at rs2, stores result in rd. Handles retry logic if configured
COLLAPSE rd, rs1, rs2 Aggregate Projections Combines multiple observations using the Field’s transition matrix \(T\)

Instruction Encoding Details

Both instructions use the R‑type format within the RISC‑V custom‑0 opcode space. The encoding is as follows:

Field Bits OBSERVE COLLAPSE
funct7 [31:25] 7'b0000001 7'b0000010
rs2 [24:20] Field ID (index into FDT) Field ID (index into FDT)
rs1 [19:15] Segment ID (base address) Observation array base address
funct3 [14:12] 3'b000 3'b000
rd [11:7] Destination register Destination register
opcode [6:0] 7'b0001011 (custom‑0) 7'b0001011 (custom‑0) 
// RTL signal definitions for XIF coprocessor
`define OPCODE_CUSTOM0   7'b0001011
`define FUNCT7_OBSERVE   7'b0000001
`define FUNCT7_COLLAPSE  7'b0000010

These instructions could allow the radiation-tolerant core to offload the complex constraint evaluation of the Field to a tightly coupled coprocessor or accelerator, potentially minimizing performance overhead.

Figure 3: CV32E40P core and SSCCS Coprocessor interconnection via XIF interface for OBSERVE/COLLAPSE instructions

XIF Handshake Protocol for OBSERVE

Stage XIF Channel Description
1. Instruction Issue Issue Interface CPU asserts x_issue_valid; passes 32-bit instruction via x_issue_req.instr. SSCCS coprocessor accepts with x_issue_ready
2. Register Read Register Interface Coprocessor asserts x_register_valid; requests source register addresses via x_register_req.rs. CPU returns values with x_register_resp.rdata
3. Memory Access Memory Request/Response If OBSERVE needs Segment data, coprocessor issues load via x_mem_valid; receives data via x_mem_resp.rdata
4. Result Return Result Interface After computation, coprocessor asserts x_result_valid; supplies x_result.rd and x_result.data. CPU accepts with x_result_ready
5. Commit/Kill Commit Interface CPU asserts x_commit_valid upon instruction commit. If exception occurs, x_commit.commit_kill notifies coprocessor to abort

XIF Handshake Timing Diagram

Cycle T0 T1 T2 T3 T4 T5 T6
x_issue_valid 1 0 0 0 0 0 0
x_issue_ready 1 0 0 0 0 0 0
x_register_valid 0 1 0 0 0 0 0
x_register_ready 0 1 0 0 0 0 0
x_mem_valid 0 0 1 0 0 0 0
x_mem_ready 0 0 1 0 0 0 0
x_result_valid 0 0 0 1 0 0 0
x_result_ready 0 0 0 1 0 0 0
x_commit_valid 0 0 0 0 0 1 0
x_commit_kill 0 0 0 0 0 1 (if exception) 0

Secure Field Loading

Leveraging the Binary-Level Composition Protocols [4]:

  1. Upload: New Field binaries (e.g., updated fault tolerance policies) are uploaded to the platform’s secure memory.
  2. Verification: The SSCCS Runtime verifies the Ed25519/ECDSA signature of the Field binary against a root of trust stored in OTP.
  3. Sandboxing: The Field is loaded into a protected memory region (using PMP - Physical Memory Protection). It can only access Segments explicitly granted permission, preventing side-channel attacks or fault propagation [4].

Key Management for Long-Duration Missions

Space missions lasting years require the ability to update cryptographic keys post‑launch. The following key rolling mechanism is adopted:

  1. Initial Provisioning: OTP stores a single Master Public Key (immutable) programmed during fabrication.
  2. Key Update Procedure:
    • Ground station generates a new key pair (PubKey₁, PrivKey₁).
    • A special Key Update Field is created, containing the hash of PubKey₁ and signed by the Master Private Key (held securely on ground).
    • The spacecraft receives and verifies the Key Update Field using the Master Public Key.
    • Upon successful verification, the hash of PubKey₁ is written to a designated Key Segment in ECC‑protected SRAM.
  3. Field Verification with Updated Key:
    • Subsequent Field binaries may be signed with PrivKey₁.
    • The runtime verifies the Field signature using PubKey₁, validating the chain: Master → PubKey₁ → Field.

This approach maintains cryptographic agility while preserving the root of trust.

Figure 4: Secure Field loading and PMP sandboxing: signature verification and memory isolation

PMP-Based Memory Isolation Layout

Memory Map (example: 512 KB ECC SRAM on a radiation-tolerant RISC-V platform):

Address Region PMP Configuration
0x0000_0000 Trusted Runtime (TEE) LOCK, R‑X
0x0001_0000 Field Code Section LOCK, R‑X
0x0002_0000 Field Data Section RW
0x0003_0000 Segment Storage R (Field only)
0x0004_0000 Application Memory RWX

Coordinate-Addressed Storage

The computation layer rests on a coordinate-addressed substrate. Chton materializes coordinate spaces directly onto physical media without indexing or hashing, so a coordinate resolves to a physical address by arithmetic, with bounded access independent of dataset size [18]. The space-grade analysis, including radiation-tolerant media and the SWaP argument, lives in Space-Grade Storage and is referenced here only as the substrate the computation layer assumes.

Conclusion

The conceptual integration of a radiation-tolerant RISC-V core and SSCCS suggests the potential for more than incremental improvement: it points toward a possible new design paradigm for resilient space computing. By exploiting the executable, composable nature of SSCCS Fields [4], this synergy transcends the limitations of static hardware hardening:

Dimension Traditional RHBD SSCCS‑Enhanced Architecture
Adaptability Fixed at fabrication Post‑launch policy updates via signed Fields
Error Coverage Bit‑wise (ECC, voters) Semantic + bit‑wise (two‑tier defense)
Resource Efficiency ~200% area for TMR <10% overhead for temporal redundancy
Verification Simulation + testing Formal constraint validation + runtime monitoring
Supply Chain Proprietary IP dependencies Open-source (OpenHW + SSCCS); transparent auditability

This synergy directly addresses the strategic imperatives identified by ESA TRISTAN: supply chain resilience through open standards, and deterministic execution for mixed‑criticality autonomy [3]. Furthermore, the cryptographic signing of Fields aligns with emerging space cybersecurity frameworks, providing a verifiable chain of trust from ground station to orbit.

A joint proof‑of‑concept with the OpenHW ecosystem could validate the XIF‑based SSCCS accelerator, potentially positioning this architecture as a reference implementation for next‑generation European and global space computing initiatives. The open-source nature of both the RISC-V core and SSCCS would enable transparent verification, a critical differentiator for safety‑critical space missions.

The computation vision rests on one coordinate substrate that also carries storage and transmission; those surfaces are developed in their own documents and referenced here only where the computation layer depends on them.

The grounds in this document (radiation-tolerant computation, coordinate-addressed storage, semantic fault tolerance) and the implementation interact in both directions: the grounds set the constraints the implementation must meet, and implementation measurements, once field-validated, will upgrade the cited and modeled claims in these grounds into measured ones.

Status

Component Status (2026-08) Class Evidence
Tagma coordinate identity Specified, benchmarked, exhaustively enumerable measured synTagma
ExaVerif verification of OpenHW cores Reports published measured CVA6 CV-X-IF Report (Standard Reference), Ibex RV32IMCB Report
neXus swarm runtime Runtime implemented and benchmarked measured neXus
Chton space-grade storage analysis Published cited, modeled Space-Grade Storage
Tagma Signal signal layer Digital path measured; physical layer modeled measured, modeled Tagma Signal
OpenHW CORE-V integration Engagement in discussion cited SSCCS Validation with OpenHW CORE-V Ecosystem
XIF Field accelerator (OBSERVE/COLLAPSE) Conceptual, this document modeled Architectural implementation section
On-orbit demonstration Not started modeled Phased roadmap

Glossary

Term Definition
Segment Immutable coordinate in possibility space; minimal unit of potential
Scheme Structural blueprint defining Segment relationships and adjacency
Field Mutable constraint substrate that governs what can be observed; executable binary in SSCCS
Observation (Ω) Active computation event that reveals Projection from Structure + Field
Projection Ephemeral, deterministic output of an Observation at the logical model level
Chton Materialization layer that projects coordinate spaces onto physical media without indexing or hashing
Tagma 16-bit structural coordinate; the identity and addressing primitive of synTagma
XIF CORE-V eXtension Interface for tightly coupled coprocessors
RHBD Radiation Hardening by Design
RT Radiation-Tolerant (mitigation for LEO/cubesat environments)
RH Radiation-Hardened (full tolerance for deep-space environments)
SEU Single Event Upset
MBU Multi-Bit Upset
TMR Triple Modular Redundancy
SECDED Single Error Correction, Double Error Detection
PMP Physical Memory Protection (RISC-V)
OTP One-Time Programmable memory
SWaP Size, Weight, and Power

References

[1]
SSCCS Initiative, “CVA6 CV-x-IF report: Deterministic encoding validation with ExaVerif.” 2026. Available: https://docs.ssccs.org/projects/ev/cva6.html
[2]
SSCCS Initiative, “Ibex RV32IMCB report: Structural enumeration with ExaVerif and synTagma.” 2026. Available: https://docs.ssccs.org/projects/ev/ibex.html
[3]
European Space Agency (ESA), “TRISTAN: Towards a european RISC-v space ecosystem,” ESA Technical Directorate, White Paper, 2025.
[4]
T. Lee, “Schema–segment composition computing system whitepaper.” DOI: 10.5281/zenodo.18759106, 2026. Available: https://docs.ssccs.org/whitepaper/whitepaper.html
[5]
SSCCS Initiative, “Tagma signal: Structural coordinate transmission.” 2026. Available: https://docs.ssccs.org/projects/syntagma/tagma/signal/
[6]
SSCCS Initiative, “neXus: Swarm computing runtime fabric with n-dimensional state space storage.” 2026. Available: https://docs.ssccs.org/projects/nexus/
[7]
SSCCS Initiative, “SSCCS validation with OpenHW CORE-v ecosystem.” 2026. Available: https://docs.ssccs.org/works/openhw_integration.html
[8]
SSCCS Initiative, “Tagma hardware contract: Coord 16-bit newtype and the combinational decoder.” 2026. Available: https://docs.ssccs.org/projects/syntagma/tagma/impl#coord-16-bit-newtype-with-hardware-contract
[9]
C. Elash et al., “Efficacy of radiation hardening by design techniques on an ASIC 32-bit RISC-v microcontroller,” in 2025 CAP congress, 2025. Available: https://indico.global/event/442/contributions/124446/attachments/57723/110907/Efficacy%20of%20Radiation%20Hardening%20by%20Design%20Techniques%20on%20an%20ASIC%2032-bit%20RISC-V%20Microcontroller.pdf
[10]
U. of S. STARLab, “Radiation-hardened digital and analog circuits.” 2026. Available: https://research-groups.usask.ca/starr-lab/research-projects.php
[11]
D. Santos, A. M. P. de Mattos, D. Melo, and L. Dilillo, “Characterization of a fault-tolerant RISC-V system-on-chip for space environments,” in 36th IEEE international symposium on defect and fault tolerance in VLSI and nanotechnology systems (DFT), 2023, pp. 1–6. doi: 10.1109/DFT59622.2023.10313549.
[12]
A. Walsemann et al., “A radiation-resistant RISC-V microprocessor with TMR protection and SRAM scrubbing for high-energy physics applications,” Journal of Instrumentation (JINST), vol. 18, no. 2, p. C02032, 2023, doi: 10.1088/1748-0221/18/02/C02032.
[13]
Microchip Technology Inc. and NASA, “PIC64-HPSC: High-performance space computing platform,” NASA Jet Propulsion Laboratory, 2024. Available: https://www.microchip.com/en-us/products/microprocessors/64-bit-mpus/pic64-hpsc
[14]
OpenHW Group, “CORE-v MCU: Ultra-low-power radiation-tolerant RISC-v microcontroller.” OpenHW Group Documentation, 2025. Available: https://docs.openhwgroup.org/projects/core-v-mcu/
[15]
L. Simoes et al., “On-demand lockstep: Dynamic redundancy for RISC-v cores in space,” in Design, automation and test in europe conference (DATE), 2024.
[16]
S. Ghosh et al., “MFID: Multi-bit fault-tolerant instruction decoder for RISC-v based space processors,” in IEEE transactions on nuclear science (TNS), 2025.
[17]
O. Group, “CORE-v eXtension interface (XIF) specification.” 2025. Available: https://github.com/openhwgroup/core-v-xif
[18]
SSCCS Initiative, “Space-grade storage: A storage layer for orbital computing environments.” 2026. Available: https://docs.ssccs.org/projects/chton/space_storage.html
[19]
ESL-EPFL, “Xif_copro: CV-x-IF compatible coprocessor example.” 2025. Available: https://github.com/esl-epfl/xif_copro

© 2026 SSCCS Initiative — Open-source computing systems initiative building a computing model, software compiler infrastructure, and open hardware architecture.

Technical Appendix

Microarchitecture of the OBSERVE Instruction

The OBSERVE rd, rs1, rs2 instruction applies the constraints \(C\) defined by the Field (rs2) to a Segment (rs1) to produce a projection. According to the SSCCS Whitepaper, “observation momentarily activates the Field, triggering a collapse of possibility and generating a projection” [4].

Figure 5: OBSERVE instruction datapath: Segment Cache, Constraint Evaluation Unit, and Transition Matrix Unit

Key Hardware Blocks:

Block Estimated Overhead (RV32IMC) Description
Segment Cache ~2 KB; <1% area Small SRAM storing coordinate vectors of frequently accessed Segments; coupled with the platform’s ECC
Constraint Evaluation Unit (CEU) ~500 LUTs; ~3% area Combinational logic evaluating Field’s constraint predicate \(C(s)\). Supports three classes [4]: (1) dimensional (range checks), (2) algebraic (linear inequalities), (3) semantic (finite-state validation)
Transition Matrix Unit (TMU) ~800 LUTs; ~4% area Computes Field’s transition matrix \(T(s, s')\). Accelerates max/min and multiplication operations [4]

COLLAPSE Instruction Aggregation Mechanism

The COLLAPSE rd, rs1, rs2 instruction aggregates multiple observation results according to the Field’s transition matrix \(T\). In SSCCS theory, “collapse” refers to the process where “observation activates the Field, triggering a collapse of possibility and generating a projection” [4].

COLLAPSE is used in two primary scenarios:

Scenario Description
Temporal Aggregation Aggregating multiple time-separated OBSERVE results of the same Segment to filter transient SEUs
Spatial Aggregation Aggregating OBSERVE results from multiple nodes (cores) to implement distributed voting

COLLAPSE Operation Pseudocode

Input:  rs1 = Base address of observation results array
        rs2 = Field ID (defines T matrix)
Output: rd = Final aggregated projection value

Algorithm (fixed-point arithmetic in Q16.16 format):
1. Load T(s, s') matrix from Field Descriptor Table.
2. for i in 0..N-1:
3.     proj_i = Memory[rs1 + i*4]  // Load observation (32-bit)
4.     weight_i = T(prev_state, proj_i)  // Q16.16 weight
5.     accumulated_weight += weight_i
6.     weighted_sum += proj_i * weight_i   // Q16.16 multiplication
7. if accumulated_weight == 0:
       rd = previous_projection   // fallback (tie)
   else:
       rd = weighted_sum / accumulated_weight  // weighted average
   or majority_vote(proj_0..proj_N-1)          // majority vote with tie → previous

Fixed-Point Arithmetic: All weights and intermediate sums are maintained in Q16.16 format to avoid floating-point unit overhead, suitable for resource‑constrained space processors.

Tie-Breaking Policy: In majority voting, if no candidate receives >50% of weighted votes, the system retains the previous projection value (conservative fallback).

This aggregation is implemented by reading observations from memory via XIF’s Memory Request/Response interface, computing weights in the TMU, and returning the result via the Result interface.

Hardware TMR vs. SSCCS Temporal Redundancy Comparison

Comparison Item Hardware TMR SSCCS Temporal Redundancy
Redundancy Type Spatial: 3 cores simultaneous Temporal: Repeated observations on single core
Area Overhead ~200% increase ~8–12% (CEU+TMU+Field storage)
Power Overhead ~200% increase Additional consumption only during Field execution
SEU Detection Mechanism Majority voter (combinational circuit) Field stability predicate evaluation
MBU Coverage Limited by voter granularity Enhanced by semantic constraints
Adaptability Fixed at design time Dynamic (changeable by swapping Field binary)
Verification Simulation + radiation testing + Formal constraint validation

Technical Compatibility Assessment

Compatibility Element Current Design Status Feasibility Recommendation
XIF-based OBSERVE/COLLAPSE Defined at RTL encoding level High Future exploration might involve prototype development based on CV32E40PX + xif_copro [19]
CEU/TMU Hardware Units Functionality specified in Whitepaper [4] Medium Detailed microarchitecture design per constraint type required
PMP-Based Sandboxing Leverages standard RISC‑V feature High Optimization of Field-specific PMP context caching
Temporal Redundancy Mechanism Defined at algorithmic level with quantitative estimates High Validation via SEU injection simulation
Cryptographic Signature Verification Ed25519/ECDSA with key rolling High OTP public key storage required

A three-phase validation roadmap (Simulation → FPGA Emulation → Radiation Testing) could provide an appropriate approach for systematically verifying these compatibility elements. In particular, the CV‑X‑IF compatible coprocessor example (xif_copro) [19] offers a reference template that could be adapted for SSCCS instruction implementation, potentially enabling use in Phase 2 FPGA emulation. The OpenHW CORE-V integration engagement [7] is the current route toward Phase 1 FPGA emulation, and the CVA6 CV-X-IF report [1] already exercises the XIF encoding space that the accelerator would consume.