TTL CPU on 32 breadboards

File: control_unit.jpg (2MB, 3264x1836px) Image search: [Google]

2MB, 3264x1836px

Here is control unit. I designed some circuitry on 3rd breadboard to the left that allows us to check conditions in the FLAGS register and advance to a different state in microcode if a certain condition is met.

Basically this allows me to do jump if zero, jump if carry, jump if not negative, and so on type of instructions.

File: Oh yea.png (125KB, 431x352px) Image search: [Google]

125KB, 431x352px

Very Interested.
Dump away please.

Highly impressive. You know what you must do now, anon.

(Port doom to it)

Well color me impressed, op. Anything more that you post about this project would be greatly appreciated.

>>1179975
I always wanted to do that when I was teen. I'm very impressed to the power and possibility of that processor ! Nice job !

Ok, but why breadboards? I can't really come up with an excuse for using them at this point in your project.

>>1180220
>Ok, but why breadboards?

Because they are fast and easy. But really, anything this complex or high frequency should never use protoboards. Go ahead and wire wrap or solder so that a few weeks later you don't have to wiggle every wire to find the ones that are no longer making good contact.

Protoboards are fine; I use them all the time, but they have weaknesses.

>>1179975
Very impressive OP

>>1179975
Bump for an interesting project.
I'd be interested to see any diagrams or schematics you are willing to share.

File: address_bus_board.jpg (3MB, 3264x1836px) Image search: [Google]

3MB, 3264x1836px

Thanks for the responses anons.

>>1180238
Yeah the wires not making contact was always an issue.


Attached is a picture of circuitry that uses the address bus. In between each breadboard there are black strips with common connects between each board, so we used the bottom 16 as the address bus. The orange circle is a CMOS EEPROM (28C64A) for the program ROM, and you can see the green wires connecting it to the address bus. The light blues wires are connecting it to the 8 bit data bus. Circled in blue is the CMOS static RAM (KM684000B) and the connections are the same, except that highest 3 address lines connect to the RAM and not the ROM. Since both chips from an assembler programmers viewpoint are accessed the same, the chip enable pins for each are tied to the inverted output (for ROM) and output (for RAM) of a triple input NOR gate where inputs are highest 3 addresses from address bus.

Circled in light purple is 16 bit program counter which uses 4 74ls163 4 bit counters and 2 74ls244 tri-state buffers to interface w/ address bus. 2 other 74ls244 interface w/ program counter low and program counter high to data bus. The light green circled stuff is memory address register used for direct addressing and array traversal and is made from the same 4 bit counters except we use the 74hc541 instead of 74ls244 for tri state buffering. Actually the CMOS chip had much easier to work with pinout and I should have used the chip throughout the project, I didn't know my schools electronics lab had a ton of these until late!

Circled in red is stack pointer. I will write some about it later.

Also for reference almost all yellow wires you will see in this project (besides ones on ALU boards) are from control unit signals.

File: block_diagram_full.jpg (1MB, 3264x1836px) Image search: [Google]

1MB, 3264x1836px

I'm posting the mostly complete block diagram of the CPU here. J is the highest 8 bits of the memory address register and I is the lowest 8 bits. A and B are ALU input registers and C is general register and T is kinda of a memory buffer register (called T for Temp register in our design) that either stores a value about to be stored in RAM or just read from RAM. It can be used as general purpose register too. The A, B, C, and T registers are the 74ls374 chip with AND gates attached to make the writes synchronous with the next rising edge of clock. Those chips actually became kind of annoying to work with since they only had a output enable and clock pins, unlike a synchronous chip which will have a load enable pin as well as a clock pin. However, the convenience of these chips was that they did have on chip tri-state buffers.

Also I just made public some youtube videos of the CPU running some programs. Here is it computing square numbers using a multiplication subroutine I made, so it outputs numbers like 1, 4, 9, 16, 25, and so on. In the demo I make it show the partial results of the multiplication algorithm (repeated addition) to show I'm not cheating by hard writing those values onto the program ROM and that the CPU is doing this in real time.

