1
Parallel Page Instruction Pipeline Processor
Developed by Brad Smith 50% Apurv Kumaria 50%
Page 2
Overview
This paper will cover the inspiration, development, and testing of the Parallel Instruction Pipeline Processor that was developed for this project. At the end, the code from each of the five blocks, the overall project code, and the code for pieces that have been changed from the original concept of pipeline in our book has been included. The Parallel Instruction Pipeline Processor (PIPP) makes use of the pipeline processor's ability to run through multiple instructions at once and takes it a step further. It runs two instructions in parallel at each step, meaning that at it's peak efficiency, it will run twice as fast as a normal pipeline processor, while at it's lowest operating speed, slowed by hazards and bubbles, the PIPP will run as fast as the normal pipeline processor. In order, this paper will discuss how the concept for the PIPP was developed, the instruction set that was developed for the processor, the design of each individual unit, the hazards and forwarding that need to be taken into account, the testing performed, and finally various thoughts on the project, partnership, and learning both from this project and in the class in general.
Initial Development
When we were asked to begin thinking about what type of application we would like our processor to be used for, we were stumped. Computers are a part of our every day lives now, both in our everyday life and our schoolwork, especially with the career path we have chosen. Our first impulse was to lean towards the mainstay of our lives before and during our time at Iowa State, gaming. We are both avid computer gamers, so we immediately began to look into the types of processors that best help in the running of computer games. It did not take long before we came across
Page 3
the idea of a Dual-Core processor. Obviously, this was a little beyond what we are able to do, but we decided to take that idea and run with it. With a little planning, we realized we would be able run two instructions at the same time, or essential run two processors simultaneously. It would cost nearly twice as much as a normal pipeline processor, but we knew that for computer gaming, the price would be high since we would be developing for performance and not for cost. While the Dual-Core processor was our inspiration, we realized it was not exactly what we are trying to implement, it would be more along the lines of a Superscalar Processor. There would be two instructions coming out of the instruction memory, and they both would travel to the register file. Four outputs would come from this unit and travel into the Execution phase where there would be two ALUs and two Shifters to handle the two instructions. These would then pass onto the memory, where they both could be written to two different or the same address, and finally could be written back into different or the same register. We wanted to make sure our data memory and our register file were accessible by both paths of instructions, and we wanted to be sure that we kept the proper order to the instructions as given to us by the programmer. With all this in mind, the developing of the PIPP ran into the problems we thought it would, but it turned out to be a success.
Instruction Set
Before we could design our processor however, we had to decide on a set of instructions and how they would be set up in format. We had been mostly working with 32 bits up to this point for instructions, but we realized that most of the time we didn't use all 32 bits, especially for the branch and I-type instructions. We decided to go with 16 bit long instructions, with an opcode of four bits, which means that we can only have 16 instructions, unless we want to implement an ALU control. While we could have done this, we decided that the processor only really needs 16 instructions to get the job Page 4
done, so we kept the opcode at four bits, and stayed with 16 instructions. We used the register file we had created earlier as our inspiration for developing the way the bits are used, as can be seen in the diagram below. For R-type functions (add, subtract, set less than, and, or) the instruction reads down the input side of the register after the opcode: Read address 1, Read address 2, write address.
IF Block
The IF or Instruction Fetch block reads from an instruction memory, and sends out the correct instruction into the pipeline. There is a PC (Program Counter), that counts which step or instruction that the block is on, and sends that value to the instruction memory. For example, the PC starts at 0, where it sends that to the instruction memory. The instruction memory then sends out the instruction at location 0 to be sent to the next block. As the instruction is being sent out to the registers to be saved for the next block, the PC increments itself appropriately for the next step, for 16 bit instruction, it would increment itself by 2. It does this by sending the PC output into an ALU where it adds the current count to 2, then sends that back to the input of the PC to be written in and given to the memory in the next step. Because of the branch and jump instructions that we are implementing, the incremented counter is not the only value we will want written into the PC; we may also want to write in addresses from later in the pipeline. We handle this by introducing a MUX, controlled by a Control Unit, that chooses between the incremented PC value, the branch address being sent in, and the jump address being sent in to send to the PC unit. For the PIPP however, it is not this simple, there will need to be two instructions coming out of the block, so it must be designed with that in mind. While the PC does put out the current state, it sends it to an instruction memory, which then sends that instruction out. At the same time though, an ALU Page 5
adds two to the PC and sends it to a second, identical instruction memory, taking out the next instruction and sending that out as well. The PC is then incremented by 4 and sent into the MUX described earlier, getting it ready to go to the next instruction in the list.
ID Block
Control
The Control is outside the main five blocks of the pipeline, but is generally placed above the ID block in visualization because that is the first time it is accessed. The control reads in the opcode of the instruction, and depending on what it reads it gives out signals which determine the selection of MUXs, the writing of registers, the operation of ALUs, and every other piece within the pipeline. You can find the Control code at the end of this report, where it lists all the signals sent out to the pipeline for each opcode that it reads in. The control signals are not all used in the ID block, so the ones that are used in later blocks must be passed onto registers so that the Control can be used for the next instruction. They follow along with the instruction they are related with passing through their own registers, until they reach the block where they are used. In the PIPP the Control is no different from the normal pipeline Control except that it must read in two opcodes instead of one and give out twice as many signals as there are two different instructions passing through at the same time.
Page 6
EX block
The execution or EX block is the stage where data is manipulated. In a normal pipeline, there is an ALU and a shifter in it, to take the data that was taken from a register, and to do the required instruction to it, before sending it onto the register to be saved. What goes into the ALU or shifter to be operated upon depends upon the forwarding unit, which will be discussed later. The ALU chooses how the two inputs will be operated on by a signal received from the control, discussed earlier. At the end of the block, before either the ALU or shifter writes to the registers, a MUX is put in, controlled by the Control, that determines whether the shifter value or the ALU value is to be saved to the register. While the ALU and shifter are the main functions going on in this stage, there are several other calculations being made at the same time. In this stage, the branch address and the two jump addresses are calculated. The branch address is made by shifting the sign extended immediate value at the end of instruction to the left by one, adding a zero in the LSB, it is then added to the PC plus 4 value that has been carried over from the IF stage in a separate ALU. In the branch instruction, the main ALU is required to subtract the two registers dictated by the instruction, and from the result it can determine if the two registers are equal or not. A wire is taken from the ALU out port called sum, every bit of this wire is put into a single OR gate, and the result is then either zero or one. If the result is zero, then the two are equal two each other, if the result is one, then the two are not equal to each other. This bit is sent into the MEM block so that it can be used to decipher whether or not there will be a branch. The jump register address is pulled out of incoming wire into the forwarding unit, to make sure that it receives the correct register value. The jump and link value is the sign extended immediate from
Page 7
the ID block, passed on through the registers. These three addresses are passed onto the MEM block, where they will then be sent elsewhere to be used. In the PIPP EX block, there are two ALUs and two shifters, as well as two adders and shifters for the branch instructions. Mostly, this isn't a problem, as the lines do not cross. The only time that they might exchange values is when we are dealing with forwarding from earlier instructions, but this will be addressed in the forwarding unit and not in this section.
MEM Block
MEM Block is the fourth stage in the pipeline. It is the stage which decides the processor clock cycle time since it takes the maximum time to execute. The MEM Block consists of a memory which is used to store or load data. The memory is written in the negative edge of the clock and read in the positive edge. The memory consists of two control signals MEMREAD, MEMWRITE. They are controlled by the control unit depending upon whether lw or sw is executing in the MEM Block. The memory has a read data port, a port for address and one data out port. In case of the PIPP processor, the memory has two read data port, two address port and two data out port, so as to execute two instructions. If both the instructions are writing to the same address in the memory then the data in the second instruction's register is written in the address as the second instruction is executed later and it should overwrite the contents written by the first instruction in the same address. It is also the stage in which the branch instructions are checked and finally sent to Program Counter to be branched to the calculated instruction. The addresses of the registers are also passed through the MEM Block to the WB Block and to the Forwarding Unit to overcome any dependencies.
Page 8
WB Block
WB BLOCK is the last stage of the pipeline. It is the simplest stage of the Pipelined processor with just one Multiplexer. WB Block completes the execution of the instruction by writing the data into the register present in the register file. The multiplexer chooses between the whether the data is from the Memory or from the ALU. The select signal of the multiplexer is controlled by the control unit depending upon the instruction to be executed. In case of the PIPP, two 4 to 1 Multiplexers are used, one for each instruction. are There only three inputs to the Multiplexer, data from ALU, data from memory and PC plus 2. There is an ALU used as a subtracter. This subtracts the PC by two and stores it in the register file. This is used in case of a JAL instruction. The address of the write register also passes from the WB Block to the register file.
Forwarding Unit
The usage of forwarding Unit is to take care of the dependencies without hindering the flow and execution of instruction. In a scalar pipeline, the dependencies can be between two or three consecutive instructions, in which the later instruction uses the register modified in the first instruction. In such case the register modified is still in the pipeline, in the MEM Block or in the WB Block and is still not written back in the register file. One solution can be stalling the next instruction until the register of the previous instruction is written back in the register file. This results in wastage of clock cycles and decreasing the performance of the processor. The forwarding unit is used to check these kinds of dependencies and resolve them without stalling the instructions. The logic behind the forwarding unit is to check the registers used in previous instructions and passing them to the MEM Block and WB Block. The registers to be used in the EX block for ALU operations like adding, subtracting, AND-ing,
Page 9
OR-ing and address calculation, are checked with write registers in the MEM Block and WB Block. Condition for the register write is also checked, i.e. whether regwrite signal is asserted at MEM Block or the WB Block. If the condition is satisfied then the register's value from MEM Block or WB Block is forwarded to the EX Block. The logic for the forwarding unit is
1. EX hazard a. If ((EX/MEM.RegWrite) and (EX/MEM.RegisterRd != 0) and (EX/MEM.REgisterRd = ID/EX.RegisterRs)) Forward Value of EX/MEM.REgisterRd to ID/EX.RegisterRs b. If ((EX/MEM.RegWrite) and (EX/MEM.RegisterRd != 0) and (EX/MEM.RegisterRd = ID/EX.RegisterRt)) Forward Value of EX/MEM.REgisterRd to ID/EX.RegisterRt
2. MEM hazard a.If ((MEM/WB.RegWrite) and (MEM/WB.REgisterRd != 0) and (MEM/WB.REgisterRd = ID/EX.RegisterRs)) Forward Value of MEM/WB.REgisterRd to ID/EX.RegisterRs b.If ((MEM/WB.RegWrite) and (MEM/WB.REgisterRd != 0) and (MEM/WB.REgisterRd = ID/EX.RegisterRt)) Forward Value of MEM/WB.REgisterRd to ID/EX.RegisterRt
The PIPP processor, which we are implementing, has to check few more conditions. Since in our PIPP processor, two instructions are implemented in one clock cycle, hence the forwarding unit has to take care of few more register checks. Also, the forwarding unit takes care of inter-instruction dependencies, i.e. the dependencies arising between the two instructions executed in the same clock cycle. The logic behind the forwarding unit of PIPP Processor is:
Page 10
Similarly it checks for the register ID/EX RegisterRt. This logic takes care of the dependencies arising Page 11
within consecutive instructions present in next block. The forwarding unit also takes care of the dependency arising within the instructions present in the same block. A possible scenario can be
add $4,$3,$2 add $6,$4,$5
Both of these instructions are to be executed in the same clock cycle. In such case the Forwarding Unit uses the value of $4 calculated by ALU1 and is forwarded to the next instruction present in the EX BLOCK. So, the instructions are executed sequential at this part of the Pipeline to resolve the dependency. It makes use of the fact that the clock cycle is large enough to incorporate that.
The forwarding unit was tested with all the dependencies that were possible.
Branch and Jump Control
The Branch and Jump Control (BJC) is our way of deciding whether or not the pipeline needs to jump or branch to a different PC step other then simply incrementing by 4. It takes in, from the Control, signals that determine whether or not the operation is a branch equal, branch not equal, jump register, or jump and link, as well as the addresses associated with each, and the bits that tell whether or not the two registers defined in the branch are equal or not equal. In the PIPP, because of the parallel instructions, the first instruction will always take precedence. This means that the BJC will check all the signals for the first instruction first, to see if it is
Page 12
a branch or jump. If it determines that it one of those four, then it will send out the proper address to the IF block and the MUX there, as well as send the signal to that MUX, telling it to select that address. The next step will then be the address that was determined by the branch or jump instruction. If the first instruction was not a branch or jump, it would then check the second instruction, and if that is a branch or jump, it will do the same for it, sending out the address and selecting it for the PC. This unit takes care of the addressing, but it does not address the fact that there will be other instructions in each of the prior blocks (IF, ID, EX) as this unit cannot be triggered until the branch or jump reaches the MEM block.
Branch and Jump Hazard
The branch and jump hazard unit (BJH) is the one that takes care of the instructions that should not be triggered because of a jump or branch. All this unit does is send signals to the registers between the blocks, telling them whether to reset themselves or not, as well as telling the PC whether or not to write. This unit is placed right above the EX stage in the pipeline, while the BJC is placed above the MEM block, so this means that this hazard actually takes place before the branch address is passed on. It is because of this that simply telling registers to reset once isn't enough. Since another two instructions will be passed out of the IF stage before the BJC is triggered, the BJH must send a signal a cycle later to the registers between the IF and ID stages, to completely eliminate instructions after the branch or jump when they are triggered. The registers that reset are the ones between IF and ID, and ID and EX. The write to PC is also turned off, so we have one less instruction to worry about. There are two different portions to this unit, as there are two separate instructions in the pipeline, and each one needs to be handled differently. If the branch or jump instruction is in the second instruction in the parallel, the way it handles everything is much simpler. It resets all the following Page 13
instructions in the way described above. If it is the first instruction, however, it must also reset the registers pertaining to the instruction that is running in parallel with it, as that instruction is considered to be running after it, and should not be executed in a branch or jump.
Load Word Hazard at EX
This hazard unit for the load word function is comparable to the load word hazard unit in a normal pipeline processor. It compares the writing address of the load word function in either of the two parallel instructions in the EX block with the read addresses of the functions in the ID block. Of any of the registers match, it then creates a bubble between the two sets of instructions by not writing to the registers between IF and ID, and then reseting the registers at ID and EX, eliminating a second copy of the load word instruction and replacing it with a bubble. By adding this bubble into the pipeline, it allows the load word to load the value from the memory so that it can be forwarded to the following instructions in the EX stage. This unit, however, does not take care of the case when there is a load word instruction in the first of the parallel instruction, and the second instruction depends on what comes out of that load word..
Load Word Hazard
This hazard unit for the load word instruction checks the first parallel instruction with the second to see if there is any dependencies between the two. This unit is set up to execute during the ID block, so the problem can be caught immediately and taken care of in one stroke. It does this check in three different ways. First it checks to see if the first instruction is a load word, then it checks if the bits from 11 to 8 in the second instruction match the address of the register the load word is writing to. In
Page 14
all instructions but one, if those match, then there is a dependency, and a bubble must be created. If the second instruction is a jump and link instruction, then there is no dependency and thus no bubble. Secondly it checks to see if the first instruction is a load word, then it checks if the bits from 7 to 4 in the second instruction match the address of the register the load word is writing to. This only applies to R type instructions, like adds and subtracts. So the unit checks the opcode through logic to see if it is or is not an R-type. Finally, it checks to see if the first instruction is a load word, then it checks if the bits from 7 to 4 in the second instruction match the address of the register the load word is writing to. This is for the branch instructions only, and there is logic that sets that up as well. The unit has these separate for testing purposes, and to make the logic simpler. After these checks are made, if one of the three situations above are hit upon, then the unit begins to change things. There is a MUX set up just outside the BJC that is controlled by this unit. When it is 0, the address the BJC picked is written into the PC, when it is 1, as set by when one of the three conditions is observed, it chooses the address of PC minus 2. This value is chosen because it selects the instruction directly after the load word in the two parallel instructions. It then resets the registers between the ID block and the EX block where the second instruction is housed. It also resets the registers between the IF block and the ID block, creating a bubble. This allows the load word instruction to continue through, alone, with a bubble after it, and the instruction that was directly after it to come right after that bubble where the forwarding unit can make sure it gets the correct value.
Testing Methodology
Our testing methodology changed dramatically since the first time we tried to do a pipeline processor. In our first attempt we did build each individual block of the pipeline, tested independently
Page 15
for all functions, then hooked them together. However, we also hooked up both the forwarding and hazard unit at the same time, and they had been tested independently as well. The problem with this was we did not take care of the errors from the forwarding unit before we hooked up the hazard unit. We changed our approach this time around, and while we did not get a normal pipeline working, we got the PIPP working. After we hooked up the 5 basic blocks and the control, we tested each instruction, one after the other, with no dependencies, until we were sure that it worked. Then we attached the BJC unit to it and made sure that worked perfectly. We then attached the forwarding unit, and fixed all the incorrect wire assignments we had made. We tested all the dependencies that this unit took care of, with all the correct instructions before we moved onto the BJH. Once this unit had been tested out and correctly hooked up, we moved onto the load word hazard EX. This was tested thoroughly before we finally attached the load word hazard, the most specific unit, and we tested this until we were positive it worked as well. Once all these units had been attached and linked together, we ran a sample set of code, checking the data with what was supposed to be given, and we found that the PIPP was running properly.
Page 16