FPGA & VPU Co-Processing in Space Applications: Development and Testing with DSP/AI Benchmarks

Angelos Kyriakos; Arne Samuelsson; Aubrey Dunne; Charalampos Bezaitis; David Steenari; Dimitrios Soudris; Dionysios Reisis; Elissaios-Alexios Papatheofanous; George Lentaris; Vasileios Leon

REVIEW 3 major objections 6 minor 17 references

FPGA & VPU Co-Processing in Space Applications: Development and Testing with DSP/AI Benchmarks

T0 review · 3 major / 6 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper demonstrates that an FPGA and a commercial VPU can work as a co-processor for space on-board processing, sustaining 6-20 FPS on DSP kernels and more than 1 FPS on 1MP CNN image classification.

desk verdict A transparent lab report on FPGA+VPU co-processing with real measured FPS numbers, but the CNN throughput claim needs accuracy validation before it supports mission-relevant AI capability. read the letter →

arxiv 2506.12968 v1 pith:4QUZ5J2E submitted 2025-06-15 cs.AR

Vasileios Leon , Charalampos Bezaitis , George Lentaris , Dimitrios Soudris , Dionysios Reisis , Elissaios-Alexios Papatheofanous , Angelos Kyriakos , Aubrey Dunne

show 2 more authors

Arne Samuelsson David Steenari

This is my paper · ORCID

classification cs.AR

keywords FPGAVPUco-processingspaceapplicationsCIF/LCDinterfaceMyriad2CNNshipdetectionon-boarddataprocessing

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to establish that a heterogeneous FPGA-plus-VPU architecture is a viable low-power option for on-board space data processing. A Kintex FPGA acts as the framing processor and heritage accelerator, while a Myriad2 VPU offloads DSP/AI workloads. The authors connect the two chips through the CIF and LCD interfaces, normally meant for cameras and displays, and show error-free 1MPixel image transfers at 48 FPS. For kernels such as binning, convolution, and depth rendering, the whole system reaches 6-20 FPS, and a 6-layer CNN ship classifier runs at 1.4-1.5 FPS on 1024x1024 RGB images. If correct, this gives space systems a COTS-based path to edge processing without spending most of an FPGA's fabric.

What carries the argument

The load-bearing mechanism is the CIF/LCD interface pair, where the FPGA's Camera Interface sends pixel data into the VPU and the VPU's Liquid Crystal Display output returns results to the FPGA. The FPGA side is implemented in VHDL with pixel FIFOs, CRC-16 checking, and clock-domain-crossing registers, while the VPU side uses vendor camera and display driver routines plus its 12 SHA VE vector cores for processing. This repurposing of camera and display interfaces creates a generic, configurable I/O channel (8/16/24-bit pixels, independently set frame sizes and clocks) that lets a framing FPGA hand data to a low-power AI accelerator without a dedicated high-speed link.

What would settle it

Run the deployed 16-bit floating-point, 64-patch ship detector on a labeled set of 1024x1024 satellite images and compare its detection accuracy with the 96.8% training figure; if the detection rate drops below what a mission would require, the claimed CNN throughput is not evidence of usable ship detection.

Watch

Extended reading notes

Core claim

The central claim is that a mixed-criticality co-processing scheme, with a Kintex-class FPGA handling framing and transcoding and a Myriad2 VPU handling DSP/AI, can meet meaningful real-time throughput for space applications while consuming roughly 1 W on the VPU. The CIF/LCD interconnection transmits 1MPixel frames in about 21 ms at 50 MHz with zero CRC errors, which corresponds to 48 FPS for pure I/O. With both I/O and processing, the system delivers 6-20 FPS for averaging binning, floating-point convolution, and depth rendering, and 1.4 FPS for CNN ship detection on 1MPixel images. The FPGA fabric usage for the interface is under 1 percent, leaving room for additional functions such as compression, FIR filtering, or corner detection, whose resource use is also reported. The paper further shows that pipelining I/O and processing via masked I/O helps only computation-heavy benchmarks, while lightweight kernels lose throughput due to frame buffering overhead.

Load-bearing premise

The CNN ship detector's on-board accuracy is untested: the 96.8% figure was measured on 128x128 RGB training images, not on the 64-patch, 16-bit floating-point 1024x1024 deployment that produced the 1.4 FPS result.

Editorial extensions

If this is right

