Today we went over associative caching, and looked at how the cache and memory will work in yoru simulation. A handout was provided to follow along with the two-way set-associative cache trace example in class, as well as some alternative organizations that we will go through in class tomorrow. Please remember to bring it back. This will help to make caching concepts concrete, so that you can more easily implement the memory demo for March 2.

The project proposals were handed back with interim grades and comments on places that need improvement. The proposal document is meant to be a complete specification for your architecture that serves to guide the team on its implementation, along with a management plan of who does what and how you manage your code and communication. The interim grade is an indication of how close you are to that goal, and will be replaced by the grade for the final version that is due on February 24. 

This is a necessary process for your team to have worked out so that you can have a clear basis for launching your efforts on the project. Where I have seen teams fail to get their simulators working in the past has mostly been due to jumoing into coding without having clarity about the design of the architecture and how the team will work on it. Don’t think of the proposal as some test of your ability to design an architecture — I asume you’ll learn and make changes along the way — rather, it is a process that is designed to help your team be efficient and to succeed.

Slides are here

Handout is here