# Vectored-Bloom Filter for IP Address Lookup: Algorithm and Hardware Architectures
## 6 Hardware Implementation  
This section shows the hardware implementation details of our proposed structure. Especially, the _parallel architecture with a single hash table_ shown in Figure 5 has been implemented. The hardware implementation has been carried out with Verilog language using Vivado 2017.4 development tool. Our target device is NetFPGA CML operating at 100 MHz. The size of the VBF is \(m=2N^{\prime}\). The VBF and the hash table implemented with BRAMs are loaded with values obtained from the simulation at the behavior level. Figure 7 shows the hardware test flow. Generally, the input IP addresses should be provided by an external input generator, as shown in Figure 7a. However, in our experiment, the input IP addresses are stored in a BRAM, as shown in Figure 7b, in order to provide the input at the operation rate of the hardware implemented on the FPGA. The input IP addresses are stored in dual-port RAMs and hence the parallel architecture can process two IP addresses in parallel. Since the VBF search block in the basic IP address lookup module has 11 hash indexes obtained from Label (3) and a VBF is implemented with a dual-port RAM, six duplicates of the VBF are required. Since the parallel architecture has two basic IP address lookup modules, the VBF duplication should be doubled again and hence the 12 copies of the VBFs are implemented in total. Table 8 shows the memory requirement in the hardware implementation. The BRAM has 18-Kbit and 36-Kbit blocks and the blocks are automatically allocated for each component. It is shown that a VBF is implemented with a single 18-Kbit block for the 1 k set, with four 36-Kbit blocks for the 5 k set and so on. Since each parallel architecture requires 12 copies of VBFs, the total number of VBFs is multiplied by 12. Similarly, it is shown the number of blocks used to store a hash table and input IP addresses for each routing set. The values in total BRAMs represent the summation of the BRAM in KBytes. The utilization rate of the BRAM is based on the BRAM capacity of 16,020 Kbits. Since each component is allocated in blocks, the memory requirement of a VBF or a hash table in hardware implementation is greater than that in behavior simulation. Table 9 shows resource utilization. _Capacity_ means the amount of available resources and _Used_ means the amount of resources used in our implementation. _Utilization_ represents the ratio between _Used_ and _Capacity_. It is shown that the utilization of the BRAM reaches up to 84.0% for the 30 k set. Figure 7: Test flow of field programmable gate array (FPGA)-based IP address lookup: (a) General case. (b) Our case. Table 10 shows the total on-chip power and the worst negative slack reported in Vivado 2017.4 development tool. Figure 8 graphically shows the resource utilization. Since the utilizations of IO and BUFG do not depend on the sizes of the routing sets, their utilizations are not shown. The utilizations of LUT and FF are almost constant, even when the size of the routing set increases. _BRAM w/o IP_ refers to the BRAM utilization when input IP addresses are not stored in BRAMs, as shown in Figure 7a. In this case, the BRAM utilization reaches up to 66.1%, which is substantially lower than 84.0%. \begin{table}
\begin{tabular}{l c c c c} \hline \hline  & **1 k** & **5 k** & **14 k** & **30 k** \\ \hline Total on chip power (W) & 0.172 & 0.181 & 0.188 & 0.262 \\ Worst negative slack (ns) & 88.51 & 82.35 & 84.30 & 79.56 \\ \hline \hline \end{tabular}
\end{table} 
Table 10: Power consumption and the worst negative slack. Figure 8: Resource utilization.