Proj2 Report-1-1
Proj2 Report-1-1
Level Programming
Project Part 2 Report
Project Part 2 Report
Camron Corcoran________________________________
Spencer Sutton______________________________
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.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:
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.
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.
[2.c.i] List all instructions that may result in a non-sequential PC update and in which pipeline
stage that update occurs.
[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.
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
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.