## 4 Results and Comparison
### Results  
We have used the Vivado IDE tool to implement our proposed crypto processor design over \(GF(2^{233})\). Moreover, we have implemented a register-transfer-level (RTL)-design in a Verilog HDL. The input parameters, namely the \(x\) and \(y\) coordinates of an initial point \(P\) and the curve constant \(b\), were selected from the NIST recommended document [8]. We developed a reference model of Algorithm 1 using C/C++ programming language. Then, we compared the behavioral and post-place-and-route simulated models, written in Verilog HDL, of Algorithm 1 with the C/C++ reference design to ensure correctness. We summarize the implementation results in Table 1, representing the outcomes obtained after the post-place-and-route stage on Virtex-6 and Virtex-7 FPGA devices. The first column indicates the specific implementation device, whereas columns two to three display area information regarding slices and look-up tables (LUTs). Similarly, columns four to six provide timing results in clock cycles, operating frequency (Freq), and latency. The circuit frequency is measured in megahertz (MHz), whereas latency represents the computation time for one PM execution, which we calculated in microseconds (us). The last column of Table 1 presents the total power consumption of the design, which is the combined static and dynamic power. Furthermore, the area, operating frequency, and power values were obtained from the synthesis tool, ahd we calculated the latency using Equation (3):  
\[\text{Latency}\left(\upmu\text{s}\right)=\frac{\text{Clock cycles}}{\text{ Clock frequency}\left(\text{MHz}\right)}. \tag{3}\]  
The proposed ECC design can operate on a maximum of 129 and 161 MHz on Virtex-6 and Virtex-7 FPGA devices, respectively. These higher frequencies require additional hardware resources and consume more power, making our design inappropriate for WSN and RFID-related applications. The timing constraints were met until these frequencies (129 and 161 MHz), meaning the design has the worst-negative-slack of 0. Therefore, our objective was to obtain an area-optimized ECC implementation on FPGA, and hence in Table 1, we show a trend on Virtex-6 and Virtex-7 FPGA devices for operating frequencies of 100, 50, and 10 MHz. Consequently, this trend reveals that decreased clock frequency increases the computation time or latency. Moreover, the higher frequencies consume more power, as illustrated in the last column of Table 1.  
Considering the results for Virtex-6 and Virtex-7 FPGA devices, the proposed crypto processor utilizes 407 slices and 2442 LUTs on Virtex-6 devices and 391 slices and 2346 LUTs on Virtex-7 FPGA. It takes 716,459 clock cycles for one PM computation. The reason for requiring higher clock cycle utilization is the use of a bit-serial modular multiplier for square, multiplication, and inverse computations. Using separate units for square and inversion reduces clock cycle overhead but significantly increases the amount of hardware resources and also raises the power consumption. Instead of using separate square and inversion blocks, faster modular multiplication methods can be employed, such as bit-parallel (Karatsuba, Toom-Cook), and digit-parallel; these also effect both hardware resources and power consumption of the crypto processor. For Virtex-6 and Virtex7 FPGA devices at 100, 50, and 10 MHz, our crypto processor takes 7.16, 14.32, and 71.64 ms time for one PM computation, but the power consumption is different. For Virtex-6 devices, our crypto processor consumes 73, 39, and 7 mW power on identical 100, 50, and 10 MHz clock frequencies during one PM execution. Similarly, for Virtex-7 FPGA devices at 100, 50, and 10 MHz, our crypto processor consumes 51, 28, and 4 mW power during one PM execution. Notice that the proposed crypto processor outperforms hardware resources and power consumption on modern (28 nm) Virtex-7 FPGA devices.