Difference between revisions of "Google Summer of Code"
From gem5
| 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 | ||
| − | |||
| − | |||
| − | |||
| − | |||
# SMT | # SMT | ||
#* Fix O3 bugs/ Fix ROB Units | #* Fix O3 bugs/ Fix ROB Units | ||
Revision as of 11:08, 11 March 2008
- 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.
- Crossbar network
- Mesh network
- Directory Protocol
- 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
- 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
- Are there any other benchmarks we want?
- That they could possible make work?
- Devices?
- Validate the DRAM model?
- Sampling/checkpointing/restarting
- Testing, fixing, etc... Not exactly exciting work
- 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)
- Different cache models (different replacement policies, etc.; would allow them to do some research into it, maybe get some work done for Lisa)
- Different prefetcher models (expand on what Ron has, also can do some research into it)
- Flash memory device model? (seems popular nowadays)
