Instruction Decoder assembly

My JLCPCB order containing both the Arithmetic Logic Unit and Instruction Decoder boards arrived Thursday afternoon, nine days after I submitted the Gerber files. As is their practice, each stack of five boards are shrink-wrapped together so the boards can't shift against each other and cause damage.

The importance of return signal paths

In a comment on my post How high and how fast?, Klaus Scheffler pointed out that the "tiny wiggles" in my CLK1 signal could be significant if they exceeded the gate-source threshold voltage of a transistor acting as a transmission gate. He'd experienced issues with this in his implementation, which uses SST215 MOSFETs. Although the datasheet for the Calogic SST215 gives the typical Vgs threshold as 1.0V, the minimum is only 0.1V. My implementation uses the NXP BSS83 with the same specs, so this is a real worry.

[Note to self: the SST211 minimum Vgs[th] is 0.5V, which could provide the needed margin.]

Although I haven't experienced this sort of problem, I've only assembled two of the five boards that will make up my i4004 CPU. Could a problem be lurking in my future?

ALU and ID boards sent for fabrication

I started laying out the Instruction Decoder board in late November 2012, and started the Arithmetic Logic Unit board ten days later. Now, only 147 months later, I finally finished their layout and sent them off to JLCPCB for fabrication. Woo hoo!

Fabrication time is quoted as 5-6 days, and shipping from China adds another 2-4 days. That puts delivery in the first week of April. That'll give me time to do my taxes without this as a distraction.

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.5 pF for the Fairchild FDV301N, and 1.5 pF 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.

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. 

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.

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?

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.

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?