Monday, March 18, 2024

How high and how fast?

Most of the circuitry in the 4004 CPU and other MCS-4 family chips uses a MOSFET to actively pull a signal toward Vss, and a "load" to passively pull it back toward Vdd. In the real 4004 CPU, a "load" is a MOSFET with its gate connected to its drain, but designed so it works sort-of like a resistor. In my re-creation, a "load" is a real resistor.

When I did my initial breadboard tests of bits of circuitry, I used 10K ohm resistors for loads. I chose this value simply because I happened to have a bag of a hundred of 10K ohm axial resistors left over from another project. Given the low input capacitance of the two MOSFET types I am using (9.5pF for the Fairchild FDV301N, and 1.5pF for the NXP BSS83), it seemed a reasonable choice.

When I began assembling my boards, I worried that 10K loads wouldn't give good rise times. Back when TTL logic was standard it was common to use a 4.7K pull-up resistor on open collector outputs, so I used these instead. I also didn't understand how "bootstrap loads" worked, and thinking this was a rise time issue I used 2.2K resistors for these. This seemed to work pretty well on the Instruction Pointer board, but I had no engineering data to support these choices.

Friday, March 15, 2024

Arithmetic Logic Unit board fully routed

 Here's the Arithmetic Logic Unit board:

All nets have been routed, and the design rule checks run without error. 

Tuesday, March 12, 2024

Instruction Decoder board layout complete

 Here it is, the (hopefully) final layout of the Instruction Decoder board:


Like the previous two and several to follow, this board uses stacking connectors to make the connections between it and the other boards that make up the i4004 CPU. Initially I thought all the inter-board connections could be made through the connector on the right, but once I'd split the master schematic into five smaller schematics I realized that this board and the Arithmetic Logic Unit board had so many connections that a second connector was needed. Thus the connector on the left was added to the designs.

I thought I was done with this board a few days ago, but while checking the connector pinouts against my master spreadsheet of interboard connections I realized there were six that didn't have pin assignments. These nets were fully routed within the board, but didn't connect to pins on a connector. This would have been something easily correctable by adding wires to the board later, but of course it's better to have caught it now.

There are a few reasons I'm I haven't sent this board to JLCPCB for fabrication. The primary reason is that I can't test this board without the ALU board; my FPGA interface board just doesn't have enough I/Os to be able to connect to all the ID board outputs. So there's little benefit to sending this one out without the ALU. Secondly, the shipping cost for this board alone is the same as for this board and the ALU board together, and ordering them together will save me about $25.

The only change I might make to this board before ordering is to reduce the layer count from 6 to 4 by merging the interior signal layer into the power distribution layer. The cost difference is only $6, but with resistive pull-ups I don't need a full power plane and it annoys me to have the extra layers.


What about the ALU board? There are still 60 unrouted nets remaining. A portion of the circuitry is incompletely routed, and I'm not happy with the component arrangement in that portion. I'm thinking it'll probably be sometime next week before it's finished.

Saturday, March 9, 2024

JLCPCB design rules for Eagle

A couple of days ago I "finished" routing the Instruction Decoder board. To be sure JLCPCB wouldn't have manufacturing problems, I used the same Eagle design rules file (DRU) I'd used to fabricate the Scratchpad Register board.

The Scratchpad board's DRU file started with the Eagle DRU file JLCPCB posted on GitHub for use with 2-layer boards which I modified for the 4-layer stack-up. Since JLCPCB's published capabilities allow tighter spacing on 4- and 6-layer boards I assumed this would be safe. The Scratchpad board works, but was this a good assumption?

Thursday, March 7, 2024

The Instruction Decoder PCB

When I started my efforts to construct a discrete-component replica of an Intel 4004 CPU in June of 2012, I realized that I was going to have to split the CPU into several parts. This was largely dictated my hobbyist license for the Eagle CAD program, which limited me to placing components within a 160mm x 100mm rectangle (that's 6.3 x 3.9 inches). So I split the CPU into five boards:

  • Instruction Pointers
  • Scratchpad Registers
  • Instruction Decoder
  • Arithmetic/Logic Unit
  • Timing and Input/Output

By October 2012 I'd assembled a working Instruction Pointer (IP) board, and tested it using an FPGA to substitute for the remainder of the CPU.

Sunday, March 3, 2024

Rant: Ubuntu RAID checking

In addition to a 40-year career as a software engineer specializing in operating systems, I've also managed corporate and personal computer systems. It should be no surprise, then, that my primary home computer system has RAID 1 arrays for several critical file systems.

Some years ago, while far from home, I wanted to demonstrate the utility of RAID arrays to a client. As I explained the up-time benefits in case of a failure, I logged into this system remotely and displayed the array status. To my surprise I found that one of the drives in the array had failed! The system continued to run, of course, because of the redundancy. This perfectly illustrated my point to my client.

RAID arrays need periodic checking to identify any errors that may have developed. For years this was kicked off by a cron job at 1 am local time on the first Sunday of each month. However, apparently with the adoption of systemd a few years ago, the start time changed. It now starts at a random time in the 24 hour period after 1 am.

Today it randomly started at 9:33 am, which was shortly after I sat down at my computer. It's now 12:30 pm, and these checks will run for another two hours. While this is running, applications randomly freeze as they compete for access to the file systems.

What brain-dead idiot thought that starting this at a random time on a Sunday was a good idea?

Wednesday, February 28, 2024

Data bus charge redistribution

In my previous post I mentioned an anomaly I'd noticed in the data bus state during a period I believed it should be floating but stable.

Klaus Scheffler mentioned in his comments that he'd seen the same thing on his board. This got me wondering if I could use the simulator to help me understand this behavior. Sure enough, the sim also shows an indeterminate state on the data bus under similar conditions.