# Latency-Aware Accelerator of SIMECK Lightweight Block Cipher
## 4 Implementation Results and Comparisons
### Comparisons
#### 4.3.1 Comparison to Area and Timing Parameters  
_Comparison to SIMECK designs [20; 30; 31]._ Four optimized designs are described in [20] for SIMECK block cipher over the Artix-7 FPGA device. On a similar Artix-7 device, our proposed SIMECK architecture utilizes a bit higher hardware resources in terms of FPGA LUTs and Slices (see columns four and five of Table 3). The reason for higher hardware resources in our architecture is the splitting of data and key lengths into smaller segments. On the other hand, we are succeeding in clock frequency and computational time (latency) for encryption and decryption operations. As compared to their 2-stage pipeline design (see column two), our architecture is 1.29 (ratio of 0.053 with 0.041) times faster in terms of computational time (i.e., latency). For their other optimized implementation techniques, i.e., folded, and DSP-targeted, our architecture is 2.09 (ratio of 0.086 with 0.041) and 2.21 (ratio of 0.091 with 0.041) times faster in terms of computational time. For each encryption and decryption, all their implemented techniques (naive, folded, and DSP-targeted) require 32 clock cycles except the 2-stage pipeline design where they need 16 cycles. The computational cost of our architecture is 16 cycles for one encryption and decryption. On a similar Spartan-3 FPGA, the SIMECK block cipher implementation of [30] utilizes 1.08 (ratio of 140 with 129) times higher Slices as compared to our proposed architecture. In other words, our architecture is more efficient in terms of hardware resources. Furthermore, our design requires only 16 clock cycles for one encryption and decryption while the architecture of [30] requires 44 cycles. Similarly, our design can operate up to a maximum frequency of 198.62 MHz while their architecture can operate on a maximum of 166.61 MHz which is comparatively 1.19 (ratio of 198.62 with 166.61) times lower than in our work. Despite the area, clock cycles, and frequency parameters, our architecture is 3.3 times (ratio of 0.264 with 0.080) more efficient in terms of latency because we are splitting the data and key lengths into smaller segments for computations which reduces the clock cycles and ultimately improves the clock frequency, while in [30], a naive approach without any optimization strategy is considered for implementation. Similarly, on the Spartan-6 FPGA device, our implementation is 1.05 (ratio of 206 with 195) times more efficient (in terms of FPGA Slices) as compared to the Spartan-6 implementation of [30]. Moreover, our design can operate up to a maximum frequency of 268.92 MHz while their architecture can operate on a maximum of 217.65 MHz which is comparatively 1.23 (ratio of 268.92 with 217.65) times lower than in our work. Furthermore, our architecture is 3.42 times (ratio of 0.202 with 0.059) more efficient in terms of latency. The reason is splitting the data and key-lengths into smaller segments for computations in our work which reduces the clock cycles and ultimately improves the clock frequency, while in [30], a naive approach without any optimization strategy is used for implementation. As compared to the Kintex-7 implementation of [31], our SIMECK design is area-efficient in terms of LUTs and Slices (see columns four and five of Table 3). The reason for the lower hardware resource utilization in our work is the use of data and key-blocks of lengths 32 and 64 bits, while in [31], a data block of length 64 bits and key-block of size 128 bits are utilized. Moreover, for one encryption and decryption computation, our architecture takes 16 clock cycles while the design of [31] requires 48 clock cycles. Similarly, our design can operate up to a maximum frequency of 382.25 MHz while the architecture of [31] can operate on a maximum of 172.41 MHz which is comparatively 2.21 (ratio of 382.25 with 172.41) times lower than in our work.