# An FPGA-Based Performance Analysis of Hardware Caching Techniques for Blockchain Key-Value Database
## 3 Implemented Caching System
\begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Direct-Mapped** & \
\begin{tabular}{c} **2-Way** \\ **Set-Associative** \\ \end{tabular} &
\begin{tabular}{c} **4-Way** \\ **Set-Associative** \\ \end{tabular} \\ \hline
**Latency when cache hit** & 1 cycle & 1 cycle & 1 cycle \\ \hline
**Latency when cache miss** & 6 cycles & 6 cycles & 6 cycles \\ \hline
**Replacement Policy** & N/A & LRU & LRU \\ \hline
**Write Policy** & Write back & Write back & Write back \\ \hline
**Address width** & 256 bits & 256 bits & 256 bits \\ \hline
**Data width** & 256 bits & 256 bits & 256 bits \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Characteristics of cache systems. Figure 2: Implemented caching system on FPGA NIC for Blockchain. judges a cache miss. When the FPGA NIC is processing data, the accessing onboard DRAM must stop receiving new packets because the processing speed of the FPGA is less than its access latency. For result evaluation, we use one delay cycle to obtain data from the BRAM cache and three delay cycles to obtain data from the server (main memory). Figure 4 shows the basic layout of the proposed caching system. * Packet Forwarding: The FPGA NIC forwards the requesting packet to the server when the cache misses. Upon cache hits, the FPGA NIC creates a new UDP packet whose payload changes to Merkle root by modifying the requesting packet. The TXID, source IP, and MAC address of the requesting packet must modify the packets before forwarding them to the client. The TXID changes to Merkle root in the payload and the source IP and MAC addresses change with destination IP and MAC addresses. The length of replying packets remain equal to that of the requesting packet, which is 74 bytes. processor when the cache is hit. Otherwise, the cache has no data, so it jumps to the next state. * Main Memory read: On cache miss case, the cache controller will jump to this state. The cache controller reads data from the main memory. * Bring Data to Cache: After reading data from the main memory, the controller jumps to this state. The controller writes data to the available location in cache memory. After writing data in the cache, the cache controller will jump to the next state. * Output data: The cache controller will provide data from the cache memory to the processor and jumps to first the state, i.e., request from CPU. Figure 6 shows the flow chart diagram of the cache system. The flow chart diagram shows the detailed working of both the read and the write processes in the proposed system. When there is a write request, the first check is in the cache. If the data are present in the cache, they will not be stored again in the main memory. However, if the data are not present in the cache, it will store data in the main memory and then jump to a request from the CPU to wait for the next incoming request. When it is a read request, it first checks the cache. If the data are present in the cache, it provides output to the processor and waits for a new request from the CPU. On the other hand, if the data are not present in the cache, it fetches data from the main memory to the cache and provides output to the CPU. Figure 5: FSM of cache system for read and write request. Figure 6: Flow chart of cache system.