Evict line before calling cache_line_fill

[nkanderson]

When evicting a line, we should send the message(s) to L1 for the eviction prior to issuing the READ message on the bus. As our cache currently functions, it issues the read, then fills the line and handles the victim, if there is one. This takes place in the __processor_access method of the Cache class, in the last branch, which handles a cache line miss in an existing set (this is the only case where an eviction would be possible). The bus op is issued in the MESI controller handle_processor_request method, which returns the correct state for the new line. Then the cache_line_fill method adds the new line with appropriate state to the cache set, and returns a victim line, if there is one (otherwise returns None). The victim line is then handled in handle_victim_line, which also sends the appropriate messages to L1.

What we need to do instead:

• Get a victim line first
  • This will probably entail adding a new method to the cache set class that is separate from any allocation (finding the victim currently takes place in the allocate method on the cache set)
  • This method might still return None, but should ideally return the victim address in addition to the victim_line, if not None (or we should add a helper in the Cache class to compose an address from a tag and set index)
• Compose the victim line address
• Call handle_victim_line - it looks like this method could remain unchanged, but the correct victim line address needs to be passed to it (it's currently being passed the address from the request)
• Call the MESI controller's handle_processor_request method - this should be ok unchanged as well
• Call cache_line_fill
  • This method should be updated to no longer return a victim_line. This change is related to the first change above, where the cache set allocate method is updated to separate allocation from victim line identification.

This issue can be replicated with the trace below (found in src/data/demos/t7.din). The issue occurs in the second-to-last line, where there is a read request to 0x02000002. This results in an eviction of a dirty line, and the L2 messages to L1 include the requested address instead of the address of the evicted line.

1   00000000
1   00200001
1   00400002
1   00600003
1   00800004
1   00A00005
1   00C00006
1   00E00007
1   01000000
1   01200001
1   01400002
1   01600003
1   01800004
1   01A00005
1   01C00006
1   01E00007
1   01000000
9   00000000
0   02000002
9   00000000