If the architecture holds up in flight-like conditions, space payload data handling can offload DSP/AI to a ~1 W VPU while the FPGA remains free for instrument I/O and trusted heritage functions.
The error-free 48 FPS 1MPixel CIF/LCD transfer rate means the I/O channel is not the bottleneck for the reported 6-20 FPS kernel throughputs.
The low FPGA resource footprint (<1% for the interface, single-digit percentages for compression and DSP kernels) suggests the same board can host multiple algorithmic pipelines without dynamic reconfiguration.
The masked-I/O results imply a simple design rule: pipeline I/O only when processing time dominates the frame copy time, otherwise serial processing is faster.
The 1.4 FPS CNN rate, combined with the 96.8% reported training accuracy, indicates that a COTS VPU could support onboard ship detection and similar EO classification tasks, assuming the deployed accuracy is verified.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

An unstated but natural next experiment is to measure the deployed CNN's detection accuracy on full-resolution 1024x1024 images; without that measurement, the reported 1.4 FPS is a throughput number not tied to a demonstrated detection quality.
The architecture could generalize beyond framing and EO to other streaming instruments, e.g., hyperspectral imagers, by reusing the same CIF/LCD channel with wider pixel formats or multiple VPUs, though the paper only reports 24-bit RGB support.
Since the platform includes three VPUs for fault tolerance, a natural extension is to test how throughput and error detection behave when one VPU fails or when the same frame is redundantly processed by multiple VPUs.
The comparison with FPGA and GPU implementations suggests that a developer could choose the VPU when runtime programmability and multi-algorithm storage matter more than peak FPS/W, which is an engineering trade-off the paper states only indirectly.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

You can read this as a solid engineering data point rather than a breakthrough. What's actually new: the paper implements and measures a CIF/LCD interconnect between a Kintex FPGA and a Myriad2 VPU, on a testbed and on the HPCB platform. The headline numbers are concrete—48 FPS for 1MPixel transfers at 50 MHz with zero errors, 6–20 FPS for binning/convolution/rendering, >1 FPS for a CNN, and <1% FPGA resource use for the interface. The authors are careful to give component times in Table II, and the unmasked I/O throughput numbers follow directly from those measured times via the stated formulas. No fitted parameters, no circular derivation. That's honest work, and it extends their earlier Myriad2 VBN study with genuinely new interface controllers and a broader benchmark set.

The soft spots are real but not fatal. The most important one is the CNN claim. They train a 6-layer ship detector on 128x128 RGB images, report 96.8% classification accuracy in training, then convert weights and inputs to 16-bit FP, split each 1024x1024 image into 64 non-overlapping patches, and run inference. No detection accuracy is reported for that deployed configuration. The >1 FPS number is therefore a throughput figure with an unknown detection quality. The paper should either validate the deployed pipeline's accuracy on representative full-size images or qualify the claim to say 'throughput without demonstrated detection performance.' This matters because the abstract's 'deep AI image classification' wording implies a usable capability.

The second issue is the 'expected' two-orders-of-magnitude speedup for the CNN relative to LEON. That's not measured; it's an extrapolation from convolution performance. Hard to reproduce, and it shouldn't be presented as a result. Third, the Masked I/O formulas include buffering parameters (CIF Buff. Time, LCD Buff. Time) that are never defined numerically, so those throughput numbers are hard to reproduce. No error bars or repeated-measurement statistics either, but for a lab prototype and standard hardware benchmarking, that's common and not disqualifying.

In proportion: the primary measured FPS results and the interface validation hold up. The soft spots affect the extrapolated and comparative claims, not the core measurements. The paper is a useful feasibility report for anyone designing on-board processing systems with COTS components. I'd bring it to a reading group only if the group is specifically interested in FPGA/VPU heterogeneous architectures; otherwise it's a data point.

For peer review: I'd send it to a serious referee because the measured results on a specific interconnect implementation deserve an archival record. But the CNN accuracy gap needs to be closed before the AI claim is usable. Treat the paper as a good starting point, not a finished mission-ready design.

Referee Report

3 major / 6 minor

Summary. The paper describes a proof-of-concept heterogeneous FPGA+VPU co-processing architecture for space on-board processing, in which a Kintex/Virtex FPGA implements CIF and LCD controllers to exchange image data with an Intel Movidius Myriad2 VPU. Custom DSP/AI benchmarks (averaging binning, floating-point convolution, depth rendering, and CNN ship detection) are mapped to the VPU's SHAVE cores. The authors report measured interface throughput of 48 FPS for 1MPixel transfers, 6–20 FPS for small kernels, and 1.4–1.5 FPS for CNN classification, together with FPGA resource utilization and power measurements. They conclude that the architecture is a viable low-power COTS-based option for space payload processing.

