Tech3 Final Report

To download this report, right click and select 'save target as'.

Download Tech3 - Final Report

CAPC Design - Tech3

Tech3's version of CPU design is mainly based on performing 16 CAPC machine instructions. This report is about our design.

Lab2: Register
This is our register. Note that enable means "enable-send", and CLK means take the data.

In CAPC-Tech3 version, there are 2 12-bits registers PC, MAR; 5 16-bit registers MBR, X, Y, G, KB; and 1 4-bit register IR. Note, there are two differences to Dr. Hasegawa's design here.

Unique 4 Bits IR Design??
IR is usually a 16-bit register, which temporarily stores the instruction and parameter address. At the end of fetch cycle, it will get data from MBR. At the beginning of execution cycle, IR sends the parameter address (IR[0..11]) to MAR. At the middle of the execution cycle when two parameter (X, Y) of ALU are ready, IR[12..15] will go through decoder and determine how ALU should process X and Y registers, and then tells Z register to get data form ALU bits.

The machine instruction would be:

TxE : IR[12..15] send to decoder, instruction is selected. At the same time, send X, Y out to let ALU bits and DeMUX to calculate, and then tell Z to get results. After that, tell z to send the result out, and then G can take it.

This seems to be quite a lot of work to do in a short period.

Instead, we modified our design to reduce some instructions by making our IR simpler - A 4 bits IR, and let MBR do some of its work.

At the end of fetch cycle, we directly send MBR[0..11] to MAR, and at the same instant, the new 4 bit IR takes MBR[12..15]. 4 bits IR connect directly to decoder, but not BUS. The enable (send) line of 4 bits IR is always "1", therefore, ALU would know what it is going to do in execution cycle and would remember it through the whole execution cycle.

No Z register?
Because we already have the 4-bit IR to determine ALU's state, we don't need Z register anymore. We just need a buffer to close and open ALU's output when needed.

Lab5: KTG
KTG was simple and straightforward. We have no major comments on this component.

Lab4: ALU
Note that X register and Y register output connections to ALU-bits all the time. Therefore, as long as the control line "SEND_XXX" is determined, ALU would hold the output, and "SEND_Z" line only enables the output. This design is simpler, so we do not have to worry about how much time it takes for ALU bit to calculate and what time "register Z" (which is in the original design) should load the data.

Lab3, 6: Programmed Memory unit
Memory unit part took us the most of the project development time. We have two versions of a "working" memory unit (and many more non-working ones)

I have heard people yelling, "Dr. Hasegawa, we followed your design and it didn't work." In the lab…

We just need a much slower clock to run it and try adjusting signal input time for MBR and RAM. It is not "mission impossible", but it may be "mission difficult".

We tried another version of RAM that Logic Works provides. (Not check on "common I/O pins" option). It not only did not work for us, but also corrupted our version 2 of our CPU design. The whole file was dead. Instead, we used two buffers to separate our RAM's input and output.

Our PROM (driver) only contains 64 words. (6-bit addresses) They are located in addresses 000000000000 to 000000111111. Therefore, the logic of switching output between RAM and PROM is easy. Just "or" address line A6 ~ A11.

Device specification:
LOAD_MAR: update MAR register
READ_RAM: update MBR to correspond address (no input or output)
WRITE_RAM: write RAM to correspond address (MAR>000000111111)
SEND_MBR: Send the data of MBR out

To load RAM: LOAD_MAR -> READ_RAM -> SEND_MBR
To write RAM: LOAD_MAR -> WRITE_RAM

Lab1, 8: Put machine instructions together by Clock
Machine instructions are represented by many and/or gates. Each signal from these gates decides which device should pass its data to bus and which other device should take from the bus. However, each signal would have to go through different number of AND/OR gates, and each of these gates has a delay. If one of the instruction signal goes through more gates than its next one, the bus may not be cleared up before the next instruction gets executed. This can cause conflicts between devices.

The best solution we can think of is introducing a "time buffer" in our clock. Between each time interval, we let the clock remain stateless for a while. This way, the bus gets cleared up before each instruction gets executed.

This is the original clock signal:
t0: --______--______--______
t1: __--______--______--____

This is improved one
t0: --_______--_______--_____
t1: ___--_______--_______--__

Note: t1 did not turn to 1 right after t0 turned off

This idea came in very handy and solved a problem that we have not even thought of before running into it:

The flip-flop device has a delay; therefore, it did not switch at exactly the same time we tell it to switch. It is dangerous if we cannot find a perfect time to switch the flip-flop. After T7F, the timer may go to T0F for a short while, and we do not want that.

Because we have "time buffer", we would switch the flip-flop while all time signals are 0.

The clock is the last device we finished. There are three inputs.

HLT:
On - disable the clock (RUN flip flop = 0)
Off - nothing

RESET:
On - Disable the clock temporarily and set state flip flop to 0
Off - enable the clock again (RUN flip flop = 1)

SKIP_E:
Skip the execution cycle

The logic of RESTART line is the most innovative feature!

The RESTART line connects to three things. RESTART connects to the reset line of state flip-flop to reset the state to "Fetch". It also connects to the reset line of the run flip-flop to halt the machine temporarily, and the reverse of RESTART connects to clock line of the run flip-flop. Because we connect ~Q to D in run flip-flop, it acts like a J-K or T flip-flop here, and would turn back from 0 to 1 at the exact moment RESTART line is turned off. Which means the clock would run again. Notice that we cannot connect the reverse of RESTART directly to the preset line of the flip-flop, because if we do that, the clock would never stop.

Why does this clock have a MUX after the RESTART line?
The CLK line of our clock is "AND'ed" with a run flip-flop. The "AND" gate acts like a "signal dampener" here. Only if run = 1, the clock signal can go through. This clock will work most of the time but we realized there could be some protental problem:

Consider the following signal:
CLK:__________------------__________________________________
RUN:________________----------------------------------------------------------
                                    ^
User turns the RUN flip-flop back on at a bad time

"And" two signals ->
CLOCK's each output line would look like
_________________-__________________________________
                              ^
Can any instruction be completed in this short amount of time?

In this case, the first instruction will not be done properly. It may cause problem.

The solution is to put a MUX there. It uses CLK as control line. If the control line is 1, it means CLK is currently high, and opening the "dampener" may cut the signal short. We would delay the signal, ignore this high voltage and wait for the next one.

CLK:__________------------__________________________________
RUN:________________----------------------------------------------------------
Delayed RUN:__________________-------------------------------------------
Adjusted output:__________________________________________

Improving Machine Instruction:
When we were testing, we noticed that INJ, LDG and SDG are too simple to be performed in one execution cycle. We decide to improve it and add them into fetch cycle.

(Pre-condition: Because of our 4-bit IR design, MAR already has the parameter address at T5F)

LDG:
T6F: READ_RAM
T7F: G <- MBR

SDG:
T6F: G <- RAM[MAR]

INJ:
T6F: READ_RAM
T7F: PC <- MBR

~~~ HAPPY COMPUTING FROM TECH3 ~~~