0% found this document useful (0 votes)
120 views13 pages

Proj2 Report-1-1

This document summarizes a project report for a computer organization and assembly-level programming course. It includes responses to various questions about implementing a 5-stage pipeline processor in VHDL with forwarding and hazard detection. The report discusses test programs that were created to exhaustively test the data forwarding and hazard detection capabilities of the pipeline. Waveform outputs are shown and discussed to verify correct operation. The critical path is identified as passing through the ID/EX register, ALUsrc mux, ALU, and EX/MEM register, with a maximum frequency of 58.05 MHz.

Uploaded by

api-697702568
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
120 views13 pages

Proj2 Report-1-1

This document summarizes a project report for a computer organization and assembly-level programming course. It includes responses to various questions about implementing a 5-stage pipeline processor in VHDL with forwarding and hazard detection. The report discusses test programs that were created to exhaustively test the data forwarding and hazard detection capabilities of the pipeline. Waveform outputs are shown and discussed to verify correct operation. The critical path is identified as passing through the ID/EX register, ALUsrc mux, ALU, and EX/MEM register, with a maximum frequency of 58.05 MHz.

Uploaded by

api-697702568
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

CprE 381: Computer Organization and Assembly-

Level Programming
Project Part 2 Report
Project Part 2 Report

Team Members: Grant Pierce____________________________________

Camron Corcoran________________________________

Spencer Sutton______________________________

Project Teams Group #:_____1_01___________________

Refer to the highlighted language in the project 1 instruction for the context of the following questions.

[1.a] Come up with a global list of the datapath values and control signals that are required
during each pipeline stage.

[1.b.ii] high-level schematic drawing of the interconnection between components

.
[1.c.i] Include an annotated waveform in your writeup and provide a short discussion of result
correctness.
The base tests from project 1 were reworked into the base test. It utilizes each of the activities upheld by our
pipeline, and we eliminated all information risks from the get together program. The program's beginning can be
seen in the waveforms above, where $sp is filled in and a few addi operations are performed and saved to $t0 and
$t1. I categorized the waveforms according to pipeline cycle and stage. As intended, the operations flow
downward and to the left. While the next PC+4, PC+8, is populating the pipeline stage before it, each PC+4
value is passed down the line. The waveform analysis reveals that every value is exactly where it ought to be, and
the testing is error-free. Each stage is isolated from the others in the section where active pipelining (multiple
operations going down the line without flushing) is performed, so there are no errors caused by stages interfering
with one another.

[1.c.ii] Include an annotated waveform in your writeup of two iterations or recursions of these
programs executing correctly and provide a short discussion of result correctness. In your
waveform and annotation, provide 3 different examples (at least one data-flow and one control-
flow) of where you did not have to use the maximum number of NOPs.
Beginning of program:

Halfway through execution:


At various points along the pipeline, the following operations can be seen in the aforementioned waveforms:
PC[-5] |lw $t0, 0($t8) #not noticeable however supportive for setting PC[-4] |lw $t1, 4($t8)
PC[-3] |nop PC[-2] |nop PC[-1] |nop
PC[0] |slt $t2, $t1, $t0
PC[1] |addi $at, $zero, 1 PC[2] |nop
PC[3] |nop PC[4] |nop
PC[5] |bne $t2, $at, preloop #branch not taken PC[6] |nop
PC[7] |nop PC[8] |nop
PC[9] |sw $t1, 0($t8)
PC[10] |sw $t0, 4($t8)
Likewise with the base tests, the waveforms are precisely true to form. In our execution of air pocket sort, the
processor loads $t0 = a[i] and $t1 = a[i+1]. It does not branch and saves a[i] = $t1 and a[i+1] = $t0 if $t1 is less
than $t0. Because a[i] and a[i+1] are equal to 2 in the preceding waveform, it does not branch or swap values.

The waveforms do not deviate from our expectations when analyzed. As long as there is no data inconsistency,
each pipeline stage remains isolated and free of interference. Correct operation of branches and jumps is made
possible by flushing the system.

The waveform demonstrates that only three nops are required for data dependencies, which do not necessitate a
full flush for regular instructions.

[1.d] Report the maximum frequency your software-scheduled pipelined processor can run at
and determine what your critical path is (specify each module/entity/component that this path
goes through).
The software pipelined processor's critical path is highlighted in red and has a numerical value of
17.23 nanoseconds, or 58.05 MHz. The basic way goes from the ID/EX register, into the ALUsrc
mux, through the principal ALU, and closes at the EX/MEM register
.
[2.a.ii] Draw a simple schematic showing how you could implement stalling and flushing
operations given an ideal N-bit register.

[2.a.iii] Create a testbench that instantiates all four of the registers in a single design. Show that
values that are stored in the initial IF/ID register are available as expected four cycles later, and
that new values can be inserted into the pipeline every single cycle. Most importantly, this
testbench should also test that each pipeline register can be individually stalled or flushed.

