# An FPGA-Oriented Baseband Modulator Architecture for 4G/5G Communication Scenarios
## 4 Results and Discussion
Still, considering Mode 1, our OFDM modulator used less 30% FFs and 13% DSP blocks, while our FBMC used less 39% FFs and 34% DSP blocks than the corresponding designs from [19]. Regarding UFMC, a direct comparison would reveal that our design used more LUTs, RAMs, and BRAMs than the works from [19; 28]. However, a careful analysis of the numerologies is required. The most demanding mode of operation for UFMC in [19] was similar to Mode 1 in our work, except that only one PRB was considered. In our UFMC Mode 1 design, each of the three PRB branches required 2737 LUTs, 2093 FFs, 4 BRAMs, and 6 DSP blocks. Similarly to the OFDM and FBMC cases, it is hard to compare the LUT utilization. Yet, a single PRG branch in our UFMC modulator used 32% FFs and 72% DSP blocks less than the UFMC modulator from [19]. In turn, the UFMC modulator from [28] had a similar numerology to Mode 2 in our work, but considered 25 PRBs processed in a ping-pong buffering/memory fashion. Thus, the architecture consisted of the computational resources required to process one PRB and control structures to allow the continuous processing of several PRBs. The resource consumption per UFMC Mode 2 sub-band in our design was: 3927 LUTs, 3304 FFs, 4 \begin{table}
\begin{tabular}{c c c} \hline \hline
**Resource** & **DFS Overhead** & **DPR Overhead** \\ \hline Slice & 24 (0.18\%) & 424 (3.19\%) \\ LUT & 75 (0.14\%) & 938 (1.76\%) \\ FF & 79 (0.07\%) & 1292 (1.21\%) \\ BRAM & 0 & 1.5 (1.07\%) \\ DSP & 0 & 0 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Post-implementation resource overhead for DFS and DPR. The figures in parenthesis correspond to the percentage of available FPGA resources. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Resource** &
\begin{tabular}{c} **Available** \\ **(xc7z020)** \\ \end{tabular} & **Static Part** & **RP\({}_{1}\)** & **RP\({}_{2}\)** & **RP\({}_{3}\)** & **All RPs** \\ \hline Slice & 13,300 & 4210 (31.7\%) & 1400 & 2400 & 3200 & 7000 (52.6\%) \\ LUT & 53,200 & 10,700 (20.1\%) & 5600 & 9600 & 12,800 & 28,000 (52.6\%) \\ FF & 106,400 & 13,110 (12.3\%) & 11,200 & 19,200 & 25,600 & 56,000 (52.6\%) \\ BRAM & 140 & 7.5 (5.4\%) & 20 & 40 & 30 & 90 (64.3\%) \\ DSP & 220 & 0 & 40 & 80 & 40 & 160 (72.7\%) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Post-implementation resource utilization for the static and reconfigurable system parts. The figures in parenthesis correspond to the percentage of available FPGA resources. BRAMs, and 6 DSP blocks. As stated previously in this section, the higher LUT and FF utilization per PRB in our design was mainly due the shift-and-add operations on the bandpass FIR filter. On the other hand, the DSP block utilization per PRB was around ten-times lower than in [28]. Besides this comparative analysis, the key observation in our architecture is that, although the three RPs jointly reserved 7000 slices, 90 BRAMs, and 160 DSP blocks, the aggregated amount of resources used by all six baseband modulation configurations was 11,322 slices, 99.5 BRAMs, and 106 DSP blocks. In fact, if we added this amount of resources to the static part resources, we would actually exceed the amount of slices available in the xc7z020 by 17%. As not all baseband modulators operated simultaneously, the hardware virtualization enabled by DPR contributed to the increased functional density and resource efficiency of the proposed architecture. Assuming that all three RPs were in use, the currently supported modes of operation allowed for 32 possible combinations to arrange the baseband modulators: 2 RP\({}_{1}\) modes \(\times\) 4 RP\({}_{2}\) modes \(\times\) 4 RP\({}_{3}\) modes. However, this versatility can be augmented by adding new RP configurations for waveforms and mode operations needed in the future, extending the system duty lifetime. This is a clear advantage over the design from [19]: although supporting the same waveforms, it is not easily upgradeable due to its static nature.