Significance. If the reported measurements are reliable, the paper provides a useful engineering data point for low-power heterogeneous processing in space, and the CIF/LCD interface integration between an FPGA and a VPU is a non-trivial contribution. The performance numbers in Table II are derived directly from measured component times via transparent formulas rather than from a fitted model, and the FPGA resource utilization is documented clearly. The main significance is limited by three gaps: the deployed CNN configuration has no accuracy validation, the claimed order-of-magnitude CNN speedup over LEON is an extrapolation rather than a measurement, and the masked-I/O results are not fully reproducible from the stated formulas. The 48 FPS one-way interface transfer result is the most defensible claim in the paper.

major comments (3)

[III-C and Table II] The CNN ship-detection benchmark is converted from 32-bit floating point to 16-bit floating point and is run as 64 non-overlapping 128x128 patches on 1024x1024 images, but no accuracy of this deployed configuration is reported. The only accuracy given (96.8%) is for training on 128x128 images with the original precision. Since the abstract and conclusion claim “more than 1 FPS for deep AI image classification,” this throughput number is not tied to any demonstrated detection capability. Patch-boundary effects, the lack of overlap or non-maximum suppression, and the effect of 16-bit quantization on detection quality all remain unexamined. Please report end-to-end detection metrics on representative 1024x1024 images, or qualify the claim as raw throughput without validated accuracy.
[IV, CNN speedup paragraph] The statement that the CNN speedup over the LEON processor is “expected to be more than 2 orders of magnitude” is explicitly an extrapolation based on convolution performance, not a measured result. No LEON execution time for the CNN is reported. The conclusion then states as fact that CNN was accelerated by 1–2 orders of magnitude versus the LEON4 CPU. This is unsupported by the data. The extrapolation should be removed or clearly labeled as an estimate, and the conclusion should claim only the measured speedups.
[Table II, footnote 2 (Masked I/O formulas)] The masked-I/O latency and throughput formulas depend on “CIF Buff. Time” and “LCD Buff. Time,” which are never defined or tabulated, and the relationship between these quantities and the “copying an 1MPixel frame requires ∼42ms” statement is unclear. Using the stated CIF/VPU/LCD times and plausible buffering times derived from that statement, I could not reproduce the reported 906ms masked latency for Averaging Binning. Please define all buffering times explicitly, list their values per benchmark, and show one worked example, or report the masked-I/O latencies and throughputs directly.

minor comments (6)

[IV, paragraph 1] The word “trasmitted” should be “transmitted.”
[V, Conclusion] “DPS/AI” should read “DSP/AI.”
[Fig. 1] The labels “M” and “CM” in the architecture diagram are not explained in the caption or text; please define them.
[IV, performance evaluation] All throughput and latency numbers are reported as single values without stating the number of repeated trials or the observed variance; please state the measurement methodology or add error bars.
[Abstract and Section IV] The “48 FPS for 1MPixel image transfers” claim corresponds to one-way CIF transfer time (1/20.9ms); please clarify in the abstract or text that this is a one-way rate, since a bidirectional round trip would be roughly half that rate.
[Table II, CNN row] The CIF input time for the CNN is 63ms for “1MP RGB/64×1, 16bpp,” which is three times the 21ms used for 1MP 8-bit images; please specify the pixel format and bit width per channel so the reader can verify this timing.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: all throughput, I/O, and power results are measured or directly computed from measured component times via stated formulas.

full rationale

This paper is an experimental evaluation, not a derivation. Every throughput, latency, FPS, and power value is either directly measured on the FPGA/VPU testbed or computed from measured component times using the explicit formulas in Table II (e.g., Unmasked I/O Throughput = 1/(CIF Time + VPU Time + LCD Time)). There are no fitted parameters, no model-based predictions, and no theoretical claims that reduce to their own inputs by construction. The CNN ship-detection benchmark's 96.8% accuracy is cited from an external Kaggle dataset reference [15], not from this paper's own fit, and although the paper does not validate accuracy after 16-bit conversion and 64-patch deployment, that is a missing validation and a correctness risk, not circularity. Self-citations such as [1], [2], [3], and [17] are used for background, related work, and benchmark comparisons; they do not carry any load-bearing argument that substitutes for the paper's own measurements. The CCSDS-123 resource utilization note in Table I is explicitly marked as extrapolated from a cited prior implementation, but it is a peripheral FPGA-remaining-capacity illustration rather than a central claim. Therefore, the paper's central claims are self-contained against external benchmarks and do not exhibit circular reasoning.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

