CSE 141L Lab # 4 - Build a "Dewey Decimal" machine

Due the week of June 2.

Even newer (6/5) information

Some people have been experiencing problems with LogicWorks crashing on the Macs when they try to make a ROM with more than about 40 entries. There are two possible solutions:

New (as of 5/31) instructions

If you haven't already done so, send email to carter@cs giving two possible times between Wednesday and Friday when your group would like to give its presentation. (Note: the "early-bird special" is no longer available.)

Before your presentation, run and time the "15x15 benchmark". By this, I mean that you should run your multiplication program to multiply 15 times 15, and count both the number of cycles it takes and the number of instructions that are executed. You should tell us these numbers (and the CPI) at your presentation.

For your demo, you will need to have some method of setting a couple of memory cells in RAM to values that we suggest. Also, there should be some way to set the program counter to an arbitrary number.

We suggest that the first instruction in memory be a "Pause" instruction, then have your multiply program (ending with a "Pause"), and then the list-max program.

Some (possibly) Helpful Hints

There's a problem with our ROM-creation technology. Check this out.

How to construct a mux with as many inputs and outputs as desired.

When creating a RAM, you can set "Chip Enables" to 0 and don't select any of the "Miscellaneous Options". The RAM will have an active-low write enable. Most likely, you'll NAND your clock with your MemWrite control signal, and attach the NAND's output to the RAM's write enable.

It's best to have only one clock device in your design. If you have more than one, there is no guarentee that their outputs will always be the same.

Pre-5\31 stuff

Each group will present their project to one or more of the staff in an individually-scheduled meeting sometime during the last week of classes. (You will NOT be presenting your project to the whole class.) You'll have roughly eight minutes to describe the highlights of your design, five minutes to demonstrate that it works, and five minutes of questions.

The primary grading critera is that the project works. I expect that a completely working project, no matter how ugly, is worth a B+. The remaining grade will be based on whether it appears to be a "good" design, and on whether you (as a group) appear to really understand the project. These components of the grade are to some extent subjective on the part of the grader.

Giving a good "sales talk" in the presentation will help, but we care about content, not appearance (don't waste time making beautiful pictures with fancy fonts). You should (briefly) tell us what you think are the good features of the design, or what you would change if you had to do it again. Did you make design decisions or changes that were intended to make the cycle time short? To make the programs short? To make the circuit have a small number of components? Are there things in your implementation that you are particularly proud of?

We won't be "picking on" any member of the group. You can have one person do all the talking if you wish, or divide up the presentation and questions any way you want. It isn't even absolutely necessary for all group members to be at the presentation, though it is recommended.

Overview

In this lab, you will

You should do the lab in groups of up to four people. Four-person groups are encouraged, both because there will be a lot of work, and because it's good to learn to work with others.

Some details

  1. You should use a "multicycle" implementation, as described in the second half of Chapter 5 of the text book.

  2. Even though your architecture can have 1024 Tytes of memory, the machine you build should have only 256 Tytes. This first 128 Tytes should be a ROM. (This will allow you to load your programs in the ROM, and not lose the code every time you exit LogicWorks.) The remaining 128 Tytes of real memory should be RAM.

    Thus, you have to make a one-port "Memory" in Logic Works, with busses for ReadAddress, WriteAddress, WriteData and MemData, and control lines MemRead and MemWrite. If the high-order three bits of the ReadAddress are "000", then remaining seven bits specify the address in ROM. If the high-order bits are "001", then the other bits specify an address in RAM.

  3. Here are instructions and a tarfile for constucting ROM's in LogicWorks. The files are also in the ieng9/cs141s/public/Lab4 directory on the lab computers.

  4. We've created a control unit, minus your "Microcode ROM" and "Dispatch ROM". The recommended way to get the design is to sit down at one of the MAC's in a lab, and use the "Fetch FTP" program which is in the communications folder on the hard drive. After double-clicking on Fetch FTP and telling it ieng9 and your userid and password, get the file ../public/Lab4/control.cct.bin. You should use "MAC 2" format (rather than "raw data"). Be sure to fetch the .bin file, so that the MAC identifiers will be preserved. The other file will make the MAC crash when you try to load it from LogicWorks. Once you have the file on the MAC, you can use it there or download it to a floppy which, with luck, will work on other machines.

    There is also the file cs141s/public/Lab4/control.cct (without the .bin). This may work on PC versions of LogicWorks, but I haven't tried it.

    You may also try to download control.cct.bin and/or control.cct from here, but I haven't tried this method and have little expectation that it works.