Sept 10 Update (11:23PM)
1. Write back arbitration priority was not specified in the lab handout.
   reply gets the highest priority, then request, followed by writeback.
2. On page 4 of the handout, we are making the following change:
   L1 Hit (L1 hit latency cycles) -> L1 Hit (0 cycle)
3. Throughout the lab, I will be using the value 0 for "L1 hit latency" in all configuration files.
4. All hit latencies in caches are zero.
5. LRU bits are updated on access. For example, for an L1 hit/miss, it is
updated instantaneously.

Sept 11 Update (2:09PM)
1. You evict a cacheline when a conflicting access to the same cacheline is made, not on a fill.

Sept 14 Update (10:34PM)
1. In the multicore case, <trace-file 0> means a trace file for CPU 0 and
<trace-file N-1> means a trace file for CPU N-1. 

Sept 15 Update (2:15PM)
1. The trace file for sample 1 is updated. What changed was the cycle number.
I accidentally had two outstanding requests to the same data. 

Sept 16 Update (5:28PM)
1. If you are evicting a cacheline in L1 that is not in L2, just kick out whatever is in L2 and bring the data into both L1 and L2. In case of a write back to L2 where the data is not resident, kick out the cacheline that is already present there, bring in a new data from main memory, and write to this newly brought in cacheline.

Sept 18 Update (12:07AM)
1. Let's assume that there is dirty data A and B in L1 and L2 cache consecutively, and data C evicts A in L2. A, B and C happen to map to the same cacheline. Then, write back data A to main memory and bring in C into both L1 and L2. The final state will be data C in both L1 and L2.
2. I will make a change to Sept 16's note. If you are writing back to L2 where teh data is not resident, just write back to memory. If data C is one that caused this eviction, just bring in data C into both L1 and L2.