# 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 2: _Cont._Comparison to area-optimized PM implementations [12; 13; 15; 16]. In comparison to the Virtex-5 implementation of [12], our accelerator over \(GF(2^{163})\) utilizes more hardware resources in slices as this work aims to optimize both throughput and area at the same time, while in the case of [12], the design premise was only the area optimizations. Another reason is the digit-serial multiplier architecture in the reference design, while we employed a digit-parallel modular multiplier. The comparison to LUTs and clock cycles is impossible as this information is not given in the reference design; see columns five and six in Table 2. The operating frequency for Montgomery and Binary PM algorithms in reference design is 359 and 362 MHz, which are comparatively 1.05 and 1.06 times higher than our Virtex-5 FPGA implementation. On the other hand, our accelerator is 2.05 times faster in circuit frequency against the Frobenius Map implementations of [12]. Even if our design utilizes higher resources and operates on lower circuit frequencies, our accelerator is 14.06, 106.13, and 38.36 times faster (in computation time or latency) as compared to Montgomery, Binary, and Frobenius Map implementations of [12]. For \(GF(2^{163})\), the Virtex-7 implementations of [13] is 2.47 times more resource intensive than our \(GF(2^{163})\) accelerator. In other words, our accelerator is more efficient in hardware resources (i.e., slices and LUTs). The reason is the use of a hybrid Karatsuba modular multiplier in the reference design, while we have utilized a digit-parallel modular multiplier with a digit size of 41 bits. Instead of hardware area, our accelerator is faster in clock cycles, frequency, and latency; see columns six to eight in Table 2.

We consider our Virtex-7 implementation for comparison to Artix-7 accelerators of [15; 16]. In comparison to accelerator of [15] over \(GF(2^{233})\), our accelerator utilizes more resources in slices as the reference design optimizes for specific applications related to wireless-sensor-networks while we consider throughput and area at the same time for implementations. Although our accelerator utilizes higher resources, the clock cycle, frequency, and latency values are much lower than the reference design; we refer readers to follow the sixth, seventh, and eighth columns of Table 2. Specifically, our accelerator is 771.41 times faster in latency than the reference design. The design of [16] over \(GF(2^{163})\) utilizes 8577 LUTs which are comparatively 2.22 times higher than our accelerator architecture (i.e., 3862). Similarly, our accelerator is 20.75, 2.47, and 51.32 times faster in clock cycles, circuit frequency, and latency compared to the accelerator of [16]. Comparison to throughput and area-optimized PM accelerators [17; 18]. A two-stage pipelined accelerator of [17] utilizes 2207, 5120, and 5207 slices for \(GF(2^{163})\), \(GF(2^{233})\), and \(GF(2^{283})\) on the Virtex-7 device; these slices on similar Virtex-7 FPGA are comparatively 1.49, 2.56, and 2.02 times higher than our accelerator for identical binary field lengths. The structural hazards due to pipelining in [17] cause higher clock cycle utilization than our accelerator, shown in column six of Table 2. Column seven in Table 2 confirms the higher circuit frequency due to pipelining in the reference design compared to our architecture. The lower clock cycle utilization in our work causes lower computation time than the reference accelerator. In comparison to another pipelined accelerator of [18] over Virtex-7 FPGA, our design utilizes lower slices and LUTs for all \(GF(2^{163})\) to \(GF(2^{571})\) binary fields, which can be seen in columns four and five of Table 2. Instead of hardware resources, our accelerator is faster in clock cycles and computation time, while the design of [18] is faster in circuit frequency due to a two-stage pipelining method. Comparison to throughput/speed-optimized PM designs [14; 19; 20; 21; 22; 23].