Difference between revisions of "InOrder ToDo List"

From gem5
Jump to: navigation, search
 
(7 intermediate revisions by 2 users not shown)
Line 14: Line 14:
 
** ResourceType/Request options
 
** ResourceType/Request options
  
−
* Multithreading Models?
+
==Resources==
−
** None (single threaded)
+
* Execution Unit
−
** Fine-grained (switch context every cycle or every few cycles, like Ultrasparc T2)
+
** Fold Address Generation Unit (AGEN) into the EXE
−
** Coarse-grained (switch context on thread stalls, like 'SwitchOnCacheMiss' currently)
+
** Pass a Function Unit Pool object to the EXE and specify what functions can operate through a specific unit (similar to O3)
−
** SMT (all contexts active, like 'SMT' currently)
+
 
  
 
==Simulation Speed==
 
==Simulation Speed==
−
* Instruction Schedule Work
+
* Instruction Sleeping
−
** Use Vector of Vectors instead of Priority Queue
+
** Sleep instructions waiting for an long-delay event (instead of constantly ask a resource if it's complete
−
** Identify Instruction Schedule Types (via Tuple)
+
 
−
** Cache Instruction Schedule, Generate On-Demand
+
* Event Sleeping
−
** Instructions walk through schedule by incrementing pointer instead of popping from queue
+
** Sleep CPU w/no activity - Implemented on a coarse-grain level, but Activity object can be tuned to be exact.
−
*** If dynamic schedule is needed, then copy the remaining part of schedule and let the instruction add/remove as it pleases
+
 
−
*** Can we cache dynamic schedules? Is there a better solution here?
+
* Resource Pool
−
* Event-Sleeping Work
+
* Instead of broadcasting all events to the resource pool, have resources declare what functions they have virtual functions for (or auto-detect this) and then only broadcast to the right set of resources every time (e.g. the BranchPredictor may not care about a Trap Event)
−
** Sleep instructions waiting for an long-delay event
 
−
** Sleep CPU w/no activity (partially implemented)
 
  
 
==ISA Support==
 
==ISA Support==
−
*ALPHA - completed
+
*ALPHA - '''completed'''
−
*MIPS - completed
+
*MIPS - '''completed'''
−
*X86 - not completed
+
*SPARC - ''partially completed'' (not currently being developed)
−
*SPARC - not completed
+
*ARM - not completed - ''Support for Micro-Ops Needed (Template code from Simple or O3 CPU?)''
 +
*X86 - not completed - ''Support for Micro-Ops Needed (Template code from Simple or O3 CPU?)''
 +
*POWER - not completed
  
 
==Full System Support ==
 
==Full System Support ==
−
* TBD
+
* InOrder can boot Linux, but testing for benchmark suites
 +
** PARSEC
 +
** SPLASH2
 +
** SPEC2K6
  
 
== Checkpointing ==
 
== Checkpointing ==
−
* TBD
+
* The serialize/unserialize functions are currently unimplemented in InOrder
−
 
 
−
==Regression Tests ==
 
−
TBD
 
  
−
'''*Move some of these to Flyspray?*'''
+
== SwitchOut ==
 +
* Implement the drain function for InOrder

Latest revision as of 06:57, 19 June 2011

Python Configurability

  • Resource Configuration - How can we specify what resources are instantiated via the Python config files?
    • ResourceType - Type of resource (Enum type)
      • ResourceParams - Parameters for this type of resource
      • Request - List of requests for this type of resource (Enum type)
        • Latency - operation latency and issue latency (intra/inter thread)
      • Count - Number of such resource type
  • Pipeline Description
    • InstSchedule - Instruction schedule specified as a vector of InstClassSchedule
      • InstClassSchedule - Vector of schedules per instruction class - load/store, Int execute, FP execute, specialized inst, etc. (do we still want a distinction between front end and back end schedules?)
    • ResourceRequestList - Vector of ResourceRequest (per stage?)
      • ResourceRequest - Vector of requests for resources
    • ResourceType/Request options

Resources

  • Execution Unit
    • Fold Address Generation Unit (AGEN) into the EXE
    • Pass a Function Unit Pool object to the EXE and specify what functions can operate through a specific unit (similar to O3)


Simulation Speed

  • Instruction Sleeping
    • Sleep instructions waiting for an long-delay event (instead of constantly ask a resource if it's complete
  • Event Sleeping
    • Sleep CPU w/no activity - Implemented on a coarse-grain level, but Activity object can be tuned to be exact.
  • Resource Pool
  • Instead of broadcasting all events to the resource pool, have resources declare what functions they have virtual functions for (or auto-detect this) and then only broadcast to the right set of resources every time (e.g. the BranchPredictor may not care about a Trap Event)

ISA Support

  • ALPHA - completed
  • MIPS - completed
  • SPARC - partially completed (not currently being developed)
  • ARM - not completed - Support for Micro-Ops Needed (Template code from Simple or O3 CPU?)
  • X86 - not completed - Support for Micro-Ops Needed (Template code from Simple or O3 CPU?)
  • POWER - not completed

Full System Support

  • InOrder can boot Linux, but testing for benchmark suites
    • PARSEC
    • SPLASH2
    • SPEC2K6

Checkpointing

  • The serialize/unserialize functions are currently unimplemented in InOrder

SwitchOut

  • Implement the drain function for InOrder
Retrieved from "http://daystrom.m5sim.org/wiki/index.php?title=InOrder_ToDo_List&oldid=3794"