# An Optimized Flexible Accelerator for Elliptic Curve Point Multiplication over NIST Binary Fields
## 2 Lopez-Dahab Projective Form of ECC over \(GF(2^{m})\)

Table 1: Implementation results of the proposed design (after post-place-and-route level) for binary field on Xilinx Virtex-7 (xc7 vx690t) [27]. than the slices of 283-bit key length; and the slices for 571-bit key length are 0.73 times higher than the slices of 409-bit key length. Therefore, it can be observed that the increase in key length is higher than the corresponding utilized slices of our accelerator architecture. In other words, the calculated average increase in key length, i.e., \(\frac{1.42+0.82+0.69+0.71}{4}\), is 0.91, which is higher than the average increase in slices (which is 0.75 and calculated using \(\frac{0.74+0.77+0.78+0.73}{4}\)). Subsequently, the techniques considered in this work for area optimizations are meaningful and can be utilized in other ECC-related accelerators. In contrast to the hardware resources, the increase in key length also increases the required number of clock cycles, as indicated in the timing results of Table 1. Furthermore, the higher key length decreases the circuit frequency. This is because of a relatively more significant critical path in the computation. The critical path is the longest path that determines the maximum operating frequency of the circuit. As key lengths increase, the critical path becomes longer, significantly reducing clock frequency. To address this issue, our accelerator can utilize pipelining to minimize the critical path, although it may come with some area overhead. Similar pipelining techniques have been employed in ECC accelerators, such as those described in [17; 18]. Column seven of Table 1 shows the increase in latency with the increase in the binary field length. It is important to note that this computation time is for PM operation without the cost of loading I/O parameters to our accelerator. We have already described the clock cycle calculation of our accelerator for loading I/O parameters in Section 3.1. Therefore, the numerical values of the clock cycles for loading I/O parameters over \(GF(2^{163})\), \(GF(2^{233})\), \(GF(2^{283})\), \(GF(2^{409})\), and \(GF(2^{571})\) are 661, 941, 1141, 1645, and 2293. Column six of Table 1 shows the operating frequency, \(>\)300 MHz, for implemented binary field key lengths. The I/O parameters cannot load on our accelerator architecture using higher operating frequencies because we used serial data and address loading strategy. Therefore, for loading I/O parameters, a 5 MHz operating frequency can be used. Hence, on this slower 5 MHz, the computation cost of the proposed accelerator for loading I/O parameters is 132.2, 188.2, 228.2, 329, and 458.6 \(\upmu\)s over \(GF(2^{163})\), \(GF(2^{233})\), \(GF(2^{283})\), \(GF(2^{409})\), and \(GF(2^{571})\). It can be observed that the cost of loading I/O parameters is much higher than the actual computation cost of the PM operation of ECC. This highlights the limitation of our proposed accelerator architecture. ### Comparisons

We have compared our results with existing designs in Table 2. Column one provides the reference number for the design that is going to be compared with the proposed design. The implemented PM algorithm (or) method for PM computation is given in the next column. Subsequently, the information about the target platform is shown in column three. The next two columns (four and five) show the information about consumed resources. The number of clock cycles for one PM computation is provided in column six. The next two columns (seven and eight) provide the frequency and latency for one PM execution. The next two columns (nine and ten) show the values for throughput and throughput over area. The architectural details regarding supported key lengths are given in the last column of the table.