## 3 Technology Background
### Fun
\begin{table}
\begin{tabular}{c c c c c c c} \hline \hline \multirow{2}{*}{**Image**} & \multirow{2}{*}{**Endmembers**} & \multicolumn{5}{c}{**Mean Spectral Angle (\({}^{\rm o}\))**} \\ \cline{3-6}  & & & **FUN** & **Reduction-Based FUN** & **VCA [44]** & **NMF [44]** & **DgS-NMF [44]** \\ \hline Samson & 3 & 3.7004 & 2.6444 & 4.8301 & 5.1337 & 2.8934 \\ Jasper Ridge & 4 & 7.5999 & 7.0384 & 19.8759 & 10.1069 & 3.0997 \\ Urban & 4 & 4.4637 & 7.6292 & 23.2564 & 10.8633 & 4.8988 \\ Cuprite & 12 & 5.9887 & 5.637 & – & 7.5401 & 5.9931 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Endmember extraction accuracy (real hyperspectral images with known endmembers). ### Hardware Tradeoffs

The reduction process detailed in Algorithm 3 has a sequential component (i.e., dimensional reduction) and a data-parallel section (i.e., endmember extraction for each subimage, Lines 5 to 8), which has been selected as the functionality to be moved to hardware. As a consequence of this decision, the transparent scalability provided by the ARTICo3 architecture, and enabled by the use of a configurable number of hardware accelerators, can be used to dynamically adapt the loop unrolling depth during application execution. While the ARTICo3 toolchain supports both HDL and C/C++ descriptions of the kernels, only the HLS-based entry point has been used to implement the FUN endmember extraction, since a C-based version of the whole linear unmixing chain was already available (i.e., the one used during the initial application profiling stage). As stated in the previous section, low-level FPGA limitations make it mandatory to develop resource-constrained, yet performance-oriented, hardware accelerators. In the following, two different HLS-based solutions are analyzed taking into account their execution latency and resource utilization. Both solutions have been implemented using Vivado HLS with the configuration parameters shown in Table 5.

The first solution uses single-precision (i.e., 32-bit) floating-point arithmetic, and relies on tool-based automatic optimizations (mainly, datapath pipelining). The second solution, on the other hand, uses half-precision (i.e., 16-bit) floating-point arithmetic, and relies on tool-based automatic optimizations to improve performance (datapath pipelining) as well as on user-driven code optimization techniques to improve the performance/area ratio (manual loop unrolling). Experimental results showed no functional difference between both solutions when processing normalized input subimages (i.e., whose pixel values range from 0 to 1), since the same endmembers were obtained as output. Table 6 shows the accelerator latency bounds for both solutions. It is important to highlight that the latency of the accelerator is data-dependent (although it will always be between the reported bounds), since the algorithm contains a loop whose trip count depends on the number of pixels with relevant information. Hence, the results shown in Table 6 refer either to an execution that finds one endmember (minimum value) or to an execution that finds _pixels_, _e_ndmembers (maximum value). Table 7, on the other hand, shows the resource-utilization reports. Note that these reports include: combinational logic expressed as Look-Up Tables (LUTs); sequential logic expressed as Flip-Flops (FFs); dedicated logic for arithmetic operations, expressed as Digital Signal Processing blocks (DSPs); and memory elements, expressed as Block RAM (BRAMs). When comparing both alternatives, it is possible to see that the combination of half-precision floating-point arithmetic and manual loop unrolling reduces the memory footprint, but increases the rest of the resources. However, both implementations can fit in regular ARTICo3 slots, and the slightly superior resource utilization of the half-precision implementation is an affordable cost given the performance increase that can be achieved (roughly speaking, 2\(\times\) resources generate 4\(\times\) performance).