Difference between revisions of "Google Summer of Code"

From gem5
Jump to: navigation, search
Line 1: Line 1:
 +
# Build a direct execution CPU model based on the Linux Kernel Virtual Machine
 +
#*  http://kvm.qumranet.com/kvmwiki
 +
# Parallelize M5
 +
#* Use the Wisconsin Wind Tunnel as a guide
 +
# Crossbar network
 +
# Mesh network
 +
# Directory Protocol
 
# Real F/S In-order core
 
# 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
 
#* 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
Line 6: Line 13:
 
# Instruction page decode cache
 
# 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
 
#* 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
# Directory Protocol
 
#* Not realistic
 
 
# SMT
 
# SMT
 
#* Fix O3 bugs/ Fix ROB Units
 
#* Fix O3 bugs/ Fix ROB Units
 
#* It's a huge pile of code to understand before you get anywhere if they get that far
 
#* It's a huge pile of code to understand before you get anywhere if they get that far
# Parallelize M5
 
#* If only, but not realistic
 
 
# Are there any other benchmarks we want?
 
# Are there any other benchmarks we want?
 
#* That they could possible make work?
 
#* That they could possible make work?

Revision as of 11:48, 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
  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. 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
  8. 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
  9. 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
  10. Are there any other benchmarks we want?
    • That they could possible make work?
  11. Devices?
    • Validate the DRAM model?
  12. Sampling/checkpointing/restarting
    • Testing, fixing, etc... Not exactly exciting work
  13. Write a PLI interface to connect Verilog CPUs to the memory system.
  14. Sampling/fast-forwarding techniques (making sure ours works, maybe adding in some new ones)
  15. Different cache models (different replacement policies, etc.; would allow them to do some research into it, maybe get some work done for Lisa)
  16. Different prefetcher models (expand on what Ron has, also can do some research into it)
  17. Flash memory device model? (seems popular nowadays)