# Throughput/Area Optimized Architecture for Elliptic-Curve Diffie-Hellman Protocol
## 3 Proposed ECDH Architecture
### Dedicated FSM Controllers
#### 3.5.1 Controller-1  
It is responsible for generating control signals for \(M_{1}\) and \(M_{2}\) routing multiplexers. The generated control signals are shown with the red color dotted lines in Figure 3. The inputs/outputs to/from _Controller-1_ are also shown in Figure 3. One of the input to _Controller-1_ is \(d\) which is an \(m\)-bit secret key or a scalar multiplier, given in Algorithm 1. Similarly, two other inputs, i.e., \(Q_{xp}\), and \(Q_{yp}\), hold the \(x\) and \(y\) coordinates for a public key of another party during the shared key generation. An \(start\) signal triggers the processor to initiate the computation process. The \(R_{xp}\) and \(R_{yp}\) provide \(x\) and \(y\) coordinates respectively. In addition to it, the \(D_{1}\) and \(D_{2}\) are one-bit done signals. The \(D_{1}\) reveals that the public key is generated while the \(D_{2}\) shows that the shared key is generated. The corresponding \(D_{1}\) and \(D_{2}\) signals are generated after the required computation by _Controller-2_. As shown in Figure 4, _Controller-1_ incorporates a total of four states, i.e., \(IDLE\), \(PBKG\), \(SKG\) and \(WAIT\). As the name implies, \(PBKG\) determines the public key generation while \(SKG\) means the shared key generation. Consequently, descriptions of these states are as follows:  
1. State one is an \(IDLE\) state. Based on the _selector_ signal (not shown in Figure 3), the processor shifts from \(IDLE\) state to either in \(PBKG\) or \(SKG\). Otherwise, the processor remains in the \(IDLE\) state.
2. In the \(PBKG\) state, the processor checks the \(start\) signal. Once it becomes true, the _Controller-1_ generates the control signals to select \(xp\) and \(yp\) coordinates of initial point \(P\).
3. Similarly, the processor checks the \(start\) signal in state three (\(SKG\)). Once it becomes true, it generates the control signals to choose \(xp\) and \(yp\) coordinates of a public key \(Q\).
4. After generating control signals either in-state \(PBKG\) or \(SKG\), the next state becomes state four (\(WAIT\)). The \(WAIT\) state determines that the processor is now waiting for the done signals (either for \(D_{1}\) or \(D_{2}\)) from _Controller-2_. Whenever the processor switches its state from \(PBKG\) to \(WAIT\), it implies that the processor is generating coordinates for a public key. Whenever the processor changes its state from \(SKG\) to \(WAIT\), it denotes that the processor is computing coordinates for a shared key. It is important to note that the transformation, either from \(PBKG\) to \(WAIT\) or from \(SKG\) to \(WAIT\), the proposed architecture consumes one clock cycle. The clock cycles for the \(WAIT\) state depends on the required cycles for _Controller-2_ to set the \(D_{1}\) or \(D_{2}\) signals. Therefore, Equation (1) provides the total number of clock cycles for our ECDH architecture. \[\text{ECDH}_{\text{cycles}}\;=\;2\;+\;2(\text{PM}_{\text{cycles}})\] (1)  
In Equation (1), one clock cycle is required for transformation from \(IDLE\) state to either in \(PBKG\) or \(SKG\). Another clock cycle is needed for shifting either from \(PBKG\) or \(SKG\) to the \(WAIT\) state. The clock cycles calculation for \(\text{PM}_{\text{cycles}}\) will be discussed briefly in the next section.  
Figure 4: FSM controller of our proposed ECDH accelerator architecture.