InOrder Pipeline Stages

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.

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

Adding Your Own Stage

• Python Configuration
• Instruction Schedule Information