Home
4Art
    Favorite Artists
    Personal Art
    Tutorials
4Education
    Astronomy
    Cryogenic Fluids
    Logic & Circuits
4Personal
    Dallas Photographs
    Cancun Photographs
    Hawaii Photographs
4Professional
    Business Skill
    Employment History
    Programming
    Web Administration
4Recreation
    Television
    Gaming - RPG
4Administration
    Navigation
    Sites
    Users
    Groups
 
 

Department of Computing

Course DOC 112 -- Hardware

 

Lecture 17: Let's Design a Real Computer (Part 1)

 

Duncan and Peter hardware designers completed their "real" processor design by adding memory, and a Program-Counter (PC) to their well running manual processor and were quite pleased showing it off to the software manager Piotr.

We pointed out the new additions and improvements. We had to add a Program-Counter (PC) register, also with eight bits and to fit it into the system; therefore, we had to use an additional multiplexer. Since we had four inputs to this new multiplexer, whose output we call the BUS, we separated the SHIFTER from the ALU and also allowed the A register to be directly connected to the BUS. We also cleverly added MEMORY in the traditional, simple way when the memory address is always kept in the MAR (Memory-Address-Register) while the memory output is enabled at all times and reflects the contents of the memory at the address held in the MAR. The MBR (Memory-Buffer-Register) contains the data either for reading or writing. When reading memory, the CLKMBR, when writing, the Memory-Write-Clock has to be generated. We did not mention the fact that there were a few unsolved problems, like where the new select lines SELMBR or SELBUS will come from or how the Memory-Write-Clock is going to be generated; however, we were confident that these problems can be solved. But, we did not get too far when .....

 

Piotr looked at the design in horror: No registers??? (Peter and Duncan did not want to point out the internal A and B registers at this point). "Exactly!" Duncan and Peter said in concert. We have fast memory so memory cycles will go like lightning, in one clock cycle, no need for registers. This is what so revolutionary about this! "Impossible", Piotr said, "I am sure there is something wrong with this idea, I wish I could think what it is". It came to him slowly, but at the end it was very convincing. For example, if one wants to sum a set of numbers, if there are no registers, the sum has to be stored in memory as well as the numbers. Thus for each addition more memory clock cycles are needed then if we accumulate the sum in a register and the computer will be slower!

 

Duncan and Peter could have suggested the A or B register for this purpose, but they knew better. First of all, in order to execute instructions in a computer, they knew from experience that they needed hidden registers which the programmer absolutely should not see (these programmers use everything they can lay their hands on and mess up the orderly hardware sequences!) Secondly, Piotr was very friendly with the general manager and word came down from above not to argue. So, there they are, four general registers called R0, R1, R2, and R3 will have to be added to the processor; which becomes quite a conventional design now. Duncan and Peter will have to go away, redesign their hardware if they want to keep their job. So, Piotr simply told the hardware department what instructions he wanted, and there could be no argument. A sad case, really.

 

The Software Designer Speaketh:

 

The instruction definitions were given to Peter and Duncan in four classes as follows:

 

. .

 

These must operate on registers only and as shown above, the operation code indicates one of eight different operations: MOVE, ADD, ADD-WITH-CARRY, SUBTRACT, COMPARE, AND, OR, and EXCLUSIVE-OR (that was lucky - our old processor could do all these operations), and the register indicators are two bits each; thus they can select any one of the four registers: R0, R1, R2, or R3 with bit combinations of 00, 01, 10, and 11 respectively.

 

. .

 

Class 2 instructions have a similar format with one register only and should include the following eight operations: INCREMENT, DECREMENT, CLEAR, COMPLEMENT, ARITHMETIC-RIGHT-SHIFT, LOGICAL-RIGHT-SHIFT, LOGICAL-LEFT-SHIFT, ROTATE-LEFT-WITH-CARRY. (Lucky again!). Also, the subroutine RETURN operation has the same format.

 

. .

 

These Memory-Reference instructions all must occupy two successive eight-bit words in memory. The first word has exactly the same format as the One-Address instructions; i.e., an operation code and a register designator. The second one could mean one of three things (the operation code should indicate which type is used). It may be an eight-bit data word (immediate data), it may be an eight-bit memory address, or it can be an eight-bit indirect memory address (the address points to memory where the address of the data is!).

 

