18th June 2019
I've just finished the CSCvon8 TTL CPU to the point where the hardware works solidly at 3.57MHz, I can consistently boot the Monitor ROM, and I can consistently assemble programs, download and run them.
This was a big step up from my 4-bit TTL CPU, as it had smaller busses, a simpler ALU, a Hardvard architecture and a much simpler control structure.
So I thought I'd write down some lessons learned during the design and build of this much larger CPU.
This time I built a Verilog version of the CPU where I used (and wrote some) Verilog models of the actual chips that I was going to use. This helped my in several ways.
Firstly, the models helped me understand exactly what each chip was doing. A good example was the 74LS593 register/counter which has a lot of control wires. It took me a long time to "grok" how it worked, and I eventually wrote a blog article about it. By building a Verilog model, it helped me crystallise in my mind what the chip was doing.
Secondly, I could simulate the CPU and see the resulting waveforms in Gtkwave. So, when the CPU was misbehaving, I could see exactly what chip was doing what. If I'd built a behavioural model of just the CPU and not of its components, I would not have seen how each component was interacting with the other ones.
Thirdly, propagation delays ...
You might think it strange, but I never considered the propagation delays through each of the chips when I designed the 4-bit CSCv2 CPU. I guess I was always thinking in the "single-step" mindset, or perhaps in the kHz operating range. I just didn't realise that the signal delays through logic chips would be such a big issue.
Luckily, Tim Rudy who wrote some of the 7400 TTL verilog models had put delay parameters into his models. That got me thinking: I should actually simulate these delays and see if they cause any problems. Well, of course they cause big issues.
Example: when the clock signal goes high, not everything happens instantaneously. It can take 120nS to look up a ROM value and propagate it to the outputs. And if these outputs are control signals, then these will reach the devices being controlled much later than expected.
It took me several minor and major redesigns of my CPU circuit in order to properly deal with the delays. The main solution is to do things on both the rising and falling edges of the system clock, and only on thesse edges. Raise the clock to start things in motion. Let values propagate through the ROMs and through the mux/demux/inverter gates, and let them settle. Then, on the falling edge of the clock, use these new values to load registers or control things.
The "chip model" Verilog version, along with the simulated delays, explicitly showed me where things were going wrong, and I wished I had built this version first.
I had used Kicad before to draw the schematic for my CSCv2 CPU. This time I had to learn it effectively from scratch. I didn't realise that the hidden pins on the components were connected to VCC and PWR, so I manually went in and connected them all by hand. I won't do that again.
This time the circuit was too complex to build it reliably on breadboard. I actually did build a breadboard version to help me get the wiring correct, but I bit the bullet and designed my own PCB. My first PCB!
It cost me about AUS$150 to get five boards built, so it wasn't a miniscule investment. I spent a lot of time learning freeroute, learning about copper fills, getting footprints correct. In the end, I only had two mistakes on the design:
I'm still amazed that we are at the point where someone can design a circuit, lay out a double-sided PCB, and get it professionally fabricated at a reasonable price. I never made my own PCBs before as I didn't want to mess around with the etching chemicals and the messy process. Now, it's all done with open source software and the results are amazing.
I still don't know enough about transmission lines etc., so GHz stuff is still out. My analog knowledge is still deficient. I have yet to try out any surface mount components. But I feel like I've achieved something substantial with the CSCvon8 project, and that's good.