Our hardware-scheduled processor does not have the ability to stall or flush individual
registers.

[2.b.i] list which instructions produce values, and what signals (i.e., bus names) in the pipeline
these correspond to.

[2.b.ii] List which of these same instructions consume values, and what signals in the pipeline
these correspond to.
[2.b.iii] Generalized list of potential data dependencies. From this generalized list, select those
dependencies that can be forwarded (write down the corresponding pipeline stages that will be
forwarding and receiving the data), and those dependencies that will require hazard stalls.

Dependency which Requires Hazard Stalls Dependency that can be forwarded

s_writeAddr_ID, s_readAddr1, s_writeAddr_MEM, s_readAddr1,


s_writeAddr_EX, s_readAddr2, s_writeEnable_MEM, s_readAddr2,
s_writeEnable_ID,
s_writeEnable_EX,

In order for a dependency to be registered, the writeEnable must be enabled during the same cycle and either of
the readAddr wires must match a writeAddr value.

[2.b.iv] Global list of the datapath values and control signals that are required during each
pipeline stage.

s_PCPlusFour_ID, s_PCPlusFour_EX, s_PCPlusFour_MEM, s_PCPlusFour_WB,


s_DecodeData1_ID, s_finalJumpAddress_EX, s_finalJumpAddress_MEM, s_finalJumpAddress_WB ,
s_DecodeData2_ID, s_branchAddress_EX, s_branchAddress_MEM, s_branchAddress_WB,
s_imm32_ID, s_RegOutReadData2_EX, s_DMemOut, s_memReadData_WB,
s_jumpAddress_ID, s_aluOut_EX, s_aluOut_MEM, s_aluOut_WB,
s_RegWrAddr_ID, s_RegWrAddr_EX, s_RegWrAddr_MEM, s_RegWrAddr,
s_Ctrl_ID, s_ALUBranch_EX, s_branch_check_MEM, s_branch_check_WB,
s_Ovfl_EX, s_Ovfl_MEM, s_Ovfl,
s_jal_EX, s_jal_MEM, s_jal_WB,
s_MemtoReg_EX, s_MemtoReg_MEM, s_MemtoReg_WB,
s_DMemWr_EX, s_RegWr_MEM, s_RegWr,
s_RegWr_EX, s_jump_MEM, s_jump_WB,
s_Branch_EX, s_Halt_MEM, s_Halt
s_jump_EX,
s_Halt_EX,

[2.c.i] List all instructions that may result in a non-sequential PC update and in which pipeline
stage that update occurs.

Instruction Pipeline Stage

beq, bne, j, jal, jr WB

[2.c.ii] For these instructions, list which stages need to be stalled and which stages need to be
squashed/flushed relative to the stage each of these instructions is in.

The processor will not load an instruction if there are already any branching or jumping instructions in the pipeline because
our Hazard Detection module is inside the Fetch stage of the pipeline. As a result, the processor will stall and wait for the
hazard to resolve itself without having to squash or flush any stages.
To respond to the inquiry, potential stages IF, ID, EX, and MEM might have to stand by while the leap guidance is in the
WB stage.

[2.d] Implement the hardware-scheduled pipeline using only structural VHDL. As with the
previous processors that you have implemented, start with a high-level schematic drawing of the
interconnection between components.

[2.e – i, ii, and iii] In your writeup, show the Modelsim output for each of the following tests,
and provide a discussion of result correctness. It may be helpful to also annotate the waveforms
directly.
[2.e.i] Create a set of assembly programs that exhaustively test the data forwarding and
hazard detection capabilities of your pipeline. Create a spreadsheet to track these cases and
justify the coverage of your testing approach. Include this spreadsheet in your report as a
table.

We developed a comprehensive testing program that simultaneously presents the


processor with examples of each and all three. It works well with our processor.

From EX/MEM and MEM/WB, we can see instances of forwarding and stalling in the
preceding example.

[2.e.ii] Create a set of assembly programs that exhaustively tests control hazard
avoidance. Create a spreadsheet to track these cases and justify the coverage of your
testing approach. Include this spreadsheet in your report as a table.
Type Description Example

Jump Invariably change PC j loop

Branch Conditionally change PC bne $t0, $zero, example

Branch example:
The testing program utilized a lot of hops and contingent branches, the processor experienced no blunders, and
investigation of the waveforms shows no issues.

[2.f] Report the maximum frequency your hardware-scheduled pipelined processor can run
at and determine what your critical path is (specify each module/entity/component that this
path goes through).

The basic way of the equipment pipelined processor emerges to 18.41 nanoseconds which is a
recurrence of 54.32 MHz. The hazard detection unit, the Instruction memory, the pcReg register,
and the IF/ID register are all destinations along the critical path.

You might also like