# Hard SyDR: A Benchmarking Environment for Global Navigation Satellite System Algorithms +
## 5 Results of the Current Hard SyDR Implementation
### Results of the Tracking Stage  
As the tracking stage required fewer changes compared to the acquisition stage, we successfully implemented it on the FPGA board, following the revised design presented in Section 3.2. Since this conversion did not involve any significant changes in the algorithm design (i.e., the same processing functions and data types), the tracking results are exactly the same between the Python, C/C++, and FPGA implementations. Consequently, we do not present these results here but invite the interested reader to consider our previous works for more details [9; 22]. Instead, we evaluate our hardware design using the following KPIs: resource utilization, latency, and power/energy consumption estimates. We first analyze the hardware utilization of our tracking-only Hard SyDR design, listed in Table 3. The design is implemented for a clock frequency of 100 MHz. The utilization numbers include a simple channel manager in charge of maintaining channel states. To examine the results in detail, we break down the numbers to highlight the differences in costs of the involved functions. Notably, with respect to the total available resources on the FPGA, the design consumes only 32.6% of the LUTs, 9.36% of the FFs, 23.5% of the DSPs, and 21.2% of the BRAMs. In other words, despite the FPGA on the KV260 board being an entry-level, hence \"small\", Zynq device with limited resources, it easily accommodates our non-optimized design. From Table 3, we see that the tracking function consumes most of the design's resources. Internally, it relies heavily on double-precision floating-point arithmetic that can be costly to implement in FPGAs as certain operations, such as division and square root, are not mapped to the fabric's DSP slices. Moreover, we notice that the mathematical functions--inverse tangent, sine, and cosine--also are costly in resources. These observations are as \begin{table}
\begin{tabular}{l l l l l l l l l l} \hline \hline
**FFT Size** & **Datatype** & **LUTs** & & **FFs** & & **DSPs** & **BRAMs** & \\ \hline \multirow{2}{*}{**16k**} & float & 20,838 & — & 24,898 & — & 0 & — & 116.5 & — \\ \cline{2-10}  & ap\_fixed\{16,1\} & 19,141 & \((-8.14\%)\) & 23,011 & \((-7.58\%)\) & 0 & (0\%) & 61 & \((-47.6\%)\) \\ \hline \multirow{2}{*}{**8k**} & float & 14,780 & \((-29.1\%)\) & 15,822 & \((-36.5\%)\) & 0 & (0\%) & 49 & \((-57.9\%)\) \\ \cline{2-10}  & ap\_fixed\{16,1\} & 13,780 & \((-33.9\%)\) & 14706 & \((-40.9\%)\) & 0 & (0\%) & 25 & \((-78.5\%)\) \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Post-synthesis resource utilization estimates and parenthesized relative savings of different configurations of the Vitis HLS FFT IP block. expected and highlight the need for a design space exploration around the data types used in tracking algorithms meant for hardware implementation. Next, we investigate the latency of key functions in the design, including data transfers, and provide a breakdown in Table 4. The profiling results show that computing dominates the execution time, indicating a high computation-to-communication ratio and a good use of memory to minimize data movement internally to the FPGA. Note that the data transfer time does not include reading the RF data file. This constitutes a significant part of the overall processing time, but as it is a byproduct of the PYNQ flow, it is irrelevant to our hardware-focused analysis. The computations of the tracking stage dominate the remaining time. Finally, it is possible to measure the power and energy consumption of the complete Zynq chip using the power measurement utility built into the PYNQ flow. While the measurements therefrom include both the PS and the PL, it is possible to isolate the dynamic power consumption of the PL by running two power measurements: first, when the PL is idle, and second, when the PL implements a design and is processing data. While changes in the dynamic power consumption of the PS may disturb these measurements, we assume that the workloads the PS executes during both measurement processes are