Project, Phase 2

CMSC 411 / Olano, Fall 2015

In this phase of the project, you will design a multi-cycle datapath for your design for your robot processor.

Constraints

We will use a simplified timing model where we count time as follows in terms of an arbitrary unit we'll call one gate delay.

Component Timing Notes
~ a free  
a & b 1  
a | b 1  
a ^ b 2 Same as (~a & b) | (a & ~b)
2-input mux 2 Same as (x & a) | (~x & b)
2n-input mux 2*n Same as n-levels of 2-input mux
Fixed shift (e.g. <<2) free Just moving wires
2n-bit ALU n+9 Carry lookahead adder + mux for logic (14 for 32-bit ALU)
Ripple-carry adder would be around 100 for a 32-bit ALU
Compare >=0, <0 free Just look at sign bit
2n-bit compare ==0, !=0 n Tree of OR's (5 for 32-bit compare)
Single register store 4 Data must be at input 2 delays before clock edge
Data available at output 2 delays after clock edge
Register file store (2n registers) floor(lg(n-1)) + 5 Select + register timing (7 for 32 registers)
Register file fetch (2n registers) 2*n Same as n-level mux (10 for 32 registers)
2n entry Decode / microcode table 2*n This is assuming an n-level mux. Can probably implement more efficiently, but I want to keep things relatively simple.
Memory lookup 350  
Robot operations 500 Time from A or D scan to answer.
Time between operations for M, R or F.

Simple logic gates are assumed to have just two inputs. For more inputs, use the timing to stack the simple 2-input ones. So a 4-input AND of a,b,c,d could be implemented as (a & b) & (c & d) for a total time of 2.

You can only have one memory unit, which must be shared for both instruction and data memory accesses.

You will have to choose a single fixed cycle time.

Registers (single or register file) can be written only on the rising or falling edge of the clock (beginning or middle of the cycle). It is OK to design some operations to span cycle boundaries. Memory or robot operations are internally clocked and latched. This means they can only start at the beginning of a cycle, with their input available within 2 gate delays of the cycle start. It is not necessary to maintain the input value for the entire memory or robot operation, only for the first half-cycle. Once their time is complete, any result will be available on their output through the end of the cycle when it is produced. Anything else spanning more than one cycle will need to have its input maintained (from a register or from other logic based on fixed register values) for the entire operation. So if you choose a cycle time shorter than the ALU operation time, you will need to make sure the inputs remain valid for the entire time, until the result is latched into another register.

What to do

Draw your datapath (electronically or by hand). Label individual delays for each element. Also label total maximum delay from start of clock cycle to each output. Someplace prominent, incude "Cycle time = x" for your assumed cycle time. If you do draw this figure by hand, scan it and check the scan into your project directory.

For each instruction from phase 1, write the set of RTL steps to implement it in your data path. You do not need to mention parts of the datapath that are not used in any cycle, but sure to mention everything that would need control signals. This can be a text file, word document, or spreadsheet named "RTL" with an appropriate file extension. Note plain text or spreadsheet saved as csv are the most git-friendly.

Submitting

Commit and push everything for this assignment in the same directory you used for phase 1. Write a new readme called readme-2.txt with anything you think I should know that is not in your datapath diagram or RTL file.