The purpose of the project is to let you do some individual work on a topic that is relevant for the Computer Architecture class. This work will involve using the knowledge gained in class, through your readings and through the process of trial and error involved in everything people design. Your work includes both hardware and software design: this way you will better understand the tradeoffs involved in the design process.

Alternate topics are possible. If you want to do something different, please get in touch with your instructor.


Design the hardware and the Instruction Set for an architecture defined as follows and show that your design is useable.

The hardware design includes the datapath and the control unit at the register level. Showing that the design is useable means that you'll have to write a piece of software using the Instruction Set you have chosen. Here is a list of software projects you can choose from. Since each project can be assigned only once, please check with your instructor to make sure the topic you like is still available. If you would like to do something different then you will need your instructor's approval (in any case the program must involve doing I/O and handling data objects larger than 4 bits).

Please be aware that the description of the architecture is incomplete, and that you are supposed to fill in the missing parts.


A 4 bit opcode for instructions seems to be the natural choice: but in this case you must very carefully choose what you want to include in the instruction set and what you leave aside. Remember that you must prove your design can be used.

Also due to the small amount of memory, you must be very careful in choosing the addressing modes: going with only one, say 'memory direct' might make instructions pretty large (this consumes memory and lengthens the fetch time), while choosing several has implications on the instruction encoding.

With such a simple CPU you don't expect to build big: a typical system would probably have some of the memory space dedicated to a ROM and what's left to a RAM. At power-up or at reset the CPU starts reading instructions from address 0. Low addresses could then go in the ROM; in this memory area could be your whole application or just a simple loader that reads your application from I/O (read into the RAM) and, after that, transfers control to the loaded program.

I would suggest that the I/O is memory mapped; this saves opcodes (at the very least).

What to turn in for the preliminary report

The preliminary report is due around mid-semester. By that time students should have a quite clear idea of how the project will look like.

Each team will turn in a PowerPoint presentation showing how instructions are executed by the datapath in connection with the memory. There will be at least one arithmetic instruction and one control instruction (brach, jump, etc).

What to turn in when the final project is due

Three things:

A) A paper (whose format is described in appendix A) that describes:

B) A program written using your instruction set. All programs will be written assuming an assembler is available: see appendix B for more details. Using your piece of software, you will calculate the average CPI of your machine.

C) A PowerPoint presentation describing your work.


Students are encouraged to work in groups no larger than 2: cooperation is the key and, hopefully, after you finish this project, you'll know much better how to share responsabilities and rewards.

Students must defend their projects individually even if they work in groups. Team members are supposed to have a good knowledge of the whole project, and a very good knowledge of what they've been in charge for. There is no guarantee that both members of a team will have the same final mark for the project.

Students may choose their teammates no later than specified in the syllabus. After that date the instructor will assign the teams.

Appendix A: The format of the paper you turn in

The front page will contain (in this order)

The rest of your paper must include:

Except for the front page and appendices, all other pages will have the format described in the syllabus.

Appendix B: Assembler conventions

As you write assembly language programs, it is important to keep your code and data separate; you probably don't want to execute your data, neither want you to modify your instructions. Most assembler provide 'assembler segments' as a way to help you maintain the distinction between data and code: each segment holds a distinct set of objects:

Here is a list of directives the assembler should understand

       Directive       Meaning
       .data           start data
       .text           start text (instructions)
       .4bit           initialize a 4-bit data
       .byte           initialize a byte
       .half-word      initialize a 16-bit data
       .word           initialize a 32-bit data
       .ascii          initialize with a string of chars
       .reserve        reserve a block of uninitialized memory

And here are some examples:

       .data   0x100   # start this at the address 0x100
a:     .4bit   3       # a is a 4-bit data with the initial value 3
b:     .word   666     # b is 32-bit wide with initial value 666
c:     .ascii "cs470"  # c is the null terminated string "cs470"
d:     .reserve 8      # reserve 4 bytes (8 4-bit) for d
       .text   0x200   # start code at 0x200 (the value is optional)
       ..........      # your code

Prepared by Virgil Bistriceanu. Last modified 2/15/97