For our relief, only four such instructions are required: LOAD, STORE, JUMP, and CALL (jump to subroutine). For JUMP and CALL instructions the immediate mode considers the data to be an address, the second mode an indirect address, and the third an indirect, indirect address. The JUMP instruction does not need a register, really; however, the CALL instruction leaves the return address in the designated register. LOAD and STORE are reasonably standard (even hardware designers would understand how they work).

 

. .

 

Piotr asked for as many conditional skip instructions as possible; however, the minimum set is: SKIP (always), SKIP-ON-CARRY=1, SKIP-ON-CARRY=0, SKIP-IF-LAST-RESULT-IS-NEGATIVE. The skip instruction, if the condition is true, must skip two successive memory words because usually after the skip instruction there is a JUMP instruction which takes two memory words.

 

A Few Observations

 

The moral of this story is that there is a dividing line between software and hardware. We can see it on the design and hear it from the conversation. But of course, they affect each other. The situation is this:

 

. .

 

The hardware/software interface (nowadays) comes from the requirements of the software; however, if some of the software requests would require expensive hardware additions, they could be negotiated. In this case, the software department was quite reasonable, and a reasonable person (especially one who wants to keep his or her job) will not argue any further.

 

 

The Hardware Designer Designeth

 

Since we have to change our design significantly by inserting the four registers into the system, we may as well look at our old design and see how we could improve it further. We have to provide data paths to be able to execute the required instructions. In order to get an idea about these data paths, we may attempt to describe the operation of the computer by register transfer operations. These are the basic steps of the internal operation of a computer and they usually mean in hardware terms the setting up of the correct signals for the appropriate multiplexers and function generators and then the generation of the appropriate clock signals which change the contents of destination registers. A register transfer operation is described by the following general register-transfer statement:

 

. .Destination-register <-- function( Source-Registers )

 

For example, the add operation C = A + B may be represented as:

 

. .C-Register <-- ADD( A-Register , B-Register )

 

The first operations we must deal with is the Fetch-cycle, i.e., the basic operation of the computer:

 

The Fetch Cycle

 

The fetch cycle must include the following four register-transfer operations where F.i indicates a fetch cycle:

 

. .

While there are four required operations, we do not necessarily need four clock pulses. We have to look at the operations in detail and may discover that two of them could be done in parallel. In this case, Step-2 must wait for Step-1 since the contents of MAR is required; however, steps 2 and 3 use entirely separate registers for both source and destination; thus, they could be done in parallel. Step-4 must wait until Step-2 is completed, since the contents of MBR is required. We end up with three required steps:

 

. .

 

We learn from the fetch cycle that a data path must be supplied from the PC to the MAR, and from the MBR to the IR. Also, an "incrementer" is needed to increment the Program-Counter. Finally, the memory operation MBR<--MEM[MAR] is the ordinary memory read operation which means that the CLKMBR must be active and a data path provided from the Memory-Data-Output lines to the MBR register.

 

Now, unfortunately, we have to go through all instruction types in the same manner in order to determine all the data paths we need. This is a painfully laborious process, but a necessary one.

 

 

Two-address instructions

 

 

The two-address instructions work quite nicely when there is a correspondence between our ALU and the required operations: ADD, ADDC, SUB, AND, OR, XOR. The cycles (execute) are E.1, E.2, ...

 

. .

 

The MOVE instruction can be done by:

 

.

 

The COMPARE instruction is really a subtract operation but without storing the result back into the destination register. We are in luck again, there is a (B mi A) operation of the ALU that we have not used yet; this is a good opportunity for it:

 

. .

Sneakily we have made the assumption that the conditions will depend on the output of the ALU. In all the above cases the ALU outputs indicate the results of the last operation.

 

 

One-address instructions

 

The one-address instructions use either the ALU or the SHIFTER. The ALU is used for CLEAR, INC, DEC, and COMPLEMENT (COMP),. This is the time when the setting of the ALU output to all zeroes or all ones (-1) becomes really useful. 00000000 or 11111111 can be put into the A or the B register and data into the other register as shown below. The shift instructions are executed by the SHIFTER:

.

 

The RETURN (from subroutine) instruction can be executed in one time step:

.

 

Memory reference instructions

 

