Understanding the MU0 Processor

In hopefully a single page…

So this is really only for University of Manchester CS students, as the MU0 processor is an abstract design for teaching purposes here, as I discovered after a quick Google. I’m just going to run through how I understand the processor to work. I’m not going to mention low level gate stuff because as far as I can see we don’t need such a low level of abstraction. Please try and follow this through with the diagrams provided by the University.

MU0 is a single-address processor, which means that each of the instructions only ever have one address in the instruction at most (the other two are implied). The effect of this is that it may take a considerable amount more instructions in order to achieve the same thing you could do with two-address architecture. It’s more basic. The processor is also only 16 bit. This means that each instruction can have, at most, 16 bits to it. Hence, it’s only a one-address processor – there’s only enough space in the instruction for one address. Of the 16 bits, 4 of them are allocated to the instruction type and are known as the ‘f’-bits, leaving 12 bits for instruction information, known as the ‘s’-bits.

The processor has three registers;

  • IR (instruction register for storing the current loaded instruction)
  • ACC (accumulator for storing a working value)
  • PC (program counter for storing the current position in the instruction set).

It also has an adder for doing all it’s computation (also known here as the ALU, or Arithmetic Logic Unit, and not to be confused with the ACC register). Here are the seven instructions available for use with this processor design:

tableThatGahHaHa
Sorry for poor quality – couldn’t work out how to do a table in WordPress!

This is great so far. We can now understand how to write a program using this processor as we have all the instructions in front of us. This is also the specification for the processor design, and our problem is how to implement these registers and instructions. So what we need is a design that incorporates the features we’ve just outlined. The design will be achieved using two sections to the processor, a datapath and a control. The datapath is responsible for following the instructions and interpreting them, and the control is responsible for controlling components by enabling and disabling them, and setting those with options to the right state (the adder/ALU will need three states). These two sections of the processor will be synchronized using a global clock. A reset will be wired up to both too so that if the reset is flicked, the whole processor resets, not just one section.

MU0_Figure03

On each clock cycle (each pulse of the CPU where everything happens), the MU0 processor will be in one of two states; fetch and execute. On the fetch “pulse” the MU0 ‘fetches’ (gets) an instruction from the memory (instructions begin at the first address in memory i.e. #000) as indicated by the PC (initially set to #0000) and loads it into the IR. The ACC/ALU side of the datapath does nothing. For simplicity we can say that the PC auto-increments without going into the lower levels, which happens at the end of the Fetch cycle.

MU0_Figure02

Now we wait for the next clock strike. When this happens, the MU0 switches to the execute state, and depending on the instruction that’s just been loaded, the ALU may do one of three things with the ‘s’ bits of the instruction. It will either perform an addition of s to the ACC, make a similar subtraction, or simply bypass (pass through unchanged) s. Any necessary change to the ACC (if it’s an add/sub) or PC (if it’s a jump) will be performed, and after the execution of the Execute state, the processor will wait for the clock to strike again, and then return back to the Fetch state. The PC has been incremented from the last time the processor was in the Fetch state, so the next instruction will be loaded, and so on.

If the reset is switched, the state returns to Fetch, and if the stp instruction is processed, the state remains in Execute (not further processes are ‘fetched’).

The control of course is key, and I can’t write too much about it, as it’s the basis of the first lab exercise. Although I will say this. Each instruction needs to use the components of the CPU in a slightly different way (there’s no two same instructions). The control basically lets each component (including memory as it needs to be read or write enabled) needs to know what way to act differently for that instruction. The eight control bits outlined on the diagram below of the MU0 datapath design display eight different ‘options’ for controlling the components. If you’ve managed to follow how the CPU has been put together and what each instruction does, it should be clear which settings the control needs to set in order for each instruction to perform the right thing. Note that the control’s main input from the datapath is the four F bits (data out on the diagram). The datapath tells the control at this point which instruction it’s working with, and the control sets the the eight control bits accordingly.

MU0_Figure01

Just to let you know I spoke to some other student’s whilst writing this for clarification on some issues.

We’re all learning! There may well be errors so please let me know if you find one. If anyone has any issues or something’s not clear let me know and I’ll make changes, and I hope this helped and please leave comments!

The MU0 processor design is copyright to someone at the University of Manchester.