## 9 Results and Discussion
### Standard and Optimized Methods  
As explained in Section 4, the standard method for I0-correction and the optimized method were implemented in the CT pre-processing core. The two versions, shown in Figures 4 and 5, were implemented with pipelining. In the optimized version, the logarithm operation is pre-calculated because its argument is constant. The algorithm executes only subtraction and multiplication operations. By contrast, the standard method executes an additional power operation and logarithm operations, which are expensive in terms of execution time and resource utilization. To compare and quantify the two methods independently by the data format, we selected the same _image-processing format_ (single-precision floating point), and synthesized both with Vitis(tm) HLS. Furthermore, we analyzed the MSE of the 2D pre-processed projections. The estimated MSE is \(3.21\times 10^{-15}\), which is almost 0. With the reported low MSE, we also validated our solution and we can confirm that the two methods are equivalent, as expected from the mathematical simplification. In fact, both methods generate the same output projections. The MSE is not exactly 0 because the two methods evolve different operations and math co-processors components that approximate the values in different ways. As expected, the two methods differ in terms of hardware performance. The optimized method, as reported in Table 1, does not use any BRAM and requires about 10 times less DSP, FF and LUT resources, the standard method to perform a complex operation, as logarithm and power need to buffer data; for this reason, BRAM is utilized. In addition, these complex operations determine the higher LUT, FF and DSP utilization. FPGAs have a small limited number of DSPs, and therefore, their utilization should be minimized, when it is possible. Moreover, the low required resource utilization for our solution allows to implement and integrate the pre-processing core directly in the DMS, closest to the sensor. Due to the real-time requirements, the most important metric is the execution time/latency. In this case, we analyzed the latency of the single operations for the two methods; the results are also shown in Table 1. The standard method has a latency of 660 ns, while the optimized method has a latency of 160 ns. In the standard method, there are power, division and logarithm operations that are much slower operations than subtraction and multiplication operations. In fact, the optimized method has only one multiplication and one subtraction, which have low latency, as shown in Table 2 and discussed in Section 9.2. For this reason, our solution achieves a speed-up of about \(4.125\times\) compared to the standard method with the same data format. We see that in the optimized method configured with the 32 bit-fixed point data format, we reach a speed-up of about \(16.5\times\) compared to the standard method. This latency enhancement is a significant improvement for the real-time requirements of the interventional CT application. By using the dataflow architecture, both solutions make it possible to pre-process a new pixel each clock cycle. It was not possible to compare the optimized methods with the related works, in terms of hardware implementation, due to the lack of information. \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Precision Name** & **BRAM 18K** & **DSP** & **FF** & **LUT** & **Latency** \\ \hline Standard method (float) & 2 & 30 & 3497 & 6881 & 660 ns \\ Optimized method (float) & 0 & 5 & 527 & 785 & 160 ns \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Hardware report for CT pre-processing core (instance for 1 pixel per clock cycle). \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline
**1 st Stage** & & & & **2 nd Stage** & & & **3 rd Stage** \\ \hline Buffer & Conv. & Mul. & Exp. & Div. & Div. & Log. & Muls & Buffer \\
10 ns & 50 ns & 40 ns & 140 ns & 120 ns & 120 ns & 130 ns & 40 ns & 10 ns \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Timing analysis of the standard method.