CS152: Computer Architecture

Final Project

Prof. Bob Brodersen

Team Evaluations on final project

As before, you will be evaluating your team members' performance.  Remember that points are not earned only by doing work, but by how well you work as a team. So if one person does all the work and makes it difficult for others to help out, that certainly does not mean he/she should get all the points!

Split up a total of 100 points between the members of your group (including yourself!). Submit your evaluations to your TA  before 5/15, 11:59 pm.

Description:

This is the final lab for the course project, for which you will make various enhancements to your processor to enable execution of a DSP algorithm at high performance with minimum energy consumption.

This lab will be graded based on the functionality and energy consumption of your design. A functional processor is one that can execute the given DSP benchmark program correctly and within the given time specs.  We can't stress this enough -- if your processor does not work, your grade will be certainly reflect this.  Please note that all the features of Lab 5 must also be functional  in this lab. You don't need to implement a cache, but still use the ZBT RAM of Lab 6 as your memory. 

Please take a good look at the due dates for this assignment. You will send your final report and a copy of your slides to the staff mailing list (cs152@cory.eecs.berkeley.edu) by 11:59PM on 5/15 (the night before the presentations).  Be sure to meet this submittal time and get some sleep so you can do a good oral presentation! . Submit all the relevant files electronically as before, and make sure there is an HTML report file named "report.htm". In class, you will give a 15-minute oral presentation of your complete design as a group- each person should talk for 5 minutes and we will have 5 minutes of questions . 

Grading:

The grade will have 3 parts: 50% on your basic design which includes functionality and what tradeoffs you explored. 25% will be on your final report, how it  explains what you did and why. 15% on your final oral presentation and 10% on how low a power level you achieved in your design. If your design doesn't meet the timing specification you won't receive any points for energy minimization.

All project related files are in the directory v:/cs152/project 

Step 1: Enable DSP support in your datapath

As discussed often in lecture, digital signal processing applications have very different characteristics than traditional user-based general purpose programs. One of the most important differences is that most DSP applications have a fixed real-time requirement, such that the process absolutely must run in a certain amount of time to be useful, and it does no good at all to run any faster. It is this characteristic that allows us to scale voltage and reduce power/energy consumption without "sacrificing performance" (since it does no good to go faster than the requirement).

In this project, you will be running a very simple DSP benchmark using one of the most common kernels: the FIR filter operation. An FIR (finite impulse response) filter is used extensively in all types of signal processing, such as pass/stop filters, equalizers, and echo cancellers to name a few. For more information on FIR filters, look at this FIR filter document.

There is only one DSP instruction you need to implement to support our benchmark:

mac $rd, $rs, $rt => $rd = $rd + $rs[15:0] * $rt[15:0]

MAC (which stands for multiply and accumulate) is an R-type instruction, with opcode = "000000" and  function code = "000101".

You will need a 16-bit multiplier to implement the instruction. You can choose from the following options

• Array multiplier with no internal pipelining
• Array multiplier with one internal pipeline stage
• Array multiplier with two internal pipeline stages

Implement the MAC unit and integrate it into your processor. You don't need to worry too much about your choice at this point. You'll have a chance to improve performance and energy later (remember, get it working first, and then optimize!).

Step 3: DSP Benchmark of your initial processor

Now you are now ready to run the DSP benchmark for an initial assessment of your processor's performance and energy consumption. As mentioned above and in the FIR background document, the DSP benchmark program we use is a 21-tap FIR high-pass filter.

The assembly file of the FIR filter is named "dsp_bench_spim.s" Since SPIM does not have a MAC instruction, the MAC instruction has been translated into three instructions. However, the assembly code you are going to run on your process is named "dsp_bench.s", which has the MAC instruction. The instruction memory file has already been translated as "dsp_bench.mem". You do not need to run mipsasm on "dsp_bench.s" again.

Run the DSP benchmark program in ModelSim with post place & routing VHDL simualtion. You must calculate and record the total execution time of the benchmark, the total energy consumed by the program, and the average power consumption.

Step 4: Make your design meet the performance spec and consume minimal power.

DSP Bench Mark Program Maximum Execution Time: 1.5ms

You probably will notice that your initial processor not only does not meet the performance requirement, and also consumes lots of energy. In this final and important step you are going to make advanced enhancements to your processor such that it can meet the performance spec and consume as little energy as possible. Here are some tips for lower energy consumption:

