# GPU@SAT DevKit: Empowering Edge Computing Development Onboard Satellites in the Space-IoT Era
## 2 Background and Related Work
However, they are mostly suited for event-based applications, such as anomaly detection, where processing is triggered by specific events rather than continuous data streams. In this regard, they may complement traditional ML accelerators rather than replace them across the broader range of space applications. An alternative approach involves using an embedded GPU implemented on FPGA fabric, which could overcome these obstacles. While this solution may not match the efficiency and performance of a custom design, it offers greater flexibility, extensibility, and customization. It can be developed across various silicon technologies and supports parallel computation at the edge of applications. This method allows combining both the high-performance capabilities of a GPU-like architecture and the reduced power consumption of FPGA technology, making it well suited for ML edge applications that require both computational power and low energy consumption. GPU@SAT exemplifies this approach. GPU@SAT is an IP core designed for FPGAs that is coded in VHDL and does not incorporate third-party IP components. The design operates on a 32-bit architecture and follows the Single Instruction Multiple Thread (SIMT) execution model of a theoretical OpenCL device. To date, the level of compatibility remains incomplete, with the current version of the standard being the OpenCL 1.2 specification. Figure 1 depicts the structure of an OpenCL device. In schematic form, such a device comprises a multitude of cores that operate in parallel to execute a program--which is referred to as a _kernel_--for a host processor that drives it. In this context, the OpenCL device can be considered a hardware accelerator that serves the processor for offloading tasks. A kernel is composed of multiple threads, designated as Work-Items (WIs), which run in parallel. To facilitate the division of workload among the cores in the architecture, the WIs are subsequently grouped into larger sets, identified as Work-Groups (WGs) [60]. Similarly, the GPU@SAT IP core is divided into several cores, called Compute Units (CUs), with each core containing up to eight Processing Elements (PEs). In accordance with the standard, the WGs are executed on the cores, while the WIs are run on the PEs. The sole distinction between the architecture and the standard lies in the further subdivision of the WGs into Wavefronts (WFs). Each WF is responsible for managing one Program Counter (PC) for 64 WIs. This approach reduces the number of PCs and the complexity of the hardware without sacrificing full-thread divergence. At each clock cycle, provided that there are no pipeline stalls, each PE executes an instruction for a single WI. The GPU@SAT IP core can be managed by the host processor through an AXI4-Lite bus control interface. It supports the loading of up to 16 OpenCL kernels, accommodating a total of 64 KB of program code. The programmability of the core is enhanced by a comprehensive software ecosystem that includes an LLVM-based compiler. This compiler translates high-level OpenCL code into assembly code executable by the accelerator, enabling high-level programmability. This design allows users to repurpose the hardware without modifying the architecture (only the software needs to be updated, making the accelerator versatile and general-purpose). Moreover, the compiler is fine-tuned to optimize the binary code specifically for the GPU@SAT IP core. This optimization is achieved through a custom LLVM backend that efficiently manages resources, such as registers, to maximize the performance of the accelerator. To execute a kernel, the processor needs two types of information:  
* The OpenCL properties of the kernel (such as the number of Work-Items in the kernel context). * The executable binary code of the kernel itself. These details must be pre-loaded by the processor into a dedicated memory space within the accelerator.