Design, implement and test a datapath according to the following figure:

I recommend you download the postscript version of this diagram as datapath-proj5.ps and print it. This will give you a more detailed picture. Down load this file an print it from one of the lab machines with the command lpr datapath-proj5.ps

We have discussed the design and operation of this data path in class. Your data path must behave in the same manner as the one we designed in class.

Design:

The design section of your design document should thoroughly describe the design you are using. Be sure to describe how the datapath functions and the purpose of each component. I might suggest discussing the instruction formats and tracing one instruction of each format through the datapath. You may borrow liberally from the class notes but do not assume the reader of your document is familiar with them.

Test Cases:

As with the last project exhaustive testing is not a practical option. You should apply a deductive approach to testing to ensure that all of the data path components are properly connected. This will include testing to be sure that each of the input, output, control and status lines of the data path are connected to the proper entities. To test your data path you will need to input data via the system bus, save it in registers, perform operations on it and output results via the system bus. The operations can be controlled by use of the microInst input.

Implementation:

Your implementation must contain at least two entities, one for the data path and one for the testbench. However, I strongly suggest that you implement several other entities and use them as components in your data path. While this may seem like more work it will be much easier to get your final design working if you attack it in this way. The entities that you create can have any name, PORT statement and filename that you choose.

Your dataPath ENTITY must be saved in a file called dataPath.v and must use the following ENTITY declaration:

dataBus:

The dataBus is the system data bus that connects the CPU to the main memory and other i/o devices. The dataBus is declared to be INOUT, this means that data may flow into or out of the entity on this signal. To use the dataBus to input data into the data path place the tri-state buffer in it high-impedance (switches open) state (enable = 0) and place the data on the dataBus. To read data out of the data path on the dataBus, place the tri-state buffer in its connected (switches closed) state. Tracing the dataBus signal in your test bench will reflect both data that is sent into or out of the data path on the dataBus. If you attempt to write data to the dataBus from both outside the data path and from the tri-state buffer at the same time the dataBus will become an unknown value ("XXX...XXX"). It may be the case the the dataBus will pass through high-impedance ("ZZZ...ZZZ") or unknown states when the enable line is changed from 0 to 1 or 1 to 0. You should be concerned with the steady state values after the propagation delay of the tri-state buffer.

addrBus:

The addrBus is the system address bus that provides the r/w address for the memory and other i/o devices.

busControl:

The four control lines that are used to indicate the type of bus cycle that is to be executed (Read/Write etc..)

busStatus:

The status lines that come back from the devices. This is where the i/o devices indicate their status such as when a r/w request has finished processing.

instruction:

The most significant 8 bits of the instruction register. This output will be used to provide an input to the micro-program control unit.

statusLatch:

The contents of the status latch. This is an output so that it can be sent to the micro-program control unit. This will allow micro-programs to monitor the status of the system (e.g. check for negative/zero results, i/o requests finished etc...)

microInst:

This will come from the output of the micro-program control unit. It contains bits for each of the necessary control lines in the data path.

For this project you must submit:

• A hard copy of the design document describing your project. ( Sample Design Document )
• All of the files containing the VHDL implementation of all of your entities.
• The test benches for your dataPath entity.
• A text file called datapath.txt that describes how to analyze and simulate your datapath. The datapath.txt file should list the files that need to be analyzed (in order). This files should also indicate what signals should be traced in your dataPath_test entity in order to produce your test results.

Files you may need for this project:

• New Files:
  • shifter32.v - VHDL Implementation of a 32 bit shift register.
  • tristate32.v - VHDL Implementation of a 32 bit tri-state buffer.
  
  
• Old Files:
  • lgates.v - VHDL Implementation of the basic 2 input logic gates.
  • lgates3.v - VHDL Implementation of 3 input logic gates.
  • lgates4.v - VHDL Implementation of 4 input logic gates.
  • dec.v - VHDL Implementation of various decoders.
  • mux.v - VHDL Implementation of various multiplexers.
  
  
• Old Project Solutions:
  
  Project #1: - Full Adder
  • fulladder.v - A full adder.
  Project #2: - One Bit ALU
  • bitALU.v - A one bit ALU.
  Project #3: - 32 Bit ALU
  • fourBitALU.v - A four bit carry ripple ALU.
  • zeroDetector.v - A 32 bit zero detector.
  • alu.v - A 32 bit carry ripple ALU.
  Project #4: - Register Bank
  • clockedD.v - A clocked D latch.
  • Dflipflop.v - A D Flip Flop.
  • latch32.v - A 32 bit leading edge triggered latch.
  • bus32mux4.v - A 4 input 32 bit bus multiplexor.
  • registerBank.html - A register with 16, 32 bit registers.