|
|
Diary
Entries
|
ENTRY
1 - Clock Device
|
Task 1: Making a time device which
can produce T0, T1,T2,T3,T4,T5,T6,T7.
Problem: We had no problem to make T0; however,
we had problems on shifting the time line. Sherry thought about
using four clocks to produce the time delay because she forgot that
buffer can do the delay.
Solution: We discussed it. Robert suggested that buffer
can do the time delay and one clock is enough. By following his
idea, we came up with our final design. We implemented in
a couple ways and decided on one that we thought would be best
for simulation purposes.
|
| |
| ENTRY
2 - 16Bit General Register |
Task 1: Make a 16 bit general purpose
register.
Problem: No problems encountered. The notes
from class were adequate.
Solution: The first thing we did was use D-Flip Flops
to figure out the exact wiring and test them on a small bus just
to be sure everything worked. This was basically a 2 bit bus with
two 2 bit registers connected. With this model we could test loading
data from the bus and sending data to it. From this, we made 16
bit registers and did a similar test. Once it was all tested,
the device was made.
|
| |
| ENTRY
3 - Memory (RAM) |
Task 1: Make a random access memory
(RAM) device with 12 address lines, 16 input/output lines, send
enable, and write enable.
Problem: There was also another problem of
the RAM not being able to hold more than one value. This was because
we enabled "Single Word Simulation" when creating the
device.
Solution: The solution was simply to not enable
the "Single Word Simulation" option when creating the
device.
Task 2: Create a data bus connecting
the PC, IR, MAR, and MBR registers and use a clock to imitate a
fetch cycle.
Problem: There was a problem with the common
I/O pins. When trying to write back from MBR to MAR, the pin on
the RAM could not be used as an input pin because it is already
being used as an output pin.
Solution: We solved the memory writing problem by using
tri-state buffers when writing Memory from MBR.
Problem: Simultaneously sending data from
one register and loading it on another (via the bus) loaded garbage
into the destination register. There seemed to be a timing problem
with the data not being on the bus in time for the load signal.
Solution: There seems to be some sort of timing
problem. We assume this is because it takes a little bit of time
for the data to propagate out of the source register, so there is
a bit of a delay. We solved this by adding a minimal delay in front
of the load pin on the destination register. [While I'm not particularly
fond of this solution, it works for now. - Steve]
|
| |
| ENTRY
4 - ALU (Arithmetic Logic Unit) |
Task 1: Make a ALU process for a single bit;
we'll call this the ALU Bit Processor (ALUbit for short).
Problem: There were no problems encountered.
Solution: Created a combinational circuit that takes
in and X-bit and a Y-bit, 1 of 6 enable bits (one for each operation:
and, xor, or, add, shift, not), and a carry bit, and has two outputs
(one for the result, and on for the overflow).
Task 2: Combine 16 ALUbits to form a complete
16 bit ALU.
Problem: There were no problems encountered..
Solution: Just combined 16 ALUBits to form a basic
ALU unit that performs operations on 16 bits of data. We may yet
add an overflow bit later.
|
| |
| ENTRY
5 - Keyboard Register |
Task 1: Create the Keyboard Input register
and attach it to the bus.
Problem: There were no problems encountered.
Solution: Used four hex keyboards and attached them
to the input lines of the keyboard register; attached the output
lines to the bus.
Task 2: Hardwire the KTG instruction.
Problem: To get the send-KB line to load the data
before sending it, so it would always send the up to date data.
Solution: Made a small delay (1 unit) and placed it
in front of send. We then tied the send and load together, so
when a pulse arrived on the tied send line, it would first go
to load and after a small delay courtesy of our new buffer, it
would then send the new data. This worked perfectly.
|
| |
| ENTRY
6 - PROM (Programmable Read-Only Memory) |
Task 1: Write a program into PROM and create
it as a device.
Problem: There were no problems encountered.
Solution: We.... uh.... wrote a program.... in notepad...
renamed it a *.hex file and attached it to a new PROM device in
Logic Works. yup.
|
| |
| ENTRY
7 - Hardware Interrupts ( -omitted- ) |
|
| |
| ENTRY
8 - Wiring Frenzy (Putting it all together) |
Task 1: Break the processor down into smaller
chunks of more robust devices.
Problem: Figuring out what devices to create.
Solution: With some influence from the inside cover
of the textbook, we decided on making a Register File, a Control
Unit, an ALU (which was already complete - yay!), and a device
encompassing all the memory. We then drew a layout for how these
would all connect that looked something like this.
We also decided that we would put all the necessary AND-gates
between the decoder and the Control Unit into one device (per
instruction). This was just to simplify wiring and make it look
more nice. =)
Task 2: Make the devices.
Problem: A couple of times, the label was created
wrong on the devices, and the wiring was done to the labeling.
Solution: Rewired the external wiring, didn't have
time to change all of the devices. We couldn't figure out an efficient
way of doing that in Logic Works; the device always seemed to
end up not working.
Problem: Making careless mistakes wiring at 4:00
AM.
Solution: Spending even more time tracking these mistakes
down.
Problem: Spent way too much time making stuff look
pretty.
Solution: No solution... but it does look pretty. =D
Task 3: Wire all the devices together.
Problem: Delays!! *pulls hair out* Finding just
the right one was horrible. And we had different delays for each
instruction, initially. Kept getting conflicts on the bus.
Solution: By trial and error, we found 10 was the perfect
delay for everything, except the ALU, which we put 4.
Problem: Making the Control Unit start back at Fetch0
when it is turned off and on.
Solution: Put a tri-state gate right after the clock.
The off/on signals must be pulses (on-off), and when turning it
off, the Xs must be allowed to propagate throughout the circuit
before turning it on again.
|
| |
ENTRY
9 - Final Product!! (we actually finished!)
happy, happy! joy, joy! =D
|
|
To see a picture of the final product, minus all the probing
(cuz nobody likes to watch probing), click on picture. Be warned
though, it's quite hefty for a GIF (200+KB).
Prev
|
Top |
Next |
Download |
Blueprint |
|
|
-THE END-
(hopefully, we'll all live happily ever after...)
|
| |
|
