EEC 281 - Homework/Project #2

Work individually, but I strongly recommend working with someone in the class nearby so you can help each other when you get stuck, with

consideration of the Course Collaboration Policy. Please send an email to me if something is not clear and I will update the assignment using

green font.

Notes:

Submit: (1) all code you wrote (no generated or provided files) including verilog hardware, verilog testing, matlab, etc. (2) other requested items such as diagrams etc.

i. Upload a single pdf to https://canvas.ucdavis.edu/.

ii. Place all of your answers and code into a single pdf file with all problems and material in order.

iii. Add titles to pages and file names so it is clear to which problem they belong. For example, Problem 1, prob1.v, prob1.vt,...

Diagrams. If a problem requires a diagram, include details such as datapath, memory, control, I/O, pipeline stages, word widths in bits, etc. There must be enough detail so that the exact functional operation of the block can be determined by someone with a reasonable knowledge of what simple blocks do. A satisfactory diagram may sometimes require multiple pages of paper taped together into a single large sheet.

Verilog. If a problem requires a verilog design, turn in paper copies of both hardware and test verilog code.

*** Where three '*'s appear in the description, perform the required test(s) and turn in a printout of either:

1. a table printed by your verilog testbench module listing all inputs and corresponding outputs,

2. a simvision waveform plot which shows (labeled and highlighted) corresponding inputs and outputs, or

3. verilog test code which compares a) your hardware circuit and b) a simple reference circuit (using high-level functions such as "+")—no third circuit. Include two copy & paste sections of text from your simulation's output (one for pass, and one for fail where you purposely make a very small change to either your designed hardware circuit or your reference circuit to force the comparison to fail) that look something like this: input=0101, out_hw=11110000, out_ref=11110000, ok ... input=0101, out_hw=11110000, out_ref=11110001, Error! ...

For 1 and 3, the output must be copied & pasted directly from the simulator's output without any modifications.

In all cases, Show how you verified the correctness of your simulation's outputs.

Keep "hardware" modules separate from testing code. Instantiate a copy of your processing module(s) in your testing module (the

highest level module) and drive the inputs and check the outputs from there.

Synthesis. If a problem requires synthesis, turn in paper copies of the following. Print in a way that results are easy to understand but conserves paper (multiple files per page, 8 or 9 point font, multiple columns). Delete sections of many repeated lines with a few copies of the line plus the comment: <many lines removed> .

1. dc-<filename>.tcl (or equivalent)

2. *.area file

3. *.logs file (not command.log) Edit and reduce "Beginning Delay Optimization Phase" and "Beginning Area-Recovery Phase"

sections.

4. *.tim file; first (longest) path only

The "always @(*)" verilog construct may be used.

Run all compiles with "medium" effort. Do not modify the synthesis script except for functional purposes (e.g., to specify source file names).

Functionality. For each design problem, you must write by hand 1) whether the design is fully functional, and 2) the failing sections if any exist.

Point deductions/additions. TotalProbPts is the sum of all points possible.

[Up to TotalProbPts × 50%] point reduction for not plainly certifying/showing that your circuit is functionally correct. This

sounds drastic but you should have checked the correctness of your circuits' outputs anyway, it is impractical for the grader to