Difference between revisions of "InOrder Pipeline Stages"

From gem5
Jump to: navigation, search
Line 12: Line 12:
  
  
The "PipelineStage" class maintains the functionality of (2a) and (2b) but abstracts the (1) out of the implementation. More specifically,
+
The "PipelineStage" class maintains the functionality of (2a) and (2b) but abstracts (1) out of the implementation. More specifically,
 
no pipeline stage is explicitly marked "Decode" or "Execute". Instead, the PipelineStage class allows the instruction and it's corresponding
 
no pipeline stage is explicitly marked "Decode" or "Execute". Instead, the PipelineStage class allows the instruction and it's corresponding
 
instruction schedule to define what tasks they want to do in a particular stage.  
 
instruction schedule to define what tasks they want to do in a particular stage.  
Line 27: Line 27:
  
 
== Interstage Communication ==
 
== Interstage Communication ==
Pipeline stages need to communicate with each other in a couple scenarios:
+
Pipeline stages need to communicate with each other in a few scenarios:
 
* Sending an instruction to the next stage
 
* Sending an instruction to the next stage
 
* Sending a stall signal back to previous stages
 
* Sending a stall signal back to previous stages
* Sending a squash signal back to previous stages
+
* Sending a squash (e.g. branch misprediction) signal back to previous stages
 +
 
 +
 
 +
===Forwards Communication===
 +
This is the simplest case in which a PipelineStage has finished doing all the processing it needs for an instruction
 +
and will place the instruction in a queue (implemented through wires) for the next stage to read from.
 +
 
 +
*The information in the "wire" is taken from the "InterStageComm" struct found in "comm.hh".
  
 
===Backwards Communication===
 
===Backwards Communication===
Line 41: Line 48:
 
on Cycle X+1.
 
on Cycle X+1.
  
The information in the "wire" is taken from the "InterStageComm" struct found in "comm.hh".
+
== Pipeline Stage Processing ==
 
+
Each stage follows these generic steps each tick:
 
+
# Read stall and/or squash signals from stages further in the pipeline
===Forwards Communication===
+
:If stall or squash is requested, then perform operation and do not process instructions that tick
In the simplest case, a PipelineStage has finished doing all the processing it needs for an instruction
+
:If no stall or squash, continue processing.
and will place the instruction in a queue (implemented through wires) for the next stage to read from.
+
# Select a thread to process instructions from
 
+
# Process all resource requests for an instruction and send instruction to next stage
 
+
:* If all resource requests are completed for an instruction, proceed to next instruction as long as the pipeline bandwidth is not used up.
== Pipeline Processing ==
+
:* If all resource requests are not completed for an instruction, save instruction in stage "skidBuffer" and stall remaining instructions in pipeline stage from that thread
 
 
 
 
== First Stage ==
 
  
 +
=== First Stage ===
 +
The FirstStage derives the "PipelineStage" class and implements specific operations that are needed for any first stage of the pipeline. Because there is no stage in front of
 +
the FirstStage there are no instructions to read from so the appropriate adjustments are made for this particular stage to create a new instruction each pipeline tick instead
 +
of read it from the previous stage.
  
 
== Implementations ==
 
== Implementations ==
In it's most basic incarnation, the In-Order model models a 5-stage pipeline.
+
In it's most basic incarnation, the In-Order model models a 5-stage pipeline with the following stages:
 
 
The 5-stage pipeline is based on the 5-stage MIPS pipeline and has the following stages:
 
 
* Instruction Fetch (IF)
 
* Instruction Fetch (IF)
 
* Instruction Decode (ID)
 
* Instruction Decode (ID)
Line 64: Line 70:
 
* Memory Access (MEM)
 
* Memory Access (MEM)
 
* Register Write Back (WB)
 
* Register Write Back (WB)
 +
 +
An example of a 9-stage pipeline is also available in the code directory. To Test it out, you'll need to copy the overwrite the "pipeline_traits.hh,cc" files with the 9-stage versions.
  
 
== Pipeline Customization==
 
== Pipeline Customization==
=== Stage Instantiation ===
+
=== Adding Your Own Stages ===
 +
*Python Configuration: TBD
  
