The Second Laboratory ("Lab 2")
The start-up script has created the directory smd137/lab2 and placed the files "lab2_mips.xml" and "Lab2ControlPart.java" there. What differs this model from the previous model is that it is looking for the controller in the file Lab2ControlPart.java (which you will modify) instead of the controller used by default.
The difference between the original controller and the one you have been given (Lab2ControlPart.java) is that some of the instructions are unimplemented in your controller and it is your job to implement them (described later). It is however still possible to load the MIPS model with the unimplemented controller but in order to do that you need to compile it:
smd137/lab2> javac -cp $myclasspath Lab2ControlPart.java
This will put the class file in the "smd137/lab2" directory. In this lab only: for SyncSim to be able to find it you have to run it from the directory "smd137/lab2/":
smd137/lab2> syncsim &
Now the only thing needed to start syncsim and load the MIPS model (lab2_mips.xml) is an "mips_program.objdump" file which you now should be able to create yourself (create an *.s file and write a small test program and compile it so you get the "mips_program.objdump" file in the same manner as in the previos lab and the prelab).
What the lab is about
This secondary laboration is a bit different from the first one. Your task is to implement the control logic for a number of opcodes by setting the values that the controller is sending out to the ALU, the register file, the signed/zero extender and the multiplexers (mux). The controller is hidden from the user in the MIPS model but you can think of it as a component that takes the current instruction as an invalue and sends out control signals based on this instruction, see the figure below.
You must add the following lines in the top of the Lab2ControlPart.java where XX should be replaced with your groupnumber:
DT_GRUPPKOD XX DT_LABNUMMER 2 DT_LABDEL 1
You will turn your lab in by electronic mail, as in the previous lab. We will take what is in this mail, compile it, and make sure that all the instructions are implemented correctly.Purpose of the Simulator
One of the purposes of this course is to introduce the student to what is happening, component by component, bus by bus, inside of a computation structure (in our case, inside of a MIPS processor). The simulator has been carefully written to show how the multiplexers are switching, which controlling values are on which bus, what values are presently stored where, and many other details.
If you are running the simulator as if it were a "black box" and you are not trying to understand why (for example) a certain multiplexer is being steered one way and not the other for some given instruction, then you might not get the deep understanding that we strive for!
Large digital designs can usually be broken into two parts. The first part is a datapath which is the circuitry which carries and processes the data. However, there is usually a control part which steers and controls the datapath. The MIPS simulator shows only the datapath and not the controller. Something, somewhere, has to "decide" and tell all the multiplexers how to switch, whether to sign extend or zero extend, in short to steer all of the "control points" in the datapath.
A multiplexer (mux) is a device that connects one of many incoming wires with one outgoing wire. They can be drawn like this:
To connect the incoming wire '01' with the outgoing wire the mux must be fed with the control signal '01'. The number of bits in the control signal is given by that two to the power of the number of control signals has to be greater or equal to the number of incoming wires. Wires are enumerated top to bottom.
In this lab we will concentrate on the control signals for four multiplexers, the ALU, the register file and the sign/zero-extend 'box'. The controller is described in a file called Lab2ControlPart.java. The compiled version of this file is the one that the lab2_mips.xml file is using. You will now be given this file uncompiled, but the control signals for the instructions that you will implement have been changed so that they are sending out "invalid" signals. which means that the component receiving the signal doesn't know which value it receives.
All the control signals for the instructions are handled in the the update method of the Lab2ControlPart.java, which you have downloaded. The instructions that you must implement have been equipped with the following comments:
"//-- START --------------------------------------"
"//-- END ----------------------------------------"
and you are only allowed to modify things between these comments for the instructions.
Between the comments the code to send control signals to the four multiplexers, the ALU, the register file and the sign/zero-extend 'box' are specified. When the MIPS executes the opcodes there may be parts of the processor unused depending on the opcode. If, for example the value on the outcoming wire of a mux is not used for a particular opcode there is no need to send a control signal to the mux. By using invalid signals this can be simulated. All components not used shoud receive "invalid" signals. This means that the signals are not handled by the components that are receiving the signals. The control signals for the instructions that you should implement are sending out these "invalid" signals to all components. Your job is to change some or all of these "invalid" signals so that the instructions are executed correctly. You should only change the signals that are necessery for the instruction to execute correctly. The others should remain unchanged.
An invalid signal has this syntax:
where bitWidth is the bitwidth of the signal. A valid signal has this syntax:
new Signal(bitWidth, value)
where value is the value to be send, e.g. to set the multiplexer in the figure above to connect to the input "11" one should send this signal:
new Signal(2, 3)
Here is how the sending of signals are specified in the instructions:
The signal to be sent are specified between ".setSignal(" and ");"
The name between "out[" and "]" is the component that will receive the signal.
Controlled componentsHere is a list explaning what the signal controls:
OUT_REG_DEST: The control signal to the multiplexer located under the regfile.
OUT_REG_WRITE: The write enable signal to the register file.
OUT_ALU_OP: The opcode signal to the ALU.
OUT_ALU_SRC_A: The control signal to the multiplexer connected to the first input of the ALU.
OUT_ALU_SRC_B: The control signal to the multiplexer connected to the second input of the ALU.
OUT_WRITE_REG_SRC: The control signal of the multiplexer located at the right hand side of the ALU.
OUT_EXT_SELECT: The signal to control wheter the sign/zero-extend 'box' should signextend or zeroextend.
Here follows an description of the signals that could be sent to the components above and what it controls:OUT_REG_DEST: The control signal chooses the input 0, 1 or 2.
OUT_REG_WRITE: The control signal chooses if we should write to the registerfile: 1 (write), 0 (no write).
OUT_ALU_OP: The signal sets which operation the ALU should perform:0000 = ALU: ADDOUT_ALU_SRC_A: The control signal chooses the input 0, 1 or 2.
0001 = ALU: ADDU
0010 = ALU: SUB
0011 = ALU: SUBU
0101 = ALU: OR
0110 = ALU: XOR
0111 = ALU: NOR
1100 = ALU: SLL
1101 = ALU: SRL
1110 = ALU: SRA
1111 = ALU: LUI
OUT_ALU_SRC_B: The control signal chooses the input 0, 1 or 2.
OUT_WRITE_REG_SRC: The control signal chooses the input 0 or 1.
OUT_EXT_SELECT: The signal sets if it should signextend: 1 (sign extend), or 0 (zeroextend).
So, if you want to send a signal so that the multiplexer that writes the result to the register, OUT_WRITE_REG_SRC, chooses the result from the ALU and not from the memory one should change the signal to this:
You will not implement the control signals sent to memory, but you should still think about these, if you should send a read/write signal to the memory.
Last six bits and corresponding operation that the ALU should perform
Change the control signals that are send to the four
multiplexers, the ALU, the register file and the sign/zero-extend
'box' for the instructions below (they are marked in
the file Lab2ControlPart.java).
You can find the format of the instructions under
instruction set summary.
You should use the compiler to see what the following pseudo instructions are translated to. They might expand to several instructions. It is also possible that the name of the pseudo instruction appears in the code view but don't let this fool you. If you look at the bits of the instruction you will see that it in fact is one of the native mips instructions. You must find out which instructions the pseudo instruction is translated to and implement these instructions. All the instrucions that you should change are commented as described in the section "Controller" above.
We will examine your code and to pass this lab your code should execute the instructions correctly. If the functions executes incorrect, you will get a "Retur". Be sure to submit your lab on time!What You Should Submit
Part One must be your Lab2ControlPart.java file, don't forget to add the things discussed in "General information on lab 2" above.Last modified 2005-11-14 by jimwik-0