https://www.youtube.com/watch?v=GCk6gT3Zew8

File: seven_seg_decoder.jpg (2MB, 3264x1836px) Image search: [Google]

2MB, 3264x1836px

The 7 segment display was done by replacing combinational logic to decode with 3 EEPROMs that store values for all segments for each decimal digit (hundreds place, tens place, and ones place). The address lines 0 to 7 on each EEPROM are fed in the output of the output register, which is a binary value 0 to 255.

For example with a common anode 7 seg display like the LTS-312AHR which we used, the segments for the digit 5 would be stored as a byte like this where n = no connection and each bit represents the segment:

n g f e d c b a --> segments
1 0 0 1 0 0 1 0 --> bit value in EEPROM

A common anode display means what the name implies, so the value 0 means that the g, f, d, c, and a segments will be lit, which shows the value 5.

The process of writing these values to the EEPROMs was done automatically with a script I wrote. The image here is the diagram for this display, which is attached to the output register which is made from 2 74ls163. Missing on the diagram is 100 ohm resistors in between the outputs of the ROMs and the 7 segment displays, just to make them slightly less bright.

Good stuff OP. What would you say was the hardest part?

>>1179975
Nice!

Does the processor implement any sort of instruction pipelining?

>>1179975
>Anyone interested in a home built CPU I did with 2 friends?

Are you fucking shitting me? Multiple threads. Write a fucking novel here.

Let's start with a simple one; how did you deal with signal propagation & jitter?

File: dangar to manifold.jpg (378KB, 1600x1200px) Image search: [Google]

378KB, 1600x1200px

>breadboards
>megahertz
jesus christ anon that's like a riverboat breaking the sound barrier

>>1179975
post all of it!

>>1179975
Shit nigger that's cool as fuck.

>>1179975

How familiar are you with this guy?

https://www.youtube.com/user/eaterbc/

>>1179975
Nice!
Is it related in any way to the TTL CPUs in Computation Structures? That used to be the textbook for MIT's 6.004 class, all undergrad EE and CS students had to build one.

>>1180478
(Building the MAYBE R-machine from Computation Structures was the most fun I had in college. Way better than the sex.)

Oh, you didn't use the 74181 and did the whole ALU too? Hardcore.

File: condition_control_logic.jpg (1MB, 3264x1836px) Image search: [Google]

1MB, 3264x1836px

>>1180478
Hmm I don't know at the moment. Most of the background research on other processors I did for this project was on the MOS 6502. I wrote an emulator for the Intel 8080 before so both of those processors definitely influenced this one.

>>1180462
Yeah I've watched a fair amount of his videos. He's a great resource and even the 7 segment decoder I designed was based on a video of his. My only complaint is that his processor is very limited in scope, in that it only has 16 bytes of RAM and not many instructions. I have a prime number generation algorithm (sieve method) that's currently compiled at 144 bytes alone + stack space used in run time + 256 bytes in RAM for an array. Again, great teacher and motivator for me.

>>1180428
Whats even crazier is that we did not intend at all to run that fast. Up until a few weeks ago I would have been happy to run in single digits kilohertz range. It just worked at over a megahertz. There are power supply decoupling capacitors for each board but none for each chip.

>>1180405
Conditional jumps. At the moment all of our jumps work, like jump if negative, jump if carry, and jump if zero. You can also test for the complement of that condition, like jump if not zero. The design I settled on was having 3 bits stored in the control ROM that signals what ALU FLAGS register condition to check. These 3 bits are then fed to a 3 --> 8 inverting decoder, I think the 74ls138. Like the value 111 for a condition check code is the default value in microcode, which would mean to not check for a jump at all. All non jump instructions have there corresponding micro instructions defaulted to those 3 bits. if we are going to do a jump if zero, then the microcode for a jump if zero instruction has its 3 condition bits set to 001, which is fed into the decoder. This goes through some pretty basic combinational circuity that selects the zero bit from the flags register. In other words, think of this as a multiplexer. (will be continued)

