## 6 Experiments
Finally, a performance comparison is made to logic controllers, based on instruction execution. The ICNT column gathers the number of instructions a particular program consists of. For the simplicity of the calculations, it is assumed that each instruction can be executed in a single cycle (this assumption gives the handicap to PLC CPU). The THP column contains the throughput of the controller structure, expressing performance in billions of instructions executed per second. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Program** & **Inputs** & **Outputs** & **dekBDD** & **ABC** & **Synplify** & **Vivado** \\ \hline AGV & 15 & 11 & 11 & 11 & 11 & 11 \\ GRAVEL & 26 & 18 & 18 & 18 & 18 & 18 \\ MIX_BRIX & 22 & 13 & 13 & 13 & 13 & 13 \\ LIFT\_4 & 37 & 18 & 23 & 23 & 24 & 23 \\ LIFT\_8 & 69 & 30 & 50 & 59 & 49 & 50 \\ LIFT\_12 & 101 & 42 & 82 & 98 & 84 & 80 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: LUT blocks utilization for the logic part of the controller and respective mapping tool. The proposed direct hardware implementation of the controllers offers extraordinary computation performance. It should be noted that, opposite to programmatic implementation, there is a constant computation time, independent from the logic conditions of program execution. The number of clock cycles is relatively low. The GRAVEL program requires seven clock cycles to complete computation, due to mutually dependent arithmetic operations. It should be noted that the mapping strategy that allocates arithmetic blocks in separate cycles, as required for computation completion, allows for achieving the maximal clock frequency (above 300 MHz). An interesting observation can be made, in the case of the LIFT_n controller implementation. The controller requires four clock cycles to complete the computation. The growing complexity of the controller (4, 8, and 12) increases the propagation delay, reducing the maximal clock frequency (from 307.0 MHz to 242.8 MHz). It should be noted that the increase in complexity results in increased throughput. This shows a unique property of direct hardware implementation that offers extraordinary computation performance, using massively parallel computations. It should be noted that, in all cases, the maximal clock frequency that can be applied to the FPGA device is significantly greater than 200 MHz. In practical applications, assuming a constant clock frequency of 200 MHz for the controller, the response time is between 10 ns for AGV to 35 ns for GRAVEL (for the considered benchmarks). The comparison with other implementation methods is gathered in Table 3, including program execution times for Simatic S7-319 [43] and LD direct hardware implementation methods. The LD direct implementation methods were divided into the rung-based method (RG column) [8,10] and the rung-based method with optimization [9,12,13,21] (RGO column). The last column (DFG column) holds the results for the developed method. The test programs AGV, GRAVEL, and MIX_BRIX are described using SFC. To be able to synthesize those programs, they were translated to the equivalent LD. The Simatic S7-319 execution time is calculated for the shortest instruction execution time. For all direct hardware-implemented controllers, the clock signal frequency is assumed to 200 MHz (1 T\({}_{\text{CK}}\) = 5 ns). The LD implementation, presented in [9,12,13,21], does not enable the implementation of timers, counters, and functional blocks. Results presented here are based on the experience and estimation of implementing the timer and arithmetic modules (performed by the authors). To summarize, the presented DFG assures an extended synthesis of the control program that offers the best performance. The rung-based method (RG column) offers a performance improvement, in comparison to PLC implementation. Further performance improvement is observed in the rung-based optimized method (column RGO). For the RG and RGO methods, performance is dependent on the program representation using a ladder diagram.