Looking for TTL (7400/CMOS) retro forum

[bitman]

I'm looking for a forum where I can ask my uninformed questions about CPU design using TTL/CMOS chips.  I understand that chips and design principles by all means aren't current or relevant today, so I prefer not to add those topics to this board.

Example of questions: Design principle of the ALU - does the ALU use a latch for the result, or should it write straight to the bus - based on the issue that the ALU is the only component that will read from two registers/latches - all others only use one patch/register active at a time. I find myself duplicating a bus to the ALU which concerns me (registers/latch does not just to the bus but to the ALU too).

In other words - I'm not attempting to build another ALTAIR 8800 - I've put together a sample CPU from scratch and I've trying to improve the design and hence I've got questions.

[rstofer]

You can register the ALU output or not, it's up to you.  It all comes down to timing and whether speed matters.  If, in one clock cycle, you intend to fetch an operand, do some ALU work, send the output through a bus buffer and try to write it into memory, it had better be a really long cycle.

But the other side is complexity and pipelining.  If you are going to waste a clock by registering the ALU, the cycles can be faster but there are more of them.  What else can you be doing while the extra clock cycle is writing back to memory?

Which brings up von Neumann versus Harvard Architecture.  In the von Neumann approach, all memory is equal.  As a result, you can't be fetching while you are writing back.  In the Harvard approach, program memory is separate and on a different bus.  This allows for overlapping fetch and result write-back.

And that brings up RISC architecture.  Never read or write an ALU operand to or from memory.  All ALU operations occur between registers and there are a  very few instructions that load or save registers.  Then we have two images of the register bank so we can select any register for either side of the ALU.  When we write back, we write both images simultaneously.  In any event, it is common to use a 5 stage pipeline for RISC instructions.   See "Digital Design and Computer Architecture - ARM Edition" by Harris and Harris.

One approach to studying timing is to use Excel spreadsheets to explore the various instructions. Really, the design of the datapath is the bulk of the work.  "Microprocessor Design Using Verilog VHDL", written by one of the original Z80 designers, goes through this process for the Z80 CPU.

I would hope you would keep your questions over here but in the Micros and FPGAs forum.  There are some very knowledgeable folks who haunt that forum.

[bitman]

You can register the ALU output or not, it's up to you.  It all comes down to timing and whether speed matters.  If, in one clock cycle, you intend to fetch an operand, do some ALU work, send the output through a bus buffer and try to write it into memory, it had better be a really long cycle

Thanks! Performance isn't my goal here. I've build this with so many LEDs to illustrate the workings, and with a very slow clock - with a manual override so I can step through each micro-instruction and show what happens. So it's not that important if i need one or two cycles to complete an instruction. The current micro-code is 8 steps with "early termination" if it only takes 2 or 3 steps to complete an instruction.

My current design allows me to show on a single clock impulse data in two registers, the ALU reacting and sending it's result out on the bus. The next instruction would then grab this data (it's not latched). But it's a mess - and instead I came up with using a simple 8x8 bit RAM, but that doesn't allow me to parse in two values at once. As an effect, I'll need 2-3 clock cycles to do what just took 1 clock cycle before. HOWEVER - I'll just have one bus for all communication. Currently, all registers/latches are connected to BOTH the BUS and the ALU. This makes the wires a bit messy and it seems very limiting. Hence my little experiment.

I'll definitely take a look at documents that describe the Z80 - but note, I'm not trying to emulate or replicate existing designs.  My goal is more to understand the design decisions by coming up with one on my own. Both from a simple logic gate perspective, but from a electrical side too (fanout and other requirements), understanding bus termination and a lot more.  While I know CPU design on the micro-code level I struggle a bit with the electrical one and now I realize I probably need to think a bit about optimization to avoid inter-connecting everything.

Btw. I don't mind using this forum. This just felt a bit outside of the topics and I was looking for a more suitable place to ask my "dumb" questions about CPU design.

Thanks again.

[rstofer]

For the Z80 book, it's the methodical approach that's important, not the details of the Z80.

The 8x8 regster problem is what I touched on above.  Instead of one 8x8, you use two.  So you now have an A and a B operand for the ALU by reading A from one chip and B from the other.  The trick is to write both sides when you store a value in the registers.

If you Google for LC3 or LC3b, you will see this approach used in a small RISC core.  Slide 05-20 here:

https://classes.soe.ucsc.edu/cmpe012/Summer09/notes/05_LC3_Architecture.pdf

The LC3 project is used by many universities as their example RISC architecture and there is a lot of information on the Internet.  I have it running in an FPGA (at 100 MHz).  I built it up as a 'drop-in' core for other projects.  The project includes a C compiler and an Assembler.  The book is by Patt and Patel:

https://www.amazon.com/Introduction-Computing-Systems-Gates-Beyond/dp/0072467509

I might look for one used at Alibris.com.  They apparently have the first edition:
https://www.alibris.com/Introduction-to-Computing-Systems-From-Bits-and-Gates-to-C-and-Beyond-with-CD-ROM-Yale-N-Patt/book/8383744

