# Hard SyDR: A Benchmarking Environment for Global Navigation Satellite System Algorithms +
## 5 Results of the Current Hard SyDR Implementation
### Results of the Acquisition Stage  
As detailed in Section 4, we encountered significant challenges in porting the acquisition step to the FPGA, which forced us to use AMD's FFT IP block in the PCPS algorithm. However, this version of the FFT constrains its input signals to have a length equal to a power of 2 [44], as it implements the famous _Cooley-Tukey_ algorithm [46]. This implies a need for padding shorter signals, often accomplished with zeros, to the next power of 2 [47]. In our case, using a 10 MHz sampling rate leads to 10,000 samples per millisecond of data. As the next power of 2 is 16,384, these samples must be padded with 6384 zeros to obtain a sufficiently long signal. In our implementation, these zeros are appended to the end of the original signal. We present results of the three different FFT implementations mentioned so far in Figure 8: the numpy FFT, the PocketFFT, and the AMD FFT IP, with and without zero-padding. These results were obtained using the Python SyDR implementation and simulations in the Vitis HLS software. We configure the AMD FFT IP block to use floating-point data and the following parameters: ordering_opt=natural_order, rounding_opt=convergent_rounding, arch_opt=radix_2_burst_io, has_nfft=true, and phase_factor_width=24. The notion of a code \"chip\" in this case is equivalent to the length of one bit in the Pseudo-Random Noise (PRN) code. The results show correct correlation results in both code phase and Doppler estimation. However, zero-padding clearly leads to significantly wider peaks in the frequency domain, which can be explained by the substantial number of zeros needed to reach the 16,384 samples, i.e., more than 60% of the original signal length. An evident solution for these effects is to either raise the sampling rate closer to the next power of 2, or to reduce it below a previous power of 2. For example, using a sampling rate of 8 MHz instead of 10 MHz leads to only 8000 samples, less than 8192, per millisecond of data. Nevertheless, the results shown in all three implementations are consistent, thus validating our conversion. Unfortunately, the AMD FFT IP block turned out to be challenging not only because of its input size constraints; concretely, when implemented naively for signals of 16,384 samples, its Block RAM (BRAM) utilization nearly exceeds the maximum available in the chosen FPGA. This utilization is a result of two factors: (1) buffers for single-precision floating-point inputs and outputs and (2) storage for twiddle factors and intermediate results. So far, we have attempted to reduce the utilization in three ways:  
* **Reduced-precision arithmetic:** Our current FFT implementation uses single-precision floating-point data to ensure acceptable acquisition results, as used for Figure 8c. However,  
Figure 7: Simplified flow chart of the Jupyter notebook used to drive the Hard SyDR design. floating-point arithmetic is costly, especially in FPGAs, and may be replaced with fixed-point arithmetic with properly dimensioned formats to induce major resource savings. **S2 Reduced size:** The current FFT implementation is designed for 16,384-point transforms. Yet, as mentioned above, this could be reduced to, for example, 8192-point transforms by using a lower sampling rate, leading to additional resource savings. **S3 Smarter HLS:** Our current PCPS implementation makes three calls to an FFT. A crude HLS flow would synthesize these into each their own FFT module while, in reality, it may be beneficial to trade off vast savings in resource utilization for slightly reduced performance by sharing one FFT or, perhaps, at most two: one forward and one inverse. This, however, requires fine-tuning of our code using with HLS-related pragmas (e.g., allocation: [38]). Additional pragmas, such as bind_storage, array_partition, and array_reshape, might also help make the FFT's buffer utilization more efficient.