Homework 3

Homework 3

Due 02/28
Weight: 15%

Overview

• Problem 1 is design of simple datapath component
• Problem 2 is a simple problem that stresses state machines
• Problem 3 is a simple design improvement and learning to synthesize a module

Provided Files

• A tarball is provided that includes testbenches and top level module definitions for all verilog problems: hw3.tar
• Do not edit the provided *_hier.v files

Handin Instructions

• You must maintain the directory structure that exists in the provided tar file, i.e. each problem has its own subdirectory titled hw3_[1,2,3]
• All verilog files required to run your verilog must be in each problem's respective subdirectory. You may also need to have copies of some files in each directory.
• Once you are done with a problem, run the command vcheck-all.sh in the problem directory to make sure that you adhere to the Verilog Rules. See Verilog rules check for more details.
• A legible schematic.pdf file must be in each problem's respective subdirectory with the schematics you drew.
  • Any solution without a corresponding schematic drawing will NOT be graded
  • A scanner is available for general use in Wendt Library
• The partners.txt file at the top level of the tarball must contain the names of yourself and your partner.
• Submit only this tar file named hw3.tar - only one partner needs to submit the file

Getting started

• For each problem follow the steps below in sequence:
  1. Break down your design into sub-modules.
  2. Define interfaces between these modules
  3. Draw paper and pencil schematics for these modules (these will he handed in as scanned schematic.pdf file)
  4. Then start writing verilog
• Use the wsrun.pl script to simulate your Verilog code. See wsrun.pl detailed usage instructions for more details.

---

Problem 1

Using Verilog, design an 8 -by -16- bit register file. See the verilog interface below. It has one write port, two read ports, three register select inputs (two for read and one for write,) a write enable, a reset and a clock input. All register state changes occur on the rising edge of the clock. As always, your basic building block must be the D-flipflop given in the Homework modules provided page. The read ports should be all combinational logic. Do not use tri-state logic in your design.

Design this register file such that changing the width to 32-bit or 64-bit is straightforward

The read and write data ports are 16 bits each. The select inputs (read and write) are 3 bits each. When the write enable is asserted (high) the selected register will be written with the data from the write port. The write occurs on the next rising clock edge; write data cannot flow through to a read port during the same cycle.

There is no read enable; data from the selected registers will always appear on to the corresponding read ports.

The reset signal is synchronous and when asserted (active high), resets all the register values to 0.

You must use a hierarchical design. Design a 16-bit register first, and then put 8 of them together with additional logic to build the register file.

Do not make any changes to the provided rf_hier.v file.

Testbench instructions

You must verify your design using the testbench in the supplied tar file. Run the testbench in your hw3_1 directory using the command wsrun.pl rf_bench *.v

The testbench for this problem (rf_bench.v) generates a random set of input signals to your module in each cycle, and compares outputs from your module with outputs that are expected from a perfect register file implementation.

If there are no errors in your design you will see a "TEST PASSED" message. If the testbench failed with a "TEST FAILED" message, look for error messages like "ERRORCHECK: Incorrect read data in cycle <cycle_number>" in the testbench output. Above each of these error messages you will see the inputs to your module, your outputs and the expected outputs for that cycle which can help you debug.

---

Problem 2

