# IOb-Cache: A High-Performance Configurable Open-Source Cache
## 3 Results
### Performance  
The cache was evaluated with the Dhrystone [26] benchmark using the cycles per instruction (_CPI_) metric. The cache was initially simulated with different configurations and then tested in a field-programmable gate array (FPGA) device. The simulation results are displayed in Table 1, with the cache connected to an AXI4 RAM. The minimum possible size for 2-level configuration is 48 Bytes, 16 Bytes for each of the three caches. This is the worst possible scenario performance-wise. If the L1 does not have the requested word, neither does the L2. The large delay in between instructions is caused by the high miss rate, causing accesses to the main memory, as well as traffic congestion between the L1 and L2 accesses. Using 2 KB caches, one can see there is no performance difference between the replacement policies in a 2-way set-associative cache. The way selected is the one that was not the most recently used in all cases. It also shows the difference in performance between the  
Figure 11: External Memory: two-level cache system implementation. set-associative and directly mapped cache. Using a set-associative in the L2-Unified cache represents the largest improvement in performance (up to 0.315 CPI). If the three caches only use direct mapping, the performance drops by 25.8%. Using 4 KB caches highlights the differences in performance of the different replacement policies. The PLRUm policy displays the highest performance in all three caches,  
\begin{table}
\begin{tabular}{c c c c c} \hline \hline
**L1-Instr** & **L1-Data** & **L2-Unified** & **Clock Cycles** & **CPI** \\ \hline \multicolumn{5}{c}{**48 B–Minimum size**} \\ \hline
1, 2, 2 & 1, 2, 2 & 1, 2, 2 & 319,580 & 8.066 \\ \hline \multicolumn{5}{c}{**2 KB**} \\ \hline
2 (PLRU), 8, 8 & 2 (PLRU), 8, 8 & 4 (PLRUm), 8, 8 & 162,147 & 4.092 \\ \hline
1, 16, 8 & 1, 16, 8 & 4 (PLRUm), 8, 8 & 174,620 & 4.407 \\ \hline
1, 16, 8 & 1, 16, 8 & 1, 16, 16 & 204,016 & 5.149 \\ \hline \multicolumn{5}{c}{**4 KB**} \\ \hline  
hile the LRU policy gives the worst performance. The reduced size of the L1-Instruction (1 KB), and the firmware instruction loops constitute an environment where replacing the least recently used is not effective, due to low time locality. The PLRU policies lack memory compared to the LRU and are worse at identifying the most recently used line. However, this ends up not being a handicap as there is no time locality to exploit. The L2-Unified is more likely to see a performance improvement with PLRU policies [6; 27]. This results from the fact L2 is accessing different memory blocks (instructions and data) with inherently low time locality. Using 16 KB and 32 KB caches, the size is large enough to fit the program. There is no change in performance between the different replacement policies. Despite the program being 25 KB in size and the L1-Instruction caches 4 KB and 8 KB, respectively, the program is not required to fit entirely in these memories. As the program is executed, the only misses that occur are the initial compulsory misses, followed by capacity misses that replace the previous non-looping instructions. As the caches are big enough to store all recently looping code, conflict misses becoming nonexistent. The real tests in FPGA are run in IOb-SoC [18], using the SSRV [22; 23] multi-issue superscalar RISC-V processor. Despite being multi-issue, the processor was limited to one instruction per clock cycle in the tests, which is the optimal configuration for testing the cache. Connected to the IOb-SoC internal memory (RAM only and no cache), it achieved CPI = 1.02, running for 40445 clock cycles. The cache was implemented following a 2-level cache system: L1-Instruction and L1-Data caches connected to an L2-Unified cache (all implemented with IOb-Cache). The FPGA system was implemented in the XCKU040 FPGA with a frequency of 50 MHz.