Difference between revisions of "Google Summer of Code"
From gem5
					
										
					
					| Line 6: | Line 6: | ||
#* Use the Wisconsin Wind Tunnel as a guide  | #* Use the Wisconsin Wind Tunnel as a guide  | ||
#* This actually isn't as bad as it sounds as all objects schedule their own events and there are limited ways they can interact with other objects in the system.    | #* This actually isn't as bad as it sounds as all objects schedule their own events and there are limited ways they can interact with other objects in the system.    | ||
| − | #   | + | #Memory network models  | 
| − | # Mesh   | + | #* (e.g. Crossbar or Mesh)  | 
# Directory Protocol  | # Directory Protocol  | ||
# Real In-order core model  | # Real In-order core model  | ||
Revision as of 14:23, 11 March 2008
All the ideas listed here will require some familiarity with Python and a good grasp of advanced C++ concepts.
- Build a direct execution CPU model based on the Linux Kernel Virtual Machine
 -  Parallelize M5
- Use the Wisconsin Wind Tunnel as a guide
 - This actually isn't as bad as it sounds as all objects schedule their own events and there are limited ways they can interact with other objects in the system.
 
 - Memory network models
- (e.g. Crossbar or Mesh)
 
 - Directory Protocol
 -  Real In-order core model
- Kevin has one that works to some degree in SE, it doesn't have functional units yet, but it does have variable latency stages and such
 - Korey has one he did at MIPS, I don't know about it's features, but it's SE only as well
 
 - Write a PLI interface to connect Verilog CPUs to the memory system.
 - Sampling/fast-forwarding techniques (making sure ours works, maybe adding in some new ones)
 - Flash memory device model? (seems popular nowadays)