PIC64-HPSC：早期輻射測試結果對太空 RISC-V 韌體的意義

Microchip's PIC64-HPSC has reached another milestone in the development of next-generation spaceflight computing. In its update of October 27, 2026, the company reports early radiation-characterization results for the PIC64-HPSC1000-RH variant and progress in customer evaluations. For embedded-system developers, the interest lies in combining multicore RISC-V processing, fault management and onboard communications.

The family was introduced on July 9, 2024. The latest announcement concerns the platform's maturation. Understanding it requires separating architectural capabilities, experimental findings and the requirements of a particular mission.

The technical points behind the announcement

• Computing: eight 64-bit SiFive X280 application cores, alongside dedicated system and security controllers.
• Radiation: early TID characterization to 200 krad(Si) and SEL testing to 78.2 MeV·cm²/mg on the PIC64-HPSC1000-RH, under the conditions specified by Microchip.
• Development: customers in the Early Access Program are evaluating silicon and development kits; integration into a flight system still requires mission-specific verification.

What the announced results establish

Microchip's October 27 announcement also describes system-controller operation during SEE characterization completed to date, without uncorrected errors or a need for external resets. That finding has a defined scope: the particular controller and the reported test campaign. It does not establish the absence of errors across every subsystem, workload or radiation environment.

The engineering significance is the transition from a proposed design to measured behavior on silicon. Assessing a mission, however, requires the complete reports: samples and lots, supply voltages, temperatures, bias conditions, workloads, dosimetry and acceptance criteria.

Inside the architecture: eight application cores, ten cores overall

Despite the PIC name, PIC64-HPSC is a 64-bit RISC-V MPU. Its application complex contains eight SiFive Intelligence X280 cores with vector extensions; an additional core manages the system, while a separate controller handles security. This explains why the product page lists ten cores overall while application-processing specifications refer to eight.

The DS00005391D technical brochure specifies frequencies up to 1 GHz and different core and cache configurations. Functional separation matters: image processing, system supervision and key protection have different requirements even when they share a device.

PIC64-HPSC: 64-bit multicore RISC-V processing for onboard systems. Conceptual illustration.

Vector processing: how to interpret the performance figures

At the family's introduction, Microchip specified up to 2 TOPS at int8 or 1 TFLOPS at bfloat16 for vector matrix-multiplication operations across all eight cores. Those figures refer to particular operations and numerical precisions. They do not describe the execution speed of every algorithm or the performance of a complete onboard application.

An engineering assessment must account for transfers, memory access, synchronization, the operating system and power consumption. A classifier may benefit from vector operations; a pipeline dominated by acquisition and I/O may remain bandwidth-limited. Selecting a configuration requires measuring latency, energy and correctness on the actual workload, including fault conditions.

The science: what radiation does to space electronics

NASA's Radiation Hardness Assurance material describes environments that include particles trapped in planetary magnetic fields, solar-particle events and galactic cosmic rays. Orbit, inclination, duration and shielding change the exposure: two satellites described simply as operating in LEO can face substantially different radiation profiles.

At least three phenomena must be distinguished: total ionizing dose, displacement damage and single-event effects. Good behavior against one does not establish immunity to the others. As ESA's discussion of radiation-resistant circuits explains, semiconductor-process properties and design techniques affect a circuit's response. The RISC-V ISA defines executable instructions; the ISA alone does not make a chip radiation-resistant.

TID: 200 krad(Si) is an absorbed dose in silicon

Total Ionizing Dose describes absorbed ionizing energy per unit mass. In MOS devices, trapped charge in oxides and interface states can alter threshold voltages, leakage currents and electrical margins. The response also depends on technology, dose rate, temperature, bias and annealing.

The physical definition and unit conversion are:

D = absorbed energy / mass
1 rad = 0.01 Gy = 0.01 J/kg
200 krad(Si) = 2,000 Gy(Si) = 2 kGy(Si)

(Si) identifies the reference material. These quantities describe absorption in silicon and must not be confused with a biological equivalent dose in sieverts. NASA GSFC material on radiation hardness provides context for the terminology and characterization process.

The family documentation distinguishes a 100 krad(Si) specification with testing to 200 krad for the RH variant. The 2026 announcement reports an early characterization result at 200 krad(Si). Treating that figure automatically as a newly guaranteed operating dose would erase the distinction between an experimental result and a device specification.

TID and SEL describe different phenomena: accumulated ionizing dose and response to a single-particle effect.

SEE and SEL: why LET is not total dose

A single particle may generate enough charge to disturb a circuit node. A single-event upset (SEU) can change a bit; a single-event transient (SET) produces a transient disturbance; a single-event latch-up (SEL) can trigger a sustained parasitic high-current path. The outcome depends on the device and its protections: latch-up may require power interruption and can become destructive if the current is not controlled.

Linear Energy Transfer, in the density-normalized form commonly used in component testing, describes energy deposition along a particle's track:

LET = −(1 / ρ) · dE/dx
unit: MeV·cm²/mg

Consequently, 78.2 MeV·cm²/mg is neither accumulated dose nor the total energy of an arbitrary ion. Microchip's SEL result applies within its stated experimental conditions. Comparing devices also requires ion species and energy, penetration, angle of incidence, temperature, voltage and fluence. The ECSS material available through SPENVIS distinguishes these effects and introduces cross-section as a measure of susceptibility.