This is an experimental engineering paper with no derived physical constants and no new entities. The ledger captures the domain assumptions about interface reliability, benchmark validity, CNN deployment correctness, and the pipelining model that the reported performance numbers depend on.

assumptions (4)

domain assumption CIF and LCD parallel bus interfaces operate at 50MHz with zero bit errors between the FPGA and Myriad2 VPU for the frame sizes used in the benchmarks.
Section IV reports successful transmission at 50MHz for 8-bit 2048x2048 and 16-bit 1024x1024 frames, but the paper generalizes this to the full range of tested workloads without reporting per-configuration error counts or margin analysis.
domain assumption The Myriad2 VPU SHAVE cores execute the benchmark kernels correctly, with output validated by comparison to groundtruth on the Host PC.
Section II states the Host PC validates results via groundtruth comparisons, but the paper reports no per-benchmark accuracy or bit-exactness metrics, so correctness is asserted but not quantified.
domain assumption The CNN trained on 128x128 images performs useful ship detection when applied patch-wise to 1024x1024 images in 16-bit floating point.
Section III-C describes dividing the large image into 64 patches and converting weights/inputs to 16-bit FP, but no detection accuracy is measured or referenced for this deployed configuration.
domain assumption The Masked I/O pipelining model accurately predicts throughput when the VPU's LEON core concurrently handles CIF reception, LCD transmission, and DRAM buffering while SHAVE cores process.
Section IV and Table II footnotes present a formula for Masked I/O throughput, but the buffering times are not reported and the concurrency assumptions are not validated with direct measurements.

how reviews work

0 comments

Cite this review

Pith. "Pith review of FPGA & VPU Co-Processing in Space Applications: Development and Testing with DSP/AI Benchmarks." pith.science (2026). https://pith.science/paper/4QUZ5J2E

@misc{pith2026250612968,
  author       = {Pith},
  title        = {Pith review of: FPGA & VPU Co-Processing in Space Applications: Development and Testing with DSP/AI Benchmarks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4QUZ5J2E}},
  note         = {Machine review of arXiv:2506.12968}
}

read the original abstract

The advent of computationally demanding algorithms and high data rate instruments in new space applications pushes the space industry to explore disruptive solutions for on-board data processing. We examine heterogeneous computing architectures involving high-performance and low-power commercial SoCs. The current paper implements an FPGA with VPU co-processing architecture utilizing the CIF & LCD interfaces for I/O data transfers. A Kintex FPGA serves as our framing processor and heritage accelerator, while we offload novel DSP/AI functions to a Myriad2 VPU. We prototype our architecture in the lab to evaluate the interfaces, the FPGA resource utilization, the VPU computational throughput, as well as the entire data handling system's performance, via custom benchmarking.

Figures

Figures reproduced from arXiv: 2506.12968 by the authors.

**Figure 2.** Block diagram of CIF/LCD I/O interface in FPGA. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗

**Figure 3.** Dataflow in VPU: CIF/LCD I/O, memory transactions and processing. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: HPCB platform: (a) FPGA motherboard and (b) VPU mezzanine [11]. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]

**Figure 5.** Figure 5: The corresponding values for the benchmark imple [PITH_FULL_IMAGE:figures/full_fig_p004_5.png]

**Figure 5.** Figure 5: Power consumption of the VPU per benchmark execution. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

17 extracted references · 17 canonical work pages

[1]

High-Performance Vision-Based Navigation on SoC FPGA for Spacecraft Proximity Operations,

G. Lentaris, I. Stratakos, I. Stamoulias, D. Soudris, M. Lourakis, and X. Zabulis, “High-Performance Vision-Based Navigation on SoC FPGA for Spacecraft Proximity Operations,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 30, no. 4, pp. 1188–1202, 2020

work page 2020
[2]

Development and Testing on the European Space-Grade BRA VE FPGAs: Evaluation of NG-Large Using High-Performance DSP Benchmarks,

V . Leon, I. Stamoulias, G. Lentaris, D. Soudris, D. Gonzalez-Arjona, R. Domingo, D. M. Codinachs, and I. Conway, “Development and Testing on the European Space-Grade BRA VE FPGAs: Evaluation of NG-Large Using High-Performance DSP Benchmarks,” IEEE Access , vol. 9, pp. 131 877–131 892, 2021

work page 2021
[3]

Improving Performance-Power-Programmability in Space Avionics with Edge Devices: VBN on Myriad2 SoC,