• Power-delay tradeoff - When voltage is lowered, each component will have a longer delay but consume less energy/transition (we will call this quantity also POWER for simplicity, but remember it has units of Joules/Transition ). So given the power-delay model with static voltage scaling, choosing a lower voltage becomes one way to reduce the power consumption as long as your processor still meets the performance spec. Most likely, choosing lower and lower voltages will require more and more enhancements to improve the performance. All components must use the same supply voltage, and at all times (no dynamic scaling)! Since XPower does not check the maximum clock rate when scaling voltage, you will need to manually scale your process's maximum clock rate according to the following table, only voltages specified below are allowed:

• Balance input signal paths: Unbalanced input paths can lead to unnecessary "glitches" which consume lots of "useless" energy.

• Gating the clock: Synchronous components can have a enable signal, which gates the clock and inputs. When disabled, the component will not consume energy. 

• Reduce the number of components used: Since every component will cost some power, minimize the number of components used, or use different components which take less power.

There are many ways to improve the performance of a processor, each of which affects a certain class of operations. Here we have a reasonable list of improvements you can make to your processor. Keep in mind that some of these designs will result in a huge increase in power consumption, but will allow you to scale down the voltage significantly and still meet the timing spec.

• Superscalar - Modify your processor to be 2-way superscalar. This means you must try to fetch and commit two instructions per clock cycle. You will decide whether to fully duplicate your datapath so that each path can support all instructions, or alternatively you can specialize each path so that only certain instructions can be dispatched in parallel. Think this one through carefully before committing to it, as it can be more of a setback than an improvement if not done correctly.
• Deep pipelining - Change your pipeline to have more stages, but with a shorter critical path. It is your choice how to divide the stages. The consequence is that you will have more complex hazard and forwarding conditions. Should you decide to divide the EX stage and pipeline the ALU, you may either design the ALU in gates, or change the VHDL so that it is divided into two separate components, each of which is purely combinational. You must provide a detailed analysis of how the delay will split between the two separate components, and they must add up to at least the delay of the original ALU.
• Branch prediction  - Implement any form of branch prediction (anything but always predict [not] taken) in your processor. Note that this will only help if your processor is designed so that more than one instruction is fetched before a branch destination is known (otherwise, there is no effect).
• Non-blocking loads  - Modify your data cache so that it supports a non-blocking load, also known as hit-under-miss. On a data cache miss on a load, your processor should continue (rather than stalling) until another miss occurs, or there is a dependency on the outstanding load value.
• Instruction stream buffer  - Modify your memory system to prefetch instructions via a stream buffer. On an instruction cache miss, fill the cache line requested and proceed to fetch the next sequential instructions into the stream buffer. On a subsequent cache miss, you may be able to quickly service the miss from the stream buffer rather than wait for memory. The size of your stream buffer is up to you.
• Victim cache  - Add a victim cache between the data cache and the SDRAM. A victim cache is a small fully associative set of registers which catches blocks that are ejected from the cache on a replacement. Note that on a data cache miss, you must check the victim cache for data before checking memory, or else you may get obsolete data. The policy for how to use the victim cache and the size is up to you. 
• Cache reorganization  - Since the benchmark has changed, reorganize your instruction and/or data caches. You may not add words to the overall size of your caches. You may trade words between the caches, and change anything about their policy or parameters.
• Jump target predictor  - Similar to branch prediction, add a feature to your processor that predicts the target of a JR instruction based on the PC address of the JR instruction.

You are welcome and encouraged to come up with your own idea for improving performance and lowering energy. However, make sure you talk to your TA ahead of time. A complex but non-functional processor will really hurt your grade.

Report and Presentation

As indicated above, the project report and the slides for your presentation  are due the night before the presentations. 

The final report and presentation should be a lot more formal than the previous labs. You should imagine that you are presenting a design review to the technical director of your company (you don't need to dress like it, though). Functionality check-off will be on the same day, and your processor must work completely. The time of the check-off will be posted.

In addition to all your performance results and analyses, we would like to see you describe why you made choices the way you did, as well as detailed explanations on how you made your improvements and what your challenges were. The presentation should be 10-15 slides summarizing what improvements you made, what results you achieved,  and what you learned or what surprised you. This will be broken up into three 5 minute talks, by each of the members of the team. Since there is only one grade be sure that all of your team does a good job!