Difference between revisions of "InOrder ToDo List"

From gem5
Jump to: navigation, search
(Created page with ''''Python Configurability''' InOrderCPU configuration (uniprocessor options) * MTApproach - Multi-Threading (MT) Approach * Resource - Resource Configuration (will eve…')
 
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
'''Python Configurability'''
+
==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
  
−
InOrderCPU configuration (uniprocessor 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)
  
−
    * MTApproach - Multi-Threading (MT) Approach
 
−
    * Resource - Resource Configuration (will eventually be used to autogenerate C++)
 
  
−
          * ResourceType - Type of resource (Enum type)
+
==Simulation Speed==
−
                * ResourceParams - Parameters for this type of resource
+
* Instruction Sleeping
−
                * Request - List of requests for this type of resource (Enum type)
+
** Sleep instructions waiting for an long-delay event (instead of constantly ask a resource if it's complete
−
                      * Latency - operation latency and issue latency (intra/inter thread)
 
−
                * Count - Number of such resource type
 
  
−
    * PipelineDesc - Pipeline Description
+
* Event Sleeping
 +
** Sleep CPU w/no activity - Implemented on a coarse-grain level, but Activity object can be tuned to be exact.
  
−
          * InstSchedule - Instruction schedule specified as a vector of InstClassSchedule
+
* Resource Pool
−
                * 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?)
+
* 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)
−
                      * ResourceRequestList - Vector of ResourceRequest (per stage, right?
 
−
                            * ResourceRequest - Vector of requests for resources
 
  
−
    * Other params
+
==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
  
−
MTApproach options
+
== Checkpointing ==
 +
* The serialize/unserialize functions are currently unimplemented in InOrder
  
−
    * None (single threaded)
+
== SwitchOut ==
−
    * Fine-grained (switch context every cycle or every few cycles, like Ultrasparc T2)
+
* Implement the drain function for InOrder
−
    * Coarse-grained (switch context on thread stalls, like 'SwitchOnCacheMiss' currently)
 
−
    * SMT (all contexts active, like 'SMT' currently)
 
−
 
 
−
 
 
−
ResourceType/Request options
 
−
 
 
−
    * FetchUnit
 
−
          o AssignNextPC
 
−
          o UpdateTargetPC
 
−
          o SelectThread (for fine-grained and coarse grained MT approaches; may also be done in a separate thread selection unit or pick unit as in Ultrasparc T2)
 
−
          o Any other fetch address generation?
 
−
    * MemPort (DataReadPort, DataWritePort, FetchPort)
 
−
          o Access
 
−
          o InitiateAccess
 
−
          o CompleteAccess
 
−
    * DecodeUnit
 
−
          o DecodeInst
 
−
    * BPredUnit
 
−
          o Predict
 
−
          o Update
 
−
    * UseDefUnit
 
−
          o ReadReg
 
−
          o WriteReg
 
−
    * AgenUnit
 
−
          o GenerateAddr
 
−
    * ExecUnit
 
−
          o Exec
 
−
          o InitiateExec
 
−
          o CompleteExec
 
−
          o GenerateAddr
 
−
    * GradUnit
 
−
          o Graduate
 
−
    * Interstage buffers (only for SMT?!)
 
−
 
 
−
 
 
−
Simulation Speed
 
−
 
 
−
    * Instruction Schedule Work
 
−
          o Use Vector of Vectors instead of Priority Queue
 
−
          o Identify Instruction Schedule Types (via Tuple)
 
−
          o Cache Instruction Schedule, Generate On-Demand
 
−
          o Instructions walk through schedule by incrementing pointer instead of popping from queue
 
−
          o If dynamic schedule is needed, then copy the remaining part of schedule and let the instruction add/remove as it pleases
 
−
                + Better solution here?
 
−
    * Event-Sleeping Work
 
−
          o Sleep instructions waiting for an long-delay event
 
−
          o Sleep CPU w/no activity (partially implemented)
 

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"