cse141 Project 1: Design Your Own ISA


April 2 Update the Operand class in Assembler.java.
April 8 Add the slides presented in discussion section.
April 11 The 30th fibonacci number should be 832040.
April 15 The deadline is extended to April 24th.
April 20 Put some SuperGarbage applications.
April 21 The deadline is extended to April 28th.
April 24 add a halt instructions to the requirements
April 26 add some description about how to test the SuperGarbage VM.
April 27 add some more description about how to test the SuperGarbage VM.
April 27 update the input files and reference outs.

Due: 03:30pm, April 28

A Letter from Jake

From:Jake Ivring;          CTO UnicationITY, Inc.
To: Cob Bolwell;       Principle FlexGermanica Technical, LLC.

Dear Cob,

Our revenues are getting hit by the knock-off clones from our low-cost rival, Boatorola Corp. The business strategist from Underson Consulting says our only hope for survival is to patent every aspect of our product. However, since many of the components are standard, there is nothing to patent. We need to redesign each piece so that it explores non-standard parts of the design space, which being new, will give our patent attorneys fodder for patent filings. Then when Boatorola copies us, we litigate for patent infringement!

We are hoping that you can pull together a team that can provide us with a new instruction set architecture that looks novel enough that we will have ample material to patent. We suggest as a start that you use a 17-bit fixed instruction size and 34-bit word size; that combination may help you explore a new design space. Furthermore, Boatorola has access to the MIPS and SPARC patent portfolio, so try not to be too similar to them. Of course, our products still need to be competitive, so the ISA should be general purpose and reasonably efficient. Also, since the fuse is relatively short on this, you will need to keep it simple. Your compensation will be based on the correctness, novelty and efficiency of the end product.

Thanks in advance,



As you read in Jake's letter, you should save your company by designing a novel processor in one month. You will first focus on the design of your own ISA. Your ISA should be general enough to run all the provided benchmark programs, while being simple enough to allow you to implement a reasonably fast processor in the allotted time frame. Then, you will implement two essential components for architectural validation and verification -- assembler and simulator. An assembler translates your program written in your assembly language into binary code; a simulator performs a simulation upon a provided binary code. Collectively, they form essential infrastructure for your processor design. For the implementation of the assembler and the simulator, you are free to choose any high level language (including scripting languages).





It is difficult and error-prone to manually write machine code. To address this problem, people usually use an assembler, which automatically generates a machine code from an assembly file. Moreover, many C compilers first generate assembly files and then simply feed it to an assembler to get the executable machine code. For these reasons, you should write an assembler for your ISA. The assembler reads a program written in an assembly language, then translates it into binary code and generates two output files containing executable machine code. You will use the generated output files for both the simulator and the actual hardware you will implement.


Now that you have an easy way to generate machine code, it is time to implement a simulator. With a simulator, you can 1) easily verify your ISA without actually implementing hardware, 2) debug your application without having actual hardware, and 3) improve your ISA by spotting performance bottlenecks in benchmark programs. Your simulator operates instruction by instruction; you must be able to execute instructions one by one and watch all the programmer visible states (eg. register, memory, ...) at a certain time when the execution of an instruction is completed.

In this project, we also provide you a simple simulator framework to save your time in developing the simulator running your new ISA. You may find the detailed description about the simulator here. The source for the simulator framework is here


Two benchmarks are provided to help guide your ISA development. You need to write assembly programs based on your ISA for all the benchmarks. Assume that all the addresses (pointers) and data in the benchmark programs are 34 bit.

Before the Submission of Your Report

Before the submission of your report, you should evaluate your instruction set architecture and also revisit your design decisions if necessary.

The first evaluation of your design to pass is a simple instruction test. Write a simple assembly program which uses all the instructions in your ISA. Your ISA will be tested using SuperGarbage and Fibonacci benchmarks. Generate a COE file with your assembler, and verify that benchmark successfully handles all the instructions in a behavioral simulation. Try to make your test program as concise as possible while it covers all the instructions.

Since "instruction count" is one of the three factors affect the execution time, you should run all the benchmark applications and get the dynamic instruction count for each benchmark. You may use the 'count' command of your ISA simulator to get this number.

Late lab write ups

If you cannot complete you lab on time, you can turn it in late, but your grade will be penalized. The penalty is one letter grade per 24 hours extension. Up to 2 extensions are possible. For example, if the labs are due at 5pm, you have until 5pm the next day to turn it in with one letter grade penalty, and until 5pm the day after to turn it in with a two letter grade penalty, and so on.


  • Your team needs to submit a report, which should contain the following items:
    • The name of your ISA and detailed explanation (two pages or so) of your design decisions.
    • Instruction manual with instruction names, instruction formats, and RTL descriptions of functionality. It should also include opcode maps, as explained in the class. For the manual style, follow the figure below, which is drawn from the MIPS R4400 manual. However, it does not need to be so ornately typeset.
    • A description of all architectural (i.e. programmer visible) state (registers, stacks, memories, queues, etc)
    • Stack management and function call / parameter passing conventions
    • The two benchmark programs written in your ISA assembly language with heavy comments
  • Submit relevant zipped source files (including your assembler and simulator) via e-mail to TA. Your email title should be "[CSE141] project1, name0, name1, ...".

Due: 03:30pm, April 28