# A Unified Point Multiplication Architecture of Weierstrass, Edward and Huff Elliptic Curves on FPGA
## 5 Implementation Results and Comparison
### Comparison with the State of the Art
The reported latency is the ratio of clock cycle counts over circuit frequency in Equation (5); thus, we believe the designs of [9; 10] take higher cycle counts compared to our unified design, which is why their architectures require more computational time than the unified design of this work. Comparison with dedicated Edward curve designs of [12; 14; 15; 16]The Edward designs over the prime field with 256-bit length are described in [12; 14]. On Virtex-6 and Virtex-7 FPGA devices, our unified accelerator utilizes lower slices and LUTs, as shown in columns seven and eight of Table 3. This is due to a lower key length of 233 bits implemented in our design, while a 256-bit key length is supported in the reference designs of [12; 14]. The last two columns of Table 3 (columns ten and eleven) reveal that the proposed unified accelerator can operate on a higher circuit frequency and takes a lower computation time than the Edward curve accelerators of [12; 14]. As we stated earlier, our accelerator supports a shorter 233-bit key length than [12; 14], where a 256-bit supported accelerator is implemented--this is the reason for the lower computation time in our accelerator design. Over \(GF(2^{233})\), a dedicated Montgomery-based PM accelerator architecture of the Edward curve is presented in [15]. On Virtex-6 FPGA, their architecture utilizes 4.90 (ratio of 6109 with 1245) times lower slices than our unified accelerator. On the other hand, our accelerator utilizes 207.02 (ratio of 718,805 with 3472) times lower clock cycles. In our design, we use a bit-parallel Karatsuba multiplier for polynomial multiplications, resulting in one multiplication in one clock cycle with an area overhead. On the other hand, a serial multiplication architecture is incorporated in [15] to optimize the hardware resources with clock cycles overhead. There is always a tradeoff between area and performance (clock cycles). The use of serial and parallel multiplication approaches affects the critical path of the PM circuits. More precisely, our accelerator can operate on a maximum of 247 MHz, while the design of [15] can operate on 107 MHz. As shown in the last column of Table 3, the larger clock cycle utilization and lower circuit frequency in [15] result in a longer computation time (latency) compared with our unified accelerator. Another Montgomery-based dedicated PM accelerator of the Edward curve over \(GF(2^{233})\) is described in [16]. If we compare our implementation results on Virtex-7 FPGA, the design of [16] is more area-efficient (in slices), as their design comprises a 32-bit digit parallel multiplier--we employed a bit-parallel Karatsuba multiplier. Moreover, their design takes a lower number of clock cycles of 3244 for one PM computation, while we utilized 3472 cycles. However, our accelerator architecture is 1.64 (ratio of 294 with 179) times faster in circuit frequency. This is due to a shorter critical path delay in our PM architecture, accomplished by an efficient Karatsuba implementation. The higher circuit frequency in our accelerator results in lower computation time (latency), as shown in the last column of Table 3.  
Comparison with dedicated Huff curve designs of [13; 17]On a similar Virtex-7 FPGA device, our unified accelerator takes a higher number of bit slices (7423) as compared to the dedicated Huff designs of [17] (7017) and [13] (7123). The reason is our accelerator's support for three different curves (Weierstrass, Edward, and Huff). Our efficient memory replacements of storage elements and the implementation of the quad block variant of an Itoh-Tsujii inversion algorithm result in lower clock cycles. As you can see in column nine of Table 3, the dedicated designs of [13; 17] take 13,057 and 15,495 cycles, while our accelerator to implement the Huff curve takes only 8913 cycles. Due to four-stage pipelining, the design of [17] has an efficient in-circuit frequency, but for the computation time, our accelerator computes one PM in almost the equivalent time (30.31 \(\upmu\)s) consumed in [17] (30.08 \(\upmu\)s).