# Large Field-Size Throughput/Area Accelerator for Elliptic-Curve Point Multiplication on FPGA
## 2 ECC Background over \(GF(2^{m})\)
The reason is three modular multipliers in the reference design (we used only one in our circuit). Our proposed design is 2.36 (ratio of 319 over 135) times more efficient in operating frequency. The reason is the shorter critical path as compared to the reference design. The comparison of latency and throughput shows that our PM architecture is 1.96 (ratio of 56.50 over 28.73) and 1.96 (ratio of 34.80 over 17.69) times more efficient. Comparison to Virtex-7 implementation: Here, we are comparing only the hardware resources in slices and LUTs of our PM architecture to Virtex-7 implementations of [15; 16; 18; 21]. As you can observe in columns four and five of Table 3, the value of the slices for [18] and LUTs values for [21] are not reported in the reference designs. Thus, our comparison to these implementations on these specific parameters (slices and LUTs) is not possible. However, the FPGA slices comparisons reveal that our PM architecture is 2.28 (ratio of 12,965 over 5683), 1.24 (ratio of 5683 over 4560) and 8.85 (ratio of 50,336 over 5683) times more efficient than [15; 16; 21]. Similarly, the LUTs comparison shows that our PM implementation is 2.68 (ratio of 38,547 over 14,356), 1.13 (ratio of 14,356 over 12,691) and 5.64 (ratio of 80,970 over 14,356) times more efficient than [15; 16; 18]. The reasons are different modular multipliers in the datapaths. For instance, in our PM design, we employed a recursive Karatsuba polynomial multiplication method, while in [16], a digit parallel multiplier with a digit size of 41-bits is incorporated for PM implementation. Moreover, a 143-bit digit serial multiplier is employed in [15] to implement modular multiplication over \(GF(2^{571})\). Thus, different multipliers with different digit lengths result in different slices and LUTs and take different clock cycles for computation. There is always a tradeoff. As shown in column six of Table 3, the comparison to clock cycles is not possible to [15; 18], as the related information is not available in the reference designs. However, our PM design takes 1.34 (ratio of 12,329 over 9165) times lower clock cycles as compared to [16]. On the other hand, our implementation takes 9165 cycles, while the design of [21] takes 3783 cycles. We know this happens due to three multipliers in the datapath of [21], while we have only one modular multiplier in our PM implementation. The comparison to circuit frequency reveals that our PM design is 1.31 (ratio of 361 over 274), 1.44 (ratio of 361 over 250), 1.06 (ratio of 361 over 11) times more efficient compared to [15; 16; 18; 21]. Column eight in Table 3 shows that our proposed PM design requires lower computation time for one PM computation as compared to [15; 16; 21]. However, on the other hand, the PM design of [18] is more efficient in latency as compared to our proposed PM architecture. Similarly, column nine in Table 3 shows that the calculated values of throughput for our proposed PM design are higher compared to [15; 16; 21]. But on the other hand, the PM design of [18] is more efficient in throughput compared to our proposed PM architecture. #### 4.2.2 Comparison to Throughput/Area

In Section 4.2.1, the area and throughput comparison of our proposed PM architecture with state-of-the-art shows that our proposed PM design is more area and throughput efficient as compared to PM implementations of [15; 16; 17; 18; 21]. In the throughput, the PM implementations of [17; 18] are more efficient as compared to our work. Similarly, in the area, the PM architecture of [16] is more efficient as compared to our proposed PM design. Therefore, to make a realistic comparison to the state-of-the-art, we have calculated throughput/area values using Equation (6).