V . Leon, G. Lentaris, E. Petrongonas, D. Soudris, G. Furano, A. Tavoularis, and D. Moloney, “Improving Performance-Power-Programmability in Space Avionics with Edge Devices: VBN on Myriad2 SoC,” ACM Trans- actions on Embedded Computing Systems (TECS), vol. 20, no. 3, pp. 1–23, 2021

work page 2021
[4]

Onboard Processing with Hybrid and Reconfigurable Computing on Small Satellites,

A. D. George and C. M. Wilson, “Onboard Processing with Hybrid and Reconfigurable Computing on Small Satellites,” Proceedings of the IEEE, vol. 106, no. 3, pp. 458–470, 2018

work page 2018
[5]

System-Level Architecture for Mixed Crit- icality Applications on MPSoC: A Space Application,

S. Esposito and M. Violante, “System-Level Architecture for Mixed Crit- icality Applications on MPSoC: A Space Application,” in IEEE Interna- tional Workshop on Metrology for AeroSpace (MetroAeroSpace), 2017, pp. 479–483

work page 2017
[6]

Towards an Integrated GPU Accelerated SoC as a Flight Computer for Small Satellites,

C. Adams, A. Spain, J. Parker, M. Hevert, J. Roach, and D. Cotten, “Towards an Integrated GPU Accelerated SoC as a Flight Computer for Small Satellites,” in IEEE Aerospace Conference, 2019, pp. 1–7

work page 2019
[7]

Enabling Radiation Tolerant Heterogeneous GPU-based Onboard Data Processing in Space,

F. C. Bruhn, N. Tsog, F. Kunkel, O. Flordal, and I. Troxel, “Enabling Radiation Tolerant Heterogeneous GPU-based Onboard Data Processing in Space,” CEAS Space Journal, vol. 12, pp. 551–564, 2020

work page 2020
[8]

Run-Time Reconfigurable MPSoC- Based On-Board Processor for Vision-Based Space Navigation,

A. P ´erez, A. Rodr´ıguez, A. Otero, D. Gonz´alez-Arjona, A. Jim´enez-Peralo, M. A. Verdugo, and E. De La Torre, “Run-Time Reconfigurable MPSoC- Based On-Board Processor for Vision-Based Space Navigation,” IEEE Access, vol. 8, pp. 59 891–59 905, 2020

work page 2020

Show all 17 references

[9]

Always-on Vision Processing Unit for Mobile Applications,

B. Barry, C. Brick, F. Connor, D. Donohoe, D. Moloney, R. Richmond, M. O’Riordan, and V . Toma, “Always-on Vision Processing Unit for Mobile Applications,” IEEE Micro, vol. 35, no. 2, pp. 56–66, 2015

2015
[10]

GAP-8: A RISC-V SoC for AI at the Edge of the IoT,

E. Flamand, D. Rossi, F. Conti, I. Loi, A. Pullini, F. Rotenberg, and L. Benini, “GAP-8: A RISC-V SoC for AI at the Edge of the IoT,” inIEEE International Conference on Application-specific Systems, Architectures and Processors (ASAP), 2018, pp. 1–4

2018
[11]

High-Performance Compute Board – A Fault-Tolerant Module for On-Board Vision Processing,

J. E. Navarro, A. Samuelsson, H. Gingsj ¨o, J. Barendt, A. Dunne, L. Buck- ley, D. Reisis, A. Kyriakos, E.-A. Papatheofanous, C. Bezaitis, P. Matthijs, J. P. Ramos, and D. Steenari, “High-Performance Compute Board – A Fault-Tolerant Module for On-Board Vision Processing,” in E...

2021
[12]

[Online]

Xilinx, Kintex UltraScale FPGA Family , (accessed July 2021). [Online]. Available: https://www.xilinx.com/products/silicon-devices/ fpga/kintex-ultrascale.html

2021
[13]

[Online]

Intel Movidius, Myriad2 Vision Processing Unit (VPU) , (accessed July 2021). [Online]. Available: https://newsroom.intel.com/wp-content/ uploads/sites/11/2017/06/Myriad-2-VPU-Fact-Sheet.pdf

2021
[14]

[Online]

Cobham Gaisler, GR716 – LEON3FT Microcontroller , (accessed July 2021). [Online]. Available: https://www.gaisler.com/index.php/products/ components/gr716

2021
[15]

March 2021)

Kaggle, Ships in Satellite Imagery , 2018 (acces. March 2021). [Online]. Available: https://www.kaggle.com/rhammell/ships-in-satellite-imagery

