Difference between revisions of "InOrder Pipeline Stages"

From gem5
Jump to: navigation, search
Line 1: Line 1:
 
== Overview ==
 
== 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
  
'''Relevant source files:'''
+
(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 the (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]
 
* first_stage.[hh,cc]
 
* pipeline_stage.[hh,cc]
 
* pipeline_stage.[hh,cc]
Line 9: Line 27:
  
 
== Interstage Communication ==
 
== Interstage Communication ==
 +
Pipeline stages need to communicate with each other in a couple scenarios:
 +
* Sending an instruction to the next stage
 +
* Sending a stall signal back to previous stages
 +
* Sending a squash signal back to previous stages
 +
 +
===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.
 +
 +
The information in the "wire" is taken from the "InterStageComm" struct found in "comm.hh".
 +
 +
 +
===Forwards Communication===
 +
In the simplest case,  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.
 +
  
 
== Pipeline Processing ==
 
== Pipeline Processing ==
Line 28: Line 67:
 
== Pipeline Customization==
 
== Pipeline Customization==
 
=== Stage Instantiation ===
 
=== Stage Instantiation ===
 +
 
=== Adding Your Own Stage ===
 
=== Adding Your Own Stage ===
 
*Python Configuration
 
*Python Configuration
 
*Instruction Schedule Information
 
*Instruction Schedule Information

Revision as of 15:18, 13 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 the (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 couple scenarios:

  • Sending an instruction to the next stage
  • Sending a stall signal back to previous stages
  • Sending a squash signal back to previous stages

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.

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


Forwards Communication

In the simplest case, 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.


Pipeline Processing

First Stage

Implementations

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)

Pipeline Customization

Stage Instantiation

Adding Your Own Stage

  • Python Configuration
  • Instruction Schedule Information