=== Adding Your Own Stage ===
+
*Instruction Schedule Information: Customizing the pipeline involves changing in what order an instruction will ask for it's resources. For example, the developer has the option to allow a load instruction to calculate it's address in stage 3 or stage 4. The developer would need to alter the instruction's schedule to enforce a particular pipeline configuration. Check out pipeline_traits.cc for more details on this process.
*Python Configuration
 
*Instruction Schedule Information
 

Revision as of 18:17, 19 January 2010

Overview

Pipeline stages in the InOrder CPU are implemented as abstract implementations of what a pipeline stage would be in any CPU model. Typically, one would imagine a particularly pipeline stage being responsible for:

(1) Performing specific operations such as "Decode" or "Execute" and either

(2a) Sending that instruction to the next stage if that operation was successful and the next stage's buffer has room for incoming instructions

or

(2b) Keeping that instruction in the pipeline's instruction buffer if that operation was unsuccesful or there is no room in the next stage's buffer


The "PipelineStage" class maintains the functionality of (2a) and (2b) but abstracts (1) out of the implementation. More specifically, no pipeline stage is explicitly marked "Decode" or "Execute". Instead, the PipelineStage class allows the instruction and it's corresponding instruction schedule to define what tasks they want to do in a particular stage.


Implementing the "PipelineStage" class in this manner allows for the modeling of arbitrarily long pipelines (easy replication of pipeline stages) as well as other potentially complex pipeline models.

Relevant source files:

  • first_stage.[hh,cc]
  • pipeline_stage.[hh,cc]
  • pipeline_traits.[hh,cc]
  • cpu.[hh,cc]

Interstage Communication

Pipeline stages need to communicate with each other in a few scenarios:

  • Sending an instruction to the next stage
  • Sending a stall signal back to previous stages
  • Sending a squash (e.g. branch misprediction) signal back to previous stages


Forwards Communication

This is the simplest case in which a PipelineStage has finished doing all the processing it needs for an instruction and will place the instruction in a queue (implemented through wires) for the next stage to read from.

  • The information in the "wire" is taken from the "InterStageComm" struct found in "comm.hh".

Backwards Communication

To handle backwards communication (stall/squash), the InOrderCPU uses the concepts of a "wire" to pass information back to previous stages. When a CPU is setup, each "wires" are defined with parameterized latencies that govern how many ticks a stage must wait to retrieve the information from that "wire". As an example, let's say Stage 3 wants to send a squash signal to Stage 1. If the the user wants Stage 1 to see information from Stage 3 the next clock tick, they would set that wire's latency to 1. In this case, if Stage 3 wanted to squash instructions on Cycle X, Stage 1 would operate undeterred on Cycle X, but notice the squash signal on Cycle X+1.

Pipeline Stage Processing

Each stage follows these generic steps each tick:

  1. Read stall and/or squash signals from stages further in the pipeline
If stall or squash is requested, then perform operation and do not process instructions that tick
If no stall or squash, continue processing.
  1. Select a thread to process instructions from
  2. Process all resource requests for an instruction and send instruction to next stage
  • If all resource requests are completed for an instruction, proceed to next instruction as long as the pipeline bandwidth is not used up.
  • If all resource requests are not completed for an instruction, save instruction in stage "skidBuffer" and stall remaining instructions in pipeline stage from that thread

First Stage

The FirstStage derives the "PipelineStage" class and implements specific operations that are needed for any first stage of the pipeline. Because there is no stage in front of the FirstStage there are no instructions to read from so the appropriate adjustments are made for this particular stage to create a new instruction each pipeline tick instead of read it from the previous stage.

Implementations

In it's most basic incarnation, the In-Order model models a 5-stage pipeline with the following stages:

  • Instruction Fetch (IF)
  • Instruction Decode (ID)
  • Execute (EX)
  • Memory Access (MEM)
  • Register Write Back (WB)

An example of a 9-stage pipeline is also available in the code directory. To Test it out, you'll need to copy the overwrite the "pipeline_traits.hh,cc" files with the 9-stage versions.

Pipeline Customization

Adding Your Own Stages

  • Python Configuration: TBD
  • Instruction Schedule Information: Customizing the pipeline involves changing in what order an instruction will ask for it's resources. For example, the developer has the option to allow a load instruction to calculate it's address in stage 3 or stage 4. The developer would need to alter the instruction's schedule to enforce a particular pipeline configuration. Check out pipeline_traits.cc for more details on this process.