Differences

This shows you the differences between two versions of the page.

--- projects:pipelined_cpu_hazards_eliminated [2013/12/18 20:27]
eric.westman [Pipelining]
+++ projects:pipelined_cpu_hazards_eliminated [2013/12/18 23:43] (current)
sstrohkorb [How can someone else build on it?]
@@ Line 65: / Line 65: @@
 {{ :projects:pic1.png?direct |}}
-One major change between the multi-cycle and pipelined CPU is the introduction of registers between the major hardware components in each stage. Because each stage executes within a clock cycle, registers are placed between each stage in order to hold and propagate data through the pipeline that is needed throughout different stages of execution.
+One major change between the multi-cycle and pipelined CPU is the introduction of registers between the major hardware components in each stage. Because each stage executes within a clock cycle, registers are placed between each stage in order to hold and propagate data through the pipeline that is needed throughout different stages of execution, as shown below.
 {{ :projects:pic6.png |}}
@@ Line 79: / Line 79: @@
 {{ :projects:pic3.png?direct |}}
-Some programs may have instructions that need data that is modified by one of the previous few instructions. This could be data in the register file, memory, or a cache (if caching were implemented). Regardless of where this data is to be stored, however, if a following instruction needs it before it has been written to its destination, that instruction will give the wrong result. This can be avoided by “forwarding” the needed data to the EX phase of the instruction that needs it. The following diagram shows an example of forwarding where the SUB, AND, and OR instruction all require the result of the first instruction before it has been written:
+Some programs may have instructions that need data that is modified by one of the previous few instructions. This could be data in the register file, memory, or a cache (if caching were implemented). Regardless of where this data is to be stored, however, if a following instruction needs it before it has been written to its destination, that instruction will give the wrong result. This can be avoided by “forwarding” the needed data to the EX phase of the instruction that needs it. The following diagram shows an example of this data hazard where the SUB, AND, and OR instruction all require the result of the first instruction before it has been written:
 {{ :projects:pic4.png?direct |}}
@@ Line 91: / Line 91: @@
 Another hazard arises from the way that the CPU keeps track of its progress when running a program. In the IF phase of each instruction that the CPU can handle, the CPU updates the “program counter,”  which monitors the location that the CPU has reached in the program, but some instructions (mainly the ones used to perform loops or if statements) reset the program counter in later phases. Resetting the program counter in a later phase is a problem because the CPU has already started executing the next sequential instructions!
+To sidestep this issue, we implement a “guess and check” system. Whenever there is an instruction that will or may reset the program counter, we assume that it will not and continue executing normally. If and when it does reset the program counter, we signal for the following instructions which have already entered the pipeline to stop executing by the MEM and WB stages (before they actually make any changes). After the PC is reset, the pipeline loads the next correct instruction and continues the program accordingly.
 ===== How can someone else build on it? =====
+**Work Plan Reflection:**
+Our goal for the project was to build a pipelined CPU that handled at least one hazard and process more instructions than we have been doing for the labs. We were not able to get the pipelined CPU to be fully operational but most of the instructions work and the other instructions work in isolation.
+We made slight modifications to our schedule as we came across many problems implementing the pipeline. We decided to implement a pipelined format then add instructions as we progressed instead of trying to complete the entire thing in one pass.
+**To Do:**
+  * Check the JAL and JR functionality
+  * Check the Forwarding logic to make sure it is implemented correctly, especially with the storing word instructions
+  * Redesign and implement a system to handle jumping and branching
+**Schematic:**
+{{ :projects:screen_shot_2013-12-18_at_11.40.26_pm.png?nolink |}}
+{{ :projects:screen_shot_2013-12-18_at_11.40.34_pm.png?nolink |}}
+**Build Instructions:**
+How to compile Assembly program using Mars4_4 to machine code:
+  - Compile/assemble the Assembly program (F3)
+  - Dump the file to memory (File -> Dump Memory or Control + D)
+  - Change dump format to Binary Text
+  - Save file
+How to run a program in machine code on our pipelined CPU using ModelSim:
+  - Make sure that the line **$readmemb(FILENAME, Memory)** uses the correct filename, such as “example.dat” and that the path is reference correctly if the machine code file is not in the same directory as the verilog file.
+  - Open ModelSim. If you don’t have a project for this CPU, then make one. Add the files “pipelinedCPU.v” and “pipelinedCPU.do” to the project, and make sure the .dat file is in the same directory.
+  - Open the project. Type “do pipelinedCPU.do” into the command line and press enter.
+  - This will run the program in the machine code file using the pipelined CPU. You may need to manually set the run time to a convenient time for the program.
+**Gotcha’s, watchouts:**
+  * Debugging will take longer than expected. Always.
+  * Get comfortable with the ins and outs of Verilog
+  * Addressing memory may be different in your implementation of the CPU as compared to MIPS Assembly if you use 32-bit words instead of 8-bit words
+  * Design your hazard avoidance systems before you look at the code and try to implement it, draw it out first and discuss it before you go to implement in the code
+Code, tests, and build instructions (please read the README): {{:projects:pipelinedcpu_project_files.zip|}}

ca Wiki

User Tools

Site Tools

Differences

Page Tools