# Latency-Aware Accelerator of SIMECK Lightweight Block Cipher
## 4 Implementation Results and Comparisons
### Comparisons
#### 4.3.1 Comparison to Area and Timing Parameters
Additionally, our architecture is 6.78 times (ratio of 0.278 with 0.041) more efficient in terms of latency because we are using the 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 is used. _Comparison to other block ciphers [15; 26; 27; 28]._ A SIMON cipher is implemented on Spartan-6 for wireless sensor nodes in [15]. Comparatively, our proposed architecture utilizes more hardware resources in terms of FPGA Slices (see column five of Table 3). The reason is to split the data and key-length blocks into smaller segments for computations in our work. The clock cycles requirement of [15] is 44 while our architecture requiresonly 16 cycles. This is due to the parallel execution of smaller data and key-length blocks in our design. Moreover, our design is 5.37 (ratio of 268.92 with 50) times more efficient in terms of operating frequency as compared to SIMON architecture of [15]. Due to parallel execution of the data and key-length blocks, our design is 14.91 (ratio of 0.880 with 0.059) times more efficient in terms of latency as compared to [15]. An LED cipher for securing wireless sensor nodes is implemented in [28] on Spartan-3 FPGA. In comparison, our proposed architecture is 1.34 (ratio of 274 with 204) times more area-efficient in terms of utilized LUTs, but for Slices, we are consuming more resources due to the split of input data and key-length blocks. Moreover, we are utilizing half clock cycles of 16 as compared to [28] where the cycles requirement is 32. Towards clock frequency comparison, the proposed design is 1.18 (ratio of 198.62 with 167.34) times more efficient. The latency comparison reveals that the proposed design is 2.38 (ratio of 0.191 with 0.080) times faster. The comparison to hardware resources of KLEIN, reported in [26], shows that the proposed design requires 1.85 (ratio of 195 with 105) times more area in terms of FPGA Slices. The logic to use higher resources in this work is the parallel computation of data and key-expansion blocks. As shown in Table 3, the comparison to other parameters is not possible as the corresponding information is not available. As compared to the implementation of the QARMA block cipher of [27] on Kintex-7 FPGA, our design is 8.53 (ratio of 418 with 49) times more area-efficient in terms of FPGA Slices. The reason to use lower hardware resources in our work is the use of 64-bit key length, while in [27], a 128-bit key length is utilized. Moreover, our design is almost 3.82 times faster in terms of clock frequency. Similar to [26], the comparison to other parameters (i.e., clock cycles, latency) is not possible as the relevant information is not reported. It is essential to highlight that the power comparison to the state-of-the-art is not shown in this work mostly because the existing hardware accelerators of many block ciphers result in the area, latency, and throughput parameters without the concern of consumed power. Therefore, we have (already) described the power consumption of our proposed SIMECK32/64 architecture in Table 2 (see Section 4.2).