## 4 Results and Comparison
### Comparisons
One reason is the use of a bit-parallel hybrid Karatsuba multiplier in the reference design, whereas we used a bit-serial modular multiplier. Another reason is the use of a separate modular multiplier for polynomial multiplications and a square for polynomial square computations in the reference design. At the same time, we incorporated only one modular multiplier for polynomial multiplications and square computations. Similarly, column seven of Table 2 shows that our design outperforms in frequency compared to the reference PM implementation. On the other hand, using a faster hybrid Karatsuba multiplier in [16] results in lower clock cycles (see column six) as compared to ours, the lower clock cycles achieve lower computation time (see column eight) in [16]. There is always a trade-off. The PM designs for wireless sensor nodes are described in [17; 18], and implementations are carried out on Artix-7 FPGA (see column three of Table 2). We implemented our crypto processor design on Virtex-7 FPGA. The Artix-7 and Virtex-7 devices are built on 28 nm process technology [34]. Therefore, we compared our Virtex-7 implemented results to Artix-7 FPGA reference designs of [17; 18]. Regarding slices, the most efficient area-optimized implementation on 28 nm technology [17] utilizes 442 slices on Artix-7 FPGA, which is comparatively 1.13 (ratio of 442 to 391) times higher than this work, where we implemented the design on Virtex-7 FPGA; the reason is the use of a digit-by-digit modular multiplier in the reference design, whereas we used a bit-serial multiplier. The LUTs comparison is impossible, as the related data are unavailable in the reference design. Comparing the clock cycles and latency, the proposed crypto process is 2.16 (ratio of 1,553,782 to 716,459) and 1.83 (ratio of 8177 to 4450) times more efficient than [17]. However, digit-by-digit multiplication style in [17] results in a higher operating frequency of 190 MHz, whereas our design achieves a maximum of 161 MHz. Even if the reference design operates at a higher clock frequency, overall, our crypto processor outperforms in computation time (or latency). Comparing our results to the Artix-7 implementation of [18] is a bit hard, as the reference design implemented three cryptographic algorithms to simultaneously obtain the advantages of symmetric and PKC. An advance encryption standard (AES-128) algorithm is incorporated to perform the symmetric cryptography; ECC over \(GF(2^{163})\) is utilized to operate elliptic-curves operations for PKC; and a secure hash algorithm (SHA-256) is considered to perform hash computation for digital signature, authentication, and random-keys generation. On the other hand, we have implemented only a Montgomery PM algorithm for the PM computation of ECC. Therefore, column five of Table 2 confirms the higher LUTs utilization in the reference design than our implementation. Slices cannot be compared, as the reference design does not provide this information. In clock cycles and computation time, the reference design is more efficient, but our crypto processor design is faster in clock frequency and consumes less power than the reference design (see columns six to nine in Table 2). Regarding the power comparison, column nine of Table 2 show that most state-of-the-art designs lack discussion over power results, and we show a hyphen symbol in the corresponding column. Therefore, this comparison to our results is impossible.