Difference between revisions of "Google Summer of Code"

From gem5
Jump to: navigation, search
Line 3: Line 3:
 
# Parallelize M5
 
# Parallelize M5
 
#* 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.
 
# Crossbar network
 
# Crossbar network
 
# Mesh network
 
# Mesh network
Line 9: Line 10:
 
#* 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
 
#* 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
 
#* Korey has one he did at MIPS, I don't know about it's features, but it's SE only  as well
−
# Fast Simple Core
 
−
#* This largely disregards all the compartmentalization we've done. It touches a lot of things, so the time to start being productive would be high
 
−
# Instruction page decode cache
 
−
#* Kinda goes along with the fast simple core, but i think it's a more manageable task. Clearing it is as simple as looking for flush instructions in sparc and the correct pal trap in alpha
 
 
# SMT
 
# SMT
 
#* Fix O3 bugs/ Fix ROB Units
 
#* Fix O3 bugs/ Fix ROB Units

Revision as of 11:08, 11 March 2008

  1. Build a direct execution CPU model based on the Linux Kernel Virtual Machine
  2. 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.
  3. Crossbar network
  4. Mesh network
  5. Directory Protocol
  6. Real F/S In-order core
    • 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
  7. SMT
    • Fix O3 bugs/ Fix ROB Units
    • It's a huge pile of code to understand before you get anywhere if they get that far
  8. Are there any other benchmarks we want?
    • That they could possible make work?
  9. Devices?
    • Validate the DRAM model?
  10. Sampling/checkpointing/restarting
    • Testing, fixing, etc... Not exactly exciting work
  11. Write a PLI interface to connect Verilog CPUs to the memory system.
  12. Sampling/fast-forwarding techniques (making sure ours works, maybe adding in some new ones)
  13. Different cache models (different replacement policies, etc.; would allow them to do some research into it, maybe get some work done for Lisa)
  14. Different prefetcher models (expand on what Ron has, also can do some research into it)
  15. Flash memory device model? (seems popular nowadays)
Retrieved from "http://daystrom.m5sim.org/wiki/index.php?title=Google_Summer_of_Code&oldid=2323"