Difference between revisions of "InOrder"

From gem5
Jump to: navigation, search
(Overview)
 
(17 intermediate revisions by 2 users not shown)
Line 1: Line 1:
This page provides a general overview of the InOrderCPU model, its pipeline stages, and its resources. We'll continue to update this page in more detail as the inorder core starts to make it way from  the "m5-dev" to the "m5-stable" repositories.  
+
== Overview ==
 +
The InOrder CPU model was designed to provide a generic framework to simulate in-order pipelines with an arbitrary ISA and with arbitrary pipeline descriptions. The model was originally conceived by closely mirroring the O3CPU model to provide a simulation framework that would operate at the "Tick" granularity. We then abstract the individual stages in the O3 model to provide [[InOrder Pipeline Stages | generic pipeline stages]] for the InOrder CPU to leverage in creating a user-defined amount of pipeline stages. Additionally, we abstract each component that a CPU might need to access (ALU, Branch Predictor, etc.) into a "resource" that needs to be requested by each instruction according to the [[InOrder Resource-Request Model | resource-request]] model we implemented. This will potentially allow for researchers to model custom pipelines without the cost of designing the complete CPU from scratch.
  
----
+
For more information, please check the following documentation about the InOrder model, browse the code, and also access the gem5-users@m5sim.org (standard usage) or gem5-dev@m5sim.org (for developer)
 +
mailing lists:
  
* Soumyaroop Roy has been kind enough to provide a [http://www.csee.usf.edu/~sroy/techres/m5_tests/|"test-status-page"] of the M5-Inorder model in the work he has been doing.  
+
* [[InOrder Pipeline Stages | Pipeline Stages]]
(Note: The latest versions of the inorder model can be found in the m5-dev repository. Please check there for updates and additional information.)
+
* [[InOrder Resource-Request Model | Resource-Request Modeling]]
 +
* [[InOrder Instruction Schedules | Instruction Schedules & Pipeline Descriptions]]
 +
* [[InOrder Tutorial | A Day in the Life of an Instruction in the InOrderCPU model (Not Completed)]]
 +
*Other Links:
 +
**Soumyaroop Roy has been kind enough to provide a [http://www.csee.usf.edu/~sroy/techres/m5_tests/"test-status-page"] of the M5-Inorder model in the work he has been doing.
  
* [[InOrder CPU FAQ]] - As more questions are received, we'll start to put to frequent answers here...
+
== Current Development ==
 
+
'''Latest versions of the InOrderCPU model can be found in the gem5-dev repository'''
----
+
* [[InOrder ToDo List]]
 
 
The relevant sources files are in src/cpu/inorder.
 
 
 
== Pipeline Stages ==
 
In it's most basic incarnation, the In-Order model models a 5-stage pipeline.
 
 
 
The 5-stage pipeline is based on the 5-stage MIPS pipeline and has the following stages:
 
* Instruction Fetch (IF)
 
* Instruction Decode (ID)
 
* Execute (EX)
 
* Memory Access (MEM)
 
* Register Write Back (WB)
 
 
 
Relevant source files:
 
* first_stage.[hh,cc]
 
* pipeline_stage.[hh,cc]
 
 
 
== Pipeline Resources ==
 
The following pipeline resources are defined for InOrderCPU:
 
* Fetch Unit
 
* Instruction Cache (I-Cache)
 
* Branch Prediction Unit (BPred Unit)
 
* Register File Manager (RF Manager)
 
* Address Generation Unit (AGen Unit)
 
* Execution Unit (EXU)
 
* Integer Multiply and Divide Unit (Int MDU)
 
* Data Cache (D-Cache)
 
* Graduation Unit (Grad Unit)
 
 
 
Relevant source files:
 
* resources/*.[hh,cc]
 
 
 
== Resource Pool ==
 
@TODO
 
 
 
== Pipeline Definition ==
 
@TODO
 
 
 
== Instruction Schedules ==
 
Instruction scheduling is divided into a ''front-end schedule'' (IF and ID), which is uniform for all the instructions, and a ''back-end schedule'', which varies across the different instructions.
 
 
 
* Front-end Schedule
 
** The front-end schedule comprises of the IF and ID stages
 
*** IF
 
**** NPC is updated by the Fetch unit
 
**** Instruction fetch from the I-Cache is initiated
 
*** ID
 
**** Instruction fetch is completed by I-Cache
 
**** Instruction decode is performed by the Decode unit
 
**** Branch prediction is performed by the BPred unit
 
**** Target PC is updated by the Fetch unit
 
 
 
* Back-end Schedule
 
** The back-end schedule comprises of the ID, EX, MEM, and WB stages
 
*** ID
 
**** For non-store instructions, the source registers, if any, are read by the RF Manager
 
**** For load instructions, address generation is performed by the AGEN unit and data read from the D-Cache is initiated
 
**** The rest of the instructions are executed in the execution units
 
***** Single cycle operations are sent to the integer EXU
 
***** Execution is initiated for the multicycle/pipelined operations
 
*** EX
 
**** Execution is finished for the multicycle/pipelined operations
 
**** For load instructions, data read from the D-Cache is completed
 
**** For store instructions, the following tasks are performed
 
***** The source registers are read by the RF manager
 
***** Address generation is performed by the AGen unit
 
***** Data write into the D-Cache is initiated
 
*** MEM
 
**** For store instructions, data write into the D-Cache is completed
 
*** WB
 
**** Destination registers are written into by the RF manager
 
**** The instruction is graduated by the Grad unit
 
 
 
Relevant source files:
 
* pipeline_traits.[cc,hh]
 

Latest revision as of 06:59, 19 June 2011

Overview

The InOrder CPU model was designed to provide a generic framework to simulate in-order pipelines with an arbitrary ISA and with arbitrary pipeline descriptions. The model was originally conceived by closely mirroring the O3CPU model to provide a simulation framework that would operate at the "Tick" granularity. We then abstract the individual stages in the O3 model to provide generic pipeline stages for the InOrder CPU to leverage in creating a user-defined amount of pipeline stages. Additionally, we abstract each component that a CPU might need to access (ALU, Branch Predictor, etc.) into a "resource" that needs to be requested by each instruction according to the resource-request model we implemented. This will potentially allow for researchers to model custom pipelines without the cost of designing the complete CPU from scratch.

For more information, please check the following documentation about the InOrder model, browse the code, and also access the gem5-users@m5sim.org (standard usage) or gem5-dev@m5sim.org (for developer) mailing lists:

Current Development

Latest versions of the InOrderCPU model can be found in the gem5-dev repository