There is enough information on the Internet to build the CPU without the book.  In fact, the book starts at the very beginning - on, off, on, off - and that's a little too far back.

http://users.ece.utexas.edu/~patt/05f.360N/handouts/360n.appC.pdf

The 'b' version brings byte addressing.  Note that the state diagram and hardware layout are included in this document.  Everything you really need to know is there.

[tggzzz]

If you want to minimise the number of ICs, cost and power supply, why not design a bit-serial processor?

The first computer I used in anger (one is still working in TNMoC) was bit serial, although there were parallel computers with more-or-less the same instruction set.

A company I used to work for produced an avionics computer for tatical air navigation; it was a bit-serial TTL machine, to reduce volume and power.

[rstofer]

In other words - I'm not attempting to build another ALTAIR 8800 - I've put together a sample CPU from scratch and I've trying to improve the design and hence I've got questions.

Building things out of chips is a lot of fun - except when you have to strip out a lot of wire and wrap it over again as the design changes.  I have done a lot of wire-wrapping over the years and, frankly, I'm glad to be rid of it.  But it was fun...

Even if the end project is going to use discrete devices, I would still model the thing on an FPGA.  Or, I would write a simulator.  It should be easy enough to write modules that react pretty much the same as MSI devices.  I would think coding up a 74181 would be pretty straightforward.  The dual register bank would be trivial.  And so on...  I would want to be certain the logic worked properly before committing to wire-wrapping.  The simulator is problematic to code because you can't really get the required parallelism without some really tricky code.  FPGAs specialize in parallelism.

Here is a book that takes it to extremes!  They design and build an entire CPU using nothing but NAND gates.  It takes a lot of NAND gates to make up 64k of RAM so I'm not sure their approach makes sense in the physical world but the project itself is a coding exercise.  It's a lot of fun, actually.

http://nand2tetris.org/

[bitman]

In other words - I'm not attempting to build another ALTAIR 8800 - I've put together a sample CPU from scratch and I've trying to improve the design and hence I've got questions.

Building things out of chips is a lot of fun - except when you have to strip out a lot of wire and wrap it over again as the design changes.  I have done a lot of wire-wrapping over the years and, frankly, I'm glad to be rid of it.  But it was fun...

It is fun. It's more a hobby right now for me, and a way for me to put into "real life" what I know on paper. I've been doing computers since the late 70ies (my first was a mainframe) but only from the software side. Very very little was hardware control and what I've done there was through 3rd party libraries.  This gives me a chance to actually create what I know from theory and use it to explain at makelabs what actually happens in a CPU - what makes it work. And I don't think a simulation will do well here. I've done those myself, and it never showed me how complex it was to get multiple gates to interact in the right way.

As for cost - I've got the chips and equipment already. Actually, I already have an early prototype that I'll need to "fix" to complete the microcode. The fixes are all about making sure the fanout power is enough and that the timing works. While I knew buses use different timers, I wasn't really aware that CPUs internally had multiple clocks to synchronize with and it wasn't until this build I realized why.

So there are several layers here that makes me choose not to just do a software emulation. My interest in electronics does I want to understand the challenges, and my interest in teaching/educating makes me what to show something physical. Granted, it's a BIG thing right now - 1x1m of chips - and it's only growing (thinking about adding IO/IRQ - but sure).

But yes - every time I redesign it's a lot of work/rework. And often I forget just a single wire and things are "odd". However, this is teaching me how to do diagnostics too - ok it FORCED me to learn how to do that - so I'm picking up quite a bit. That doesn't mean I don't have a ton of questions - which was why I asked for the right forum.

A short illustration of my "newbie-ness" - I couldn't figure out why when I applied 5v (high) to my bus, current went up 20-30mA per bit. All 8 bits on resulted in 1.5A at 5v which made no sense. Each bus line does have an LED and a 100ohm resistor - plus a 500kOhm resistor to ground (to pull it low). It made no sense to me - other designs had no issues - the LEDs will absolutely drive more current than a real design would but not that much.  It took me a long time to find that one of my 3-state buffers that connected to the bus was not turned off and hence it created a short. I'm pretty sure anyone with better understanding of electronics would have been able to figure that out much faster than I did. I struggled for days to figure it out, and had begun setting up a simple circuit to illustrate the issue (isolate it) when I discovered the "bad" buffer.   Those kind of lessons I would not get from a simulator. 

[rstofer]

No and these types of problems don't happen in FPGAs either because buses are usually synthesized as multiplexers.  A couple of months back I was playing with a new Z80 machine and I set my power supply to severely limit the current.  Turns out I had a jumper misplaced and there was a bus collision.  I really like current limiting power supplies.

I like discrete chip projects.  I don't want to build another one but I like them.  I also like microcoded designs.  I did an IBM1130 microcoded design way back in '74 or so using blown-link PROMS.  At the time, RAM wasn't available so I put it on the shelf and bought the Altair 8800 when it came out.  Forty years later I built the entire system in an FPGA.  Still use it from time to time.  There's just something about your 'first' computer.