File: condition_pinout.jpg (2MB, 1836x3264px) Image search: [Google]

2MB, 1836x3264px

cont.

>>1180405
The output of this logic is the feed into a high address line of the control ROMs. Again we use 28C64A as our EEPROM. The microcode for a instruction (only for jumps) is mirrored on those higher addresses such that when the condition logic outputs high, we go through microcode that swaps out the program counter. The issue was that we needed a buffer for the low 8 bits of the program counter, because we need to grab two bytes in memory for the new value of the program counter to be swapped in. But we must advance the older program counter to get the new one! So that's where a buffer came into play. This is an issue of having an 8 bit machine with 16 bit address space, but a minor one.

>>1180416
I tested the ALU carry out propagation times with o-scope and they were around 160 nano seconds. That was my worry for limiting factor since we built it completely from scratch and it spanned a lot of space. I'm not looking at the data sheet for EEPROMs but they also had a pretty long propagation delay too of around 150ns for a read to become valid. Honestly I had very little electrical engineering knowledge before this. I'm a CS major who has taken a couple physics classes + done simple circuit design before, so I had to crash course myself last winter break. I actually noticed ringing on clock signals in certain cases, and a terrible side effect of this is if the program counter clock signal rings (and dips low enough to TTL logic low) it will increment twice as long as both edges are over 5ns or something apart. If that happens everything is broken software wise.

I design I had that made my life really easy was to have a clock and inverted clock pulse. The main clock pulse is fed into instruction register and state register which is then fed into address lines of 4 EEPROMs which make up the control ROM of our system. All registers (except state and instruction register) are written synchronously with the rising edge of the inverted clock.

File: ALU.jpg (2MB, 3264x1836px) Image search: [Google]

2MB, 3264x1836px

>>1180551
attached is TTL pinout for jmp logic

>>1180416
That inverted clock solution worked great. Although you totally can do this with one clock or other better ways it made writing the microcode simple and I did not have to worry about race conditions or propagation delay too much as long as we were running below 1.5 megahertz.

>>1180481
Thanks for recognizing this :) Yeah, the ALU was built from XOR, AND, OR, and NOT gates only. The full adders and multiplexing logic needed in a basic ALU design were built from logic gate scratch. Later on I used two 74ls83 (4 bit adders) when designing the stack pointer to increment and decrement, but those were not used in the ALU.

Each breadboard in the pic is a 1 bit ALU. The orange wires that go from a board on the left to the right is the carry out from a previous ALU.

File: full_CPU_2.jpg (2MB, 1836x3264px) Image search: [Google]

2MB, 1836x3264px

>>1180410

For some instructions, like an ALU operation (add, or, xor...) or a non-RAM data transfer like load_immediate [byte] or mov b,t take 2 clock cycles in total. The instruction decoding and execution take 1 cycle and the fetch takes 1 more cycle. However at the top of my head I think the call [addr] instruction takes like 10 or maybe more clock cycles. I don't know if its accurate to call it pipelining but the program counter is incremented during most instruction execution when possible, so I guess the instruction fetch and execution do overlap. Maybe I can call it minimal pipelining lol?

I didn't mention this yet but the whole fetch-decode-execute cycle is all dictated by the microcode in the control ROM. In the last state of every instruction besides HALT we signal for the ROM to drive the data bus and for the instruction register load signal to become active, and on the next rising edge the 8 bits on the data bus corresponding to an op-code are clocked into the instruction register while the state register is reset to 0 at the same time. State 0 means we now enter the first (or only) step in executing the new instruction.

Attached is just another picture of the CPU from the viewpoint of 7 seg display.

File: clapping-gif7.gif (1MB, 320x240px) Image search: [Google]

1MB, 320x240px

>>1179975

File: laughingwhores.jpg (162KB, 669x600px) Image search: [Google]

162KB, 669x600px

>anon, what's all this electronics for?
>are you building an iPhone?
>so it doesn't even have Facebook yet?
>seriously?

>>1179977
I hope you are paid for your project and/or has severe autism