2018
[16]

High- Performance COTS FPGA SoC for Parallel Hyperspectral Image Com- pression with CCSDS-123.0-B-1,

A. Tsigkanos, N. Kranitis, D. Theodoropoulos, and A. Paschalis, “High- Performance COTS FPGA SoC for Parallel Hyperspectral Image Com- pression with CCSDS-123.0-B-1,”IEEE Transactions on Very Large Scale Integration (VLSI) Systems, vol. 28, no. 11, pp. 2397–2409, 2020

2020
[17]

Combining Arithmetic Approximation Techniques for Improved CNN Circuit Design,

G. Lentaris, G. Chatzitsompanis, V . Leon, K. Pekmestzi, and D. Soudris, “Combining Arithmetic Approximation Techniques for Improved CNN Circuit Design,” inIEEE International Conference on Electronics, Circuits and Systems (ICECS), 2020, pp. 1–4

2020

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

High-Performance Vision-Based Navigation on SoC FPGA for Spacecraft Proximity Operations,

G. Lentaris, I. Stratakos, I. Stamoulias, D. Soudris, M. Lourakis, and X. Zabulis, “High-Performance Vision-Based Navigation on SoC FPGA for Spacecraft Proximity Operations,” IEEE Transactions on Circuits and Systems for Video Technology, vol. 30, no. 4, pp. 1188–1202, 2020

work page 2020

[2] [2]

Development and Testing on the European Space-Grade BRA VE FPGAs: Evaluation of NG-Large Using High-Performance DSP Benchmarks,

V . Leon, I. Stamoulias, G. Lentaris, D. Soudris, D. Gonzalez-Arjona, R. Domingo, D. M. Codinachs, and I. Conway, “Development and Testing on the European Space-Grade BRA VE FPGAs: Evaluation of NG-Large Using High-Performance DSP Benchmarks,” IEEE Access , vol. 9, pp. 131 877–131 892, 2021

work page 2021

[3] [3]

Improving Performance-Power-Programmability in Space Avionics with Edge Devices: VBN on Myriad2 SoC,

V . Leon, G. Lentaris, E. Petrongonas, D. Soudris, G. Furano, A. Tavoularis, and D. Moloney, “Improving Performance-Power-Programmability in Space Avionics with Edge Devices: VBN on Myriad2 SoC,” ACM Trans- actions on Embedded Computing Systems (TECS), vol. 20, no. 3, pp. 1–23, 2021

work page 2021

[4] [4]

Onboard Processing with Hybrid and Reconfigurable Computing on Small Satellites,

A. D. George and C. M. Wilson, “Onboard Processing with Hybrid and Reconfigurable Computing on Small Satellites,” Proceedings of the IEEE, vol. 106, no. 3, pp. 458–470, 2018

work page 2018

[5] [5]

System-Level Architecture for Mixed Crit- icality Applications on MPSoC: A Space Application,

S. Esposito and M. Violante, “System-Level Architecture for Mixed Crit- icality Applications on MPSoC: A Space Application,” in IEEE Interna- tional Workshop on Metrology for AeroSpace (MetroAeroSpace), 2017, pp. 479–483

work page 2017

[6] [6]

Towards an Integrated GPU Accelerated SoC as a Flight Computer for Small Satellites,

C. Adams, A. Spain, J. Parker, M. Hevert, J. Roach, and D. Cotten, “Towards an Integrated GPU Accelerated SoC as a Flight Computer for Small Satellites,” in IEEE Aerospace Conference, 2019, pp. 1–7

work page 2019

[7] [7]

Enabling Radiation Tolerant Heterogeneous GPU-based Onboard Data Processing in Space,

F. C. Bruhn, N. Tsog, F. Kunkel, O. Flordal, and I. Troxel, “Enabling Radiation Tolerant Heterogeneous GPU-based Onboard Data Processing in Space,” CEAS Space Journal, vol. 12, pp. 551–564, 2020

work page 2020

[8] [8]

Run-Time Reconfigurable MPSoC- Based On-Board Processor for Vision-Based Space Navigation,

A. P ´erez, A. Rodr´ıguez, A. Otero, D. Gonz´alez-Arjona, A. Jim´enez-Peralo, M. A. Verdugo, and E. De La Torre, “Run-Time Reconfigurable MPSoC- Based On-Board Processor for Vision-Based Space Navigation,” IEEE Access, vol. 8, pp. 59 891–59 905, 2020

work page 2020