CSE 141L Project 3: Single-cycle CPU

Due Thursday, August 31st September 7th the beginning of class.

Introduction

In this project, you will finally design a single-cycle implementation of a processor to execute your 9-bit ISA. Using LogicWorks, you will construct a complete datapath using the CPU internals – ALU and internal storage – from Project 2, build control logic for your datapath, and demonstrate your processor executing the programs you wrote for your ISA in Project 1.

At a minimum, your design will have a program counter (PC), a PC incrementer, instruction memory, data memory, your ALU, control logic, and your internal storage. Your ALU and internal storage should not be significantly changed from Project 2.

Design Requirements

• Use hierarchical design (sub-circuits) to make your design easier to understand and think about. The highest-level schematic should contain mostly functional blocks – your ALU, internal storage, memory blocks, control block, etc. – with most of the details hidden in sub-circuits. If you can fit each schematic on a single printed page without extreme scaling, you've likely done a good job here.
• Isolate your control logic. As a specific instance of the "hierarchical design" requirement, follow the text's lead by generating all control signals in one place from the opcode. This should make the design easier conceptually, at least. You'll likely have a big sub-circuit labeled "Control" which takes instruction bits as inputs, and emits all of the control signals for your datapath.
• You will create ROM(s) to hold instruction memory and a RAM to hold data memory. Both will be pre-initialized; the ROM(s) to hold your programs, the RAM to hold your input data. We'll post instructions to help you out.
• Note: your instruction memory (ROM) will be 9-bits wide; that is, it will have 9 output lines, and every instruction will occupy one memory address. The "Next PC" operation is then adding 1 to the PC.
• You can actually create three ROMs for your three programs, and swap them in and out of your design as needed. To avoid having to change your circuit between programs, you may optionally create an "Instruction Memory" sub-circuit which holds your three ROMs, and uses a "Program Select" mux (controlled by the user) to choose between them. Alternatively, you may create a single ROM which holds all of your programs, and use different initial values for the PC.
• You must have an "init" signal that sets the PC appropriately to begin execution of your programs. The "init" signal is controlled by the user. You must also have a "done" signal that goes high at the halt instruction (and not sooner).
• You must implement the "halt" instruction. When executed, it will assert the "done" signal, and force the PC to remain at that same halt instruction.
• You must have a hardware cycle counter that we will use to reliably determine dynamic instruction counts. It must initialize to 0 at the "init" signal, and count up by 1 each cycle until the "done" signal is asserted, at which point it stops counting. Your cycle counter must be wide enough not to overflow: if your highest instruction count is 1000, for instance, you'll need at least 10 bits for your cycle counter.
• Wire your cycle counter count outputs to hex display blocks, to allow easy measurements.
• Bear in mind that you may have to debug your programs, as well as your hardware! Think about how to make your life easier in this regard, before it happens.
• Remember that it is your responsibility to convince us that your CPU works, not our responsibility to figure that out ourselves. Providing sufficient, clear results and information is crucial.

What To Turn In

Each group will turn in, on paper, a printed report with attachments:

• A summary of your ISA: what instructions you offer, what instruction formats you use, what operations they perform, how your internal storage is addressed, etc.
• Answers to the questions (see below).
• Commented assembly code for your three programs.
• Machine code for your three programs; use hex to encode the assembled instructions. Be sure to indicate the PCs corresponding to your instructions.
• LogicWorks schematic diagrams of all of your circuits. Include all of your parts here, even sub-circuits you've already detailed in Project 2.

• Timing diagrams for each program demonstrating the correct operation and other important data. These diagrams must at minimum show results being generated (e.g., the checksum values being calculated at each step, the word count increasing, etc.), the PC, and the cycle counter. You do not need not show the whole execution of the program – please do not include massive diagrams showing hundreds of cycles of execution! – but your diagrams must show the beginning and end of execution, including where the final results are written to memory. Your diagrams must also demonstrate key steps used in each result calculation, as previously mentioned.

  Once again, your timing diagrams should be heavily annotated so we can figure out what is going on.

Report Questions

As part of the above turn-in items, be sure to answer all of the following in your typewritten report.

Note that, this time around, we're asking you to reflect upon and critique your design, and consider how you might change it given different design goals. We're after insightful analysis here, not marketing material. For example, if you made a decision in your ISA design which made programming difficult, then detail that in the appropriate question; you won't lose credit for being honest about what you would have changed!

1. Have you made any changes to your ISA from lab 1? What were they? Why did you make them?
2. What are your dynamic instruction counts for program 1? program 2? program 3?
3. What could you have done differently to better optimize for dynamic instruction count?
4. How successful were you at optimizing for ease of design? Give examples.
5. What could you have done differently to better optimize for ease of design? What, if any, impact would these changes have had on your dynamic instruction counts?
6. How easy or difficult would it be to extend your design to a multi-cycle implementation? How about a pipelined implementation? Give examples.
7. What might you have done differently if ease of programming was a design goal? Give examples.
8. Which instruction takes the longest on your machine, thus dictating the cycle time? Use some kind of rough estimates here, perhaps assuming each device introduces a constant delay. (It's alright your answer is basically the same as the answer you gave to the corresponding question in Project 2.)
9. What might you have done differently, if having a short cycle time was a design goal? (As above, use rough estimates.) Give examples.

Program Inputs

Your program will read inputs from pre-specified addresses in RAM; RAM will start out initialized with these values. You may actually use the same RAM image for all three programs, as long as no program writes to memory addresses used as inputs by any program.

(Within the following table, "address" indicates the byte address of the leftmost value, and addresses increase from left to right. For example, address 0 contains hex value FF, address 1 contains hex FE, etc.)

Watch the Web!

Finally, be sure to keep an eye on the course web page, and WebBoard. We'll likely end up posting updates, corrections, hints, etc.