Designing a processor is one of my favorite feelings, especially when they work as intended. This project was no exception. In this project myself and a small group designed, programmed, simulated, tested, and synthesized 3 processor implementations of the MIPS ISA. This has been my most complex processor design to date however I do not expect it to stay that way for long. Jumping into the design, the three implementations we made were single cycle, software scheduled pipeline, and a hardware scheduled pipeline. At the end of the project, we synthesized all three and analyzed the benefits and cons of each architecture.
Primary Language : VHDL and MIPS assembly
Simulation Software : Model Sim
Supported Commands: add, addi, andi, beq, bne, j, jal, jr, lui, lw, nor, or, ori, sll, sllv, slt, slti, sra, srlv, sub, subu, sw, xor, xori
FPGA to Synthesize to : Cyclone IV
More Information about the MIPS instruction set : MIPS Instruction Reference
The first architecture we designed was a single cycle processor. In this type of processor every instruction only takes a single clock cycle to complete. Each instruction can be split into several phases: Fetch (getting the new instruction from memory), Decode (decoding what the instruction is telling the processor to do), and Execute (the processor operates according to the instruction). Because of the single cycle nature of this design, all three of the phases are executed in a single clock cycle providing us with a CPI (Cycles Per Instruction) of 1. This is generally a very good CPI however the downsides with this processor design is that certain blocks are very slow for example the Data Memory and that causes the max clock speed to be greatly reduced when compared to a pipelined processor. This clock slowing effect arises because each block is not ideal and takes a certain amount of time to complete its operation. The longest time that a data path can take is the constraint while picking the max clock speed. For this processor, while being synthesized on a Cyclone IV FPGA had a max clock rate of 29.92Mhz with the critical path having to do with our poor implementation of a ripple carry adder. This poor implementation affected our results because the critical path should have been based around the data memory and in the pipelined version, we optimized for a slow data memory rather than a slow ALU.
After we had the basic single cycle processor, it was time to work on the more complex pipelined processor. For this processor, the goal was to speed up the overall clock speed and in the process increase the instructions per second. To do this we used additional hardware to split the single cycle into the 3 main phases, Fetch, Decode, and Execute. Each phase received its own register of varying size, using these registers we can save the state from the previous phase. This benefits the overall design because no longer requires waiting for an entire datapath but instead just relies on waiting for the longest step between 2 phase registers. In our case it was still the ALU by an order of magnitude due to the poor implementation of the ripple carry adder so the speedup from the single cycle to the pipelined processor was not as high as it could have been. The pipelined processor was able to achieve a max clock frequency of 55.97Mhz. On the benchmark programs we ran, the pipelined processor consistently ran slower than the single cycle due to the pipelined processor being software scheduled and several excess NO-OP commands were included in the testing due to lack of time for review.