First, let us look at the " load immediate data" (LOADIM) mode operations. The data for the LOAD operation is stored in the next memory location, after the instruction. We notice that after the FETCH cycle the PC contains the address of this memory location. Therefore the following sequence will load the data contained in memory into the destination register:

 

.

 

The second incrementing of the PC is necessary (the first increment occurred in the FETCH cycle) because the instruction which has to be executed next is stored in the memory word after the data word.

 

The ordinary LOAD operation requires an address in the second byte. The register-transfer sequence for this operations is:

 

.

 

Notice that this is the first time that five execution steps were required. This is very unpleasant, really. We will try later to make the sequences more uniform.

 

The ordinary STORE operation requires an address in the second byte. The register-transfer sequence for this operations is:

 

. .

 

The JUMP instruction with an "immediate data mode" considers the contents of the next memory location to be an address. The sequence is very similar to LOADIM but with a different third step:

 

. .

 

since a "jump" in the program means the changing of the program counter.

 

The CALL (call a procedure) instruction is similar to the JUMP instruction but the return address must be stored in a specified register. We can do this with the following sequence:

 

. .

 

The unusual incrementing of the PC as the first step is necessary because the return address is one larger than the location where the address for the CALL instruction is located. Again, there are multiple register transfers in one clock cycle, but they look OK. to me.

 

Now the indirect address calculations have to be taken care of. Actually, indirect address calculations give very little trouble to hardware designers (as directly opposed to software writers), because after the memory READ cycle the MBR contains the contents of the memory at the required address. If this is data (immediate mode) then we have nothing more to do. If this is an address then we can transfer this address to the MAR register and do another memory READ operation In fact, instead of copying all four instructions again, we can simply insert two or four new states into the state transition diagram of the computer which take care of the indirect addressing problem. This, hopefully, will become clearer when we will be designing the new controller. We shall designate these states as I.1, I.2, I.3, ...

 

. .

 

Finally, we are left with the skip instructions. The unconditional skip instruction must increment the PC twice, so it will take the following two steps:

. .

 

Conditional skip instructions execute exactly in the same way using two time steps, if the conditions are satisfied; however, they do nothing if the conditions are false. This is a control problem not a register transfer problem and will have to be handled when the controller is designed.

 

Phew!! Now we have all our required register transfer instructions, we are ready to propose the hardware paths which should be able to execute all of them. The proposed design is shown on the next page. It is obviously very similar to our first design, so we may be called conservatives. On the other hand, we may be a bit careful and try something which worked before.

 

 

Let us look at some important features of this design. The most important data path (eight bits) of the hardware is called again the BUS because it is the output of a four-to-one multiplexer and therefore could be a "source" for many register-transfer operations. It may represent the shifted A register contents (remember, one of the shift functions is "no change"; i.e. the BUS will represent the unchanged contents of the A register in this case), the results of the ALU, the contents of the Program-Counter, or the contents of the Memory-Buffer-Register. Notice, that there is no direct path from the registers R0..R3 or from the Memory-Data-Output to the BUS.

 

The BUS is connected to the A or B registers (through a multiplexer), directly to registers R0..R3, to the PC (again through a multiplexer), to the MBR (ditto), directly to the Memory-Data-Input lines and to the MAR. Thus, it is connected to just about everywhere.

 

The Carry-Input of the ALU has been given a four-to-one multiplexer; thus a wide variety of inputs can be selected; such as the most significant bit of the A register A7, the Carry flip-flop output, the two constants: zero and one. This wide variety of inputs was necessary because for the required instructions the carry input bit must be strictly controlled.

 

Finally, the Controller became much more complicated. In addition to the reset input line, the Instruction-Register bits must be input since different instructions may require different state sequences (like the indirect address sequence), similarly, the C bit and the A7 bits are probably needed for conditional skip instructions. We shall see later.

 

Our next task is to check our design carefully and make certain that all our register transfer operations can be executed with it. After that, we will have to pay attention to the controller.

 

 

 
 
 
 
Email comments to: Joshua Jacobsen
Last modified: 1/23/2005 11:42:41 AM
Make This Page Your HomepageMake This Page a FavoritePrint This Page
URL for this page: http://www.drowlord.com/education/logic_design/h17.html
Copyright© 1999 - 2005 Joshua Jacobsen