Populating the ALU board

I decided today was a good day to populate the Arithmetic Logic Unit board I had fabricated in March.

I taped the bare board to my solder station workbench (which is separate from the one with all my test gear), then taped the solder stencil down as well. I scooped some solder paste onto the back of an old credit card and used that as a squeegee to apply the paste. The first time I got about half way done before I realized the stencil had slipped and the holes weren't lined up with the footprints, so I removed the stencil and wiped the board clean. Solder paste is sticky and hard to remove, but some 91% isopropyl alcohol on a rag made a quick job of it.

Testing the Instruction Pointer board

My project for April and May was to extend my PicoBlaze-based test framework to test the Instruction Pointer board I built in 2012. I also wanted to update the desktop computer in my electronics lab.

I'd completed the Verilog implementation of the i4004 CPU at about the same time I assembled the IP board, so the obvious way to test it was to strip out the parts of the Verilog that implemented the instruction pointer, and let the IP board perform that function. It seemed to work, but later, when I attempted to run the i4004 Clock program on the hybrid setup, it wasn't stable. Sometimes it would run, and sometimes it wouldn't. I wasn't sure why, but I didn't have a way to capture the failure for analysis.

The most costly phrase

You know what the most costly phrase you can say is? "While you're in there..."

Not my computer

I've said it while I was discussing work to be done on my car. Suddenly a job that should have cost a couple hundred dollars now costs a couple thousand. I went in to get the oil changed and the tires rotated and I said, "while you're in there... the air conditioning seems weak." It turns out that replacing the A/C compressor on my car costs a bit over $2k. But it's about to be summer, and it gets hot and humid here.

The same applies with computers. My primary desktop computer crashed a few days ago. The first attempt to reboot hung. The second got as far as the boot menu before powering itself down. The third reboot wouldn't even bring up the BIOS.

PCB Reflow with a Skillet: Part 1

The skillet I bought is a Farberware 12" x 12" ceramic skillet, model FW6110027877. Searching the web for this model turns up nothing, so it's probably specific to Wallyworld. This idea is supported by the absurdly short power cord, which is barely 2 feet long including the plug. I did my test with the skillet under the vent hood above my stove, which meant I had to use a heavy-duty extension cord to reach the nearest outlet in the wall just to the side of the stove. Annoying shortcuts like this is how they sell at such low prices.

My initial plan was set the skillet's control to its maximum temperature of 450℉ (232℃) and record the surface temperature of the empty skillet in the center and the corners of an imaginary 9" square as it warmed up. I'd been thinking the center of the skillet would be its hottest spot, but it's actually one of the coolest. Within two minutes the center had topped 350℉ (180℃) and the corners hotter, too fast for me to record good readings, so I gave up trying to be scientific about it. By three minutes the center had reached 450℉ (230℃) and was still rising, while the corners were approaching 500℉ (260℃). Clearly hot enough to reach my target temperatures.

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?

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.

Internal data bus pre-charging

I "discovered" an interesting feature in the i4004 internal data bus management this weekend. Maybe the rest of you already discovered this, but it's new to me.

With the Scrachpad Register board working with my test program, I decided to mate it with the Instruction Pointer board I built in 2012. One of my goals was to see if the CLK1 and CLK2 circuits would ring, or if the rise and fall times are slow enough to avoid problems. To my great relief, I see no significant undershoot or overshoot on these circuits, and no ringing at all. Whew!

However, my logic analyzer showed some suspicious timing on the internal data bus. At first it wasn't clear to me what was happening, so I probed around a bit with my oscilloscope. As I was making notes of my observations I realized what was happening, and this also explained a bit of circuitry in the original chip I didn't previously understand.

The Scratchpad DRAM tests found a problem!

My DRAM test found an actual problem on the Scratchpad Register board!

Should I be excited that my test performed its function, or sad that there was a problem with the board?

The test is designed to work in concert with my logic analyzer. A PicoBlaze program implements the March C DRAM test, reading and writing the scratchpad registers repeatedly. If it detects that the data returned from a register isn't the expected value, it pulses an output. This pulse triggers the logic analyzer to log and display the signals it's been recording, which shows me what's been going into and out of the board for the last 25 i4004 instruction cycles. I'd tested this test setup in simulation, using the Verilog Scratchpad board emulation in place of the actual board, so I had some confidence that the test itself wasn't broken. But this was the first time I'd connected it to the real board.

What I saw was the error pulse indicating an error for essentially every attempt to read a scratchpad register. Looking more closely, I saw that the signalling going into the Scratchpad board looked correct, but the data being read was always 1111.

DRAM testing methodologies

Since I decided to do proper testing of my Scratchpad Register board, I thought I ought to invest some time in understanding the type of faults a DRAM array might have, and how to test for them. Given that the array on this board is only 8 rows of 8 bits I'm not really concerned with run-time, but I do want the tests to be thorough.

In my search for useful algorithms I came across this series of videos by Professor James CM Li of the National Taiwan University:

• 16 1 MemTest Intro (32:25)
• 16 2 Memory Test - Classical algorithms (23:41)
• 16 3 MemTest March (25:18)

These are part of a much longer online course (94 videos) on VLSI Testing, but these three address testing RAM. The total run time for all three is only 1 hour 21 minutes. Professor Li speaks English with a pronounced accent, but his pace and careful enunciation make him easy to understand (unlike several videos by others I tried to watch).

I think I caught one small error in his explanation of the answer to one of his "quizes", but otherwise the content seems solid and is explained well.

Scratchpad Register board signalling

One of the prerequisites for testing my Scratchpad Register Array board is to get a clear picture of the signalling necessary to make it function outside of the rest of the i4004 CPU's circuitry.

Years ago I split the i4004 CPU into functional chunks, each of which would become a separate PC board. In doing so I tried to keep related circuitry together to minimize the inter-board signalling. Thus the Scratchpad Register board includes many subcircuits:

• 8-row x 8-bit DRAM array
• 3-to-8 row decoder
  
• 3-bit row refresh counter
• 3-bit address latch
• 3-bit 2:1 address multiplexer
• 4-bit 2:1 data output multiplexer
• 4-bit 1:2 data input demultiplexer
• Miscellaneous state decode logic
  

The inclusion of these subcircuits means the interface to the board is somewhat more complicated than it would be with direct access to the DRAM address and data signals.

To read and write the Scratchpad DRAM array, I need to emulate the execution of one of the i4004's instructions. The only instruction which allows a single Scratchpad register to be written is "XCH", which exchanges the contents of the accumulator and the specified register.