From a test result to mission risk: cross-section and statistics

The cross-section σ expresses susceptibility to an effect, typically in cm² per device or per bit. For heavy ions, it is often characterized as a function of LET. A simplified event-rate model combines this response with the expected differential flux behind shielding:

R ≈ ∫ σ(L) · φ(L) dL
Expected event count ≈ R · duration

Here, L denotes LET and φ(L) is the differential flux consistent with the chosen model. This explains the method; it is not a calculation for PIC64-HPSC. The complete response curves and mission profile are unavailable in the announcement. Protons and other mechanisms may require energy-based models and separate contributions.

Even “zero observed events” needs a statistical interpretation. Under an ideal-detection Poisson counting model, with zero events observed during fluence F, the one-sided 95% upper bound is:

P(0 events) = exp(−μ)
μ95 = −ln(0.05) ≈ 3
σ95 ≈ 3 / F

The derivation shows why observing no events places an upper bound on susceptibility rather than proving it is zero. Without fluence, monitoring coverage and test configuration, the announcement does not support a reliable numerical event-rate estimate.

RH, RT and Engineering Model: choosing the appropriate variant

The official family page distinguishes radiation-hardened and radiation-tolerant devices for different applications. The table summarizes family-level information; the October 27 result concerns the RH variant specifically.

Family documentation: check the exact part number and documentation revision applicable to the design.

A similar software environment makes development easier, but does not make laboratory models and mission devices interchangeable. Guaranteed conditions, qualification status and the documentation for the precise orderable part must be checked.

System reliability: lockstep, ECC and isolation

Microchip's technical white paper describes multiple protection layers: configurable Dual-Core Lockstep pairs, WorldGuard hardware partitioning, ECC protection and memory-interface error correction with scrubbing functions.

In lockstep, paired cores execute together and a mismatch can reveal a fault. That supports detection, but does not automatically identify the correct result or replace a recovery strategy. Cores allocated to redundancy are not simultaneously independent throughput resources for the application.

ECC corrects the error classes supported by its code and memory configuration. Scrubbing periodically checks and rewrites corrected data to limit error accumulation. Hardware isolation constrains access between domains; meeting deadlines additionally requires analysis of scheduling, arbitration and contention for shared resources.

These capabilities belong within a Fault Detection, Isolation and Recovery architecture. NASA's NESC recommendations on SEE emphasize considering both unrecoverable effects and recoverable errors, including recovery time. A system that restarts must also restore a coherent operational state.

Onboard networks and autonomy: data must reach the cores

The design combines Ethernet TSN, SpaceWire, PCIe Gen 3 and CXL 2.0 support. The cited 240 Gbit/s Ethernet-switch figure describes aggregate internal switching capacity, rather than the rate of an individual port. RoCEv2 supports low-latency transfers with less CPU involvement. These interfaces connect computing resources to sensors and potential accelerators.

An illustrative design scenario is an Earth-observation pipeline: acquisition, calibration, selection of useful regions, compression and downlink preparation. Local processing can reduce the volume sent to Earth. Actual benefits depend on the algorithm, required scientific quality and available energy; fewer transmitted bytes alone do not guarantee a better mission result.

Satellite platform with articulated solar arrays, a high-gain antenna and optical and thermal subsystems. Conceptual application scenario. Earth: NASA/Goddard Space Flight Center Scientific Visualization Studio.

Implications for firmware and mission-software developers

The evaluation platform and BSP allow development to begin before the final board exists. The Evaluation Platform documentation describes a modular baseboard, expansion options and daughter cards. The official ecosystem includes Linux, RTEMS and hypervisors. Declared support must be checked against the versions actually delivered and the peripherals used by the application.

The NASA HPSC white paper also discusses power management and partitioning: available processing capability changes with the mission phase. Software therefore needs explicit operating transitions, priorities and degraded modes.

Five activities provide a useful engineering verification path:

1. Define expected fault behavior. Establish which functions must continue, which may stop and which require transition to a safe state.
2. Separate workloads and domains. Allocate control, communications and payload processing; configure access rights, DMA, interrupts and timing budgets.
3. Measure beyond averages. Capture peak latency, missed deadlines and energy use during contention, memory corrections, timeouts and recovery.
4. Inject controlled faults. Exercise corrupted data, stalled peripherals, resets and interrupted transfers; verify telemetry, state consistency and restart behavior. Such tests assess recovery logic without replacing physical irradiation.
5. Make configurations reproducible. Track the BSP, toolchain, boot images, ECC and isolation settings alongside each test result.

In practical embedded firmware and Linux integration work, hardware availability must be accompanied by software that can be measured, observed and recovered.

The engineering significance of this milestone

Early PIC64-HPSC1000-RH results bring a platform combining vector processing, fault management and onboard connectivity closer to practical integration. For an actual project, the next step is to connect characterization reports to mission requirements and verify the entire chain: processor, memory, power supplies, board and software.

The decisive question is which function the system continues to perform, with what timing and data quality, when an error occurs. That is the engineering measure of the value of greater computing capability in space.

Technical sources

Primary sources are linked throughout: Microchip announcements and documentation, NASA Radiation Hardness Assurance material, and ESA and ECSS references on radiation effects in semiconductors. The program update is dated October 27, 2026. Specifications should be checked against the variant and revision applicable to the design.

Originally published on Silicon LogiX.