Cache Simulator

1. Description

   In this project, you will be designing a cache simulator. The simulator must be able to handle the following characteristics:

   • Sizes: 1024, 2048, 4096, 8192, 16384 bytes
   • Block size: 16 bytes
   • Associativities: Direct Mapped, 2-way, 4-way, 8-way
   • Replacement Policy: LRU, FIFO

   The cache simulator should keep track of misses for each combination of size, associativity, and replacement policy. The input to your program will be a sequence of addresses. For each address, you should simulate a read from the cache. Therefore, given an address you would first check to see if it is contained in the cache. If it isn't, you would increment the number of misses and update the cache using the replacement policies. Assume the size of an address is 32 bits. You are provided with a large file of address traces (1012176 addresses) in order to help test your program. You can download it from HERE (its size is 2,303,772 bytes). Please be sure to unzip it using 'gzip -d trace.gz' after you download it. The addresses are represented in heximal format. A sample address trace looks like the following:

   a0873430

   a0873431

   b1884590

   ...

   The simulator should be written in C++. Make sure that your programs compile and run correctly using the g++ compiler on ``eon''. We will be using this machine to test the programs.

   The simulator should output two tables which contain the miss ratio for each combination of size and associativity. The tables should contain the results for each replacement policy. Output the tables in the following format:

   	1024	2048	4096	8192	16384
   Direct
   2-way
   4-way
   8-way

   In addition to writing the simulator, you are required to write a report summarizing the results for the provided test file. The report should contain an explanation of the miss rates (why they are better for different configuations). If you feel that your results are incorrect, you should explain what the results should be. This will ensure that you will get full credit for the report, even if your results are incorrect. In addition, explain how you implemented the simulator.

   Include in the report the tables that were output from the simulator. Also, include two graphs in the report. Both graphs should contain miss rate on the y-axis and cache size on the x-axis. Plot four different results on each graph, one for each associativity. The first graph should contain the results for the LRU replacement. The second graph should contain the results for the FIFO replacement. The report should be done in Microsoft Word.

   Make sure to turn in all code and the report using online turnin.

2. Testing

   The sample input file used for testing is provided here (gziped, you need to do 'gzip -d trace.gz'). Make sure to use the results of this input in your report. The results should be the following:

   
   

   Table 1: LRU Replacement

   	1024	2048	4096	8192	16384
   1	55.01	42.07	29.30	20.74	13.91
   2	51.58	36.44	23.70	13.98	08.49
   4	48.85	33.97	20.04	11.33	06.37
   8	47.44	32.20	18.63	10.02	05.72

   
   

   
   

   Table 2: FIFO Replacement

   	1024	2048	4096	8192	16384
   1	55.01	42.07	29.30	20.74	13.91
   2	53.31	38.32	25.47	15.37	09.49
   4	51.86	37.07	23.11	13.67	07.86
   8	51.14	35.98	22.40	12.79	07.44

   
   

   It is possible that there are errors in these results. If you get different miss rates, email yluo at cs.ucr.edu and I will update the results. Since the output of the simulator is already given, we will be checking for people who have simply hardcoded the program to output the correct results. If we find anyone doing this, you will receive a zero on this assignment.

3. Note

   The sizes of the caches should be in bytes, not words.

   Make sure you are doing your programs in Linux and testing them on eon. Also, your program should work in the following way:

   executable inputfile

   In other words, the application should take one command line parameter, which is the name of the input file. The program should then output the tables which are described earlier on this page. Also, make sure your program does not take a very long time to finish. This can happen if you read in the input file for each different configuration of the cache. You can greatly reduce the running time by testing all cache configurations at the same time, thus avoiding repeated scans of the input file. If your program takes too long to finish, we might mistake it for being in an infinite loop. If you can't get it to work quickly, at least give some kind of output on the screen to let the user know that it isn't frozen.

   Please read my notes on cache simulator at http://www.cs.ucr.edu/$\sim$yluo/cs161L/labs/cachenote.txt.