Project, Phase 2

CMSC 411 / Olano, Fall 2013

In this phase of the project, you will refine your functional simulator to simulate the behavior and timing of a processor organization with multi-cycle control.


Design your multi-cycle organization. Execute each instruction to completion before starting the next instruction. In other words this phase of the project should be multi-cycle, but not pipelined.

Your organization should obey the following rules: Any memory access (read or write) takes one cycle. Any ALU operation takes one cycle. Any robot control action takes one cycle. You can perform multiple single-cycle actions in parallel (e.g. by having multiple ALUs), but cannot chain them together without saving the intermediate value to a register and continuing execution in the next cycle (in this instance, I am referring to a generic temporary register, not necessarily one of the ISA-visible registers). Any data from one cycle that will be used in a later cycle must be saved in a register.

Any register write can be defined to happen at the rising clock edge (beginning of the cycle) or falling clock edge (middle of the cycle), but the inputs need to be stable before the write. For example, a if a register will store the results of an ALU operation at the end of a cycle, the ALU inputs need to be available at the beginning of the cycle. Any single MUX or simple control logic can be assumed to take negligible time.


Modify your simulator to perform one clock cycle action per "enter" following your multi-cycle design. You should printf("N\n") in any cycle that does not include a robot action. So, in your first cycle, you might fetch the first instruction and print N. The next several cycles would simulate that instruction. When the first instruction is complete, you fetch the second instruction. Use only the stages and cycles necessary for each instruction.

You should have explicit C variables for each temporary register. You should also create a function for each major block (e.g. call a function to read registers or to compute the ALU operation), but can simulate the functioning of each block with the appropriate C code, rather than the actual logic that would implement the block in hardware. You also can use C code in place of any control logic (so you might use an if or switch statement to choose what results to compute in place of control logic and a MUX).

Robot program

Write an assembly robot program to compete against the other robots. Submit the source code for your robot, and well as your simulator.

Working and Submitting

Continue work in the same CVS directory as phase 1. Update your "readme.txt" to describes how to build and run your program, including a description of any known problems or bugs. You should also turn in a hard-copy diagram of your multi-cycle organization in class, with all registers, memory, ALUs, and major units shown.