Using Verilog, write, compile and simulate a six state saturating counter. The counter should take as input a clock and a reset line (ctr_rst), and output a 3-bit wide bus (and an err output). Reset is synchronous and sets the output to 0 at the rising edge of the clock. ctr_rst is not the same as the global reset signal generated at the start of simulation. The output should increment every clock cycle until it reaches its saturation value (5, i.e. 101 in binary) and then continue to output the maximum value until reset. ctr_rst is different from the global rst signal which is set high at start for 2 cycles and then remains low. Use this global rst signal to initialize the state of the counter to zero. The "err" output is a standard way of indicating hardware errors or illegal states. Assert it (1'b1) for states which are supposed to be impossible to get into.

The ctr_rst line is active high, i.e. a logical value of 1 will reset the counter, while a logical value of 0 will let the counter increment.

If ctr_rst is high while the counter is still counting, the output should reset to 0. If it is held high, the counter should hold at 0. All state changes should occur on the clock's rising edge.

Do not make any changes to the provided sc_hier.v file.

Testbench instructions

You must verify your design using the testbench in the supplied tar file. Run the testbench in your hw3_2 directory using the command wsrun.pl sc_bench *.v

The testbench for this problem (sc_bench.v) randomly asserts ctr_rst, and compares outputs from your module with outputs that are expected from a perfect saturating counter implementation.

If there are no errors in your design you will see a "TEST PASSED" message. If the testbench failed with a "TEST FAILED" message, look for error messages like "ERRORCHECK: ctr_rst = xx : out = xx : expected_out = xx" in the testbench output. These lines show the input to your module (ctr_rst), your output and the expected output which can help you debug.

---

Problem 3 Part (a)

In Verilog, create a register file that includes internal bypassing so that results written in one cycle can be read during the same cycle. Do this by writing an outer "wrapper" module that instantiates your existing (unchanged) register file module; your new module will just add the bypass logic. The list of inputs and outputs of the outer module should be the same as that of the inner module.

Do not make any changes to the provided rf_hier.v file.

Testbench instructions

You must verify your design using the testbench in the supplied tar file. Run the testbench in your hw3_3 directory using the command wsrun.pl rf_bypass_hier_bench *.v

The testbench for this problem (rf_bypass_hier_bench.v) generates a random set of input signals to your module in each cycle, and compares outputs from your module with outputs that are expected from a perfect register file bypass implementation.

If there are no errors in your design you will see a "TEST PASSED" message. If the testbench failed with a "TEST FAILED WITH xx ERRORS" message, look for error messages like "ERRORCHECK: Read data incorrect in cycle <cycle_number>" in the testbench output. Above each of these error messages you will see the inputs to your module, your outputs and the expected outputs for that cycle which can help you debug.

Problem 3 Part (b)

Read the synthesis tutorial on the Synthesis page.

Synthesize your new register file (in the same hw3_3 directory).

Synthesis will create the synth directory which will include rf_bypass.syn.v, area report, timing report, etc. Do not delete this directory - it must be included in your submission. Make sure that in the area report no cell has an area of zero

---

Problem 4

Do problem 4.7

---

Problem 5

Do problems 4.8

---

Problem 6

Do problem 4.9

---

Problem 7

Do problems 4.1.1 to 4.1.3 in page 357 of textbook.

For 4.1.1, In addition to the control signals RegWrite, ALU operation, MemWrite, MemRead and Branch, you should also report the control signals of the following two control signals:

• ALUMux: the control signal that controls the Mux at the ALU input, 0 (Reg) selects the output of the register file and 1 (Imm) selects the immediate from the instruction word as the second input to the ALU.
• RegMux: the control signal that controls the Mux at the data input to the register file, 0 (ALU) selects the output of the ALU, and 1 (Mem) selects the output of memory.

---

Problem 8

Consider a single-cycle computer design such as the one in Figure 4.15 of text (page 263). Assume a MIPS-like instruction set. Suppose you had just completed such a design, and now the compiler group has come to you with a small list of additional instructions they would like you to add. How would you respond? Order the list from easiest to most difficult to add, based on the number of things that would have to change in the datapath; briefly indicate for each one what those changes would be.

1. "Split Register": This instruction would read an operand from $rs and move its lower half to $rd with the upper half set to zero. It would also take the upper half of $rs, shift it right 16 bits (with zero fill), and write it to $rt.
2. "Bit Equal": This instruction does a bit-for-bit compare between two registers. For each bit i, if bit i of $rs is equal to bit i of $rt, set bit i of $rd; otherwise set bit i of $rd to zero.
3. "Replace Under Mask": This I-Format instruction uses the 16-bit sign-extended immediate to select which bits of $rt should be replaced with the corresponding bits of $rs. For each bit of the sign-extended immediate that is a one, the result comes from the corresponding bit of $rs; for each bit that is a zero, the result comes from $rt. The result is written to $rt.

---

Problem 9

For this problem, you do not need to use mentor or Verilog; just draw the designs (neatly!) on paper.
First, design a 4-bit ripple-carry adder; as a building block use squares representing full adders. (You may use a printout from Homework 1.)
Next, draw an 8-bit carry-select adder, using as building blocks (three) 4-bit ripple-carry adders and 2:1 muxes.

Now, calculate the delay at output S₅ of the carry-select adder. To do this, you will need to know the gate design of the full adder and the 2:1 mux (see below). You will also need to know the delay function:
AND, OR, NAND, NOR, NOT: delay = (8 + n²) τ
XOR: delay = (12 + n²) τ
where n is the number of inputs to the gate.
Assume that all inputs to your design are available at time zero. Calculate (and mark on your paper) the pertinent critical-path delays through the basic building blocks, through your ripple adder, and finally to S₅ of the entire design.

---

Problem 9

This problem does not require verilog implementation. You should work to create a neatly drawn schematic.

Consider the division algorithm in Figure 3.10 (page 238) of the text and the accompanying high level diagram in Figure 3.9 (page 237). For this problem create a working and detail schematic with hierarchical design implementing this bit-wise divider. Simply reproducing Figure 3.9 will earn you negative points :-)

If you feel there is ambiguity in the problem specification, make reasonable assumptions and start your answer stating all your assumptions.

• Break your design into different blocks (Like in figure 3.9)
• The schematic should include
  • The names and bit widths of external ports of the design
    • Think about how the values of dividend and divisors are going to be initialized.
    • Do you need any control signals for the inputs?
    • Do you need any output ports?
    • How would another module interact with the divider module? Do you need a control signal to notify that the divide operation is completed?
  • The name for each block
  • The names and bit widths of interfaces between blocks.
• You will be graded based on:
  • the correctness of the design
  • the completeness of the design
  • If a team of 4-5 engineers were to implement (each person in charge of one block) the design in verilog, your design document would function as a reference for this team. They should be able to complete the implementation without talking to you or talking to each other. This requires that the interfaces are marked clearly, with meaningful names and bit widths.

---