Yet another digital clock

The classic *nix first program is one that prints "Hello world" on the console. For me, my first project seems to be a digital clock. I made one when I started experimenting with Microchip PICs in 1999. A few years back I made one using my Verilog emulation of an Intel 4004, So it made sense to make one as my first project using the PicoBlaze soft processor.

After recording this video I left it running overnight. The next morning, to my consternation, I found it had stopped with the display showing. 11:01:12.

Running Xilinx ChipScope under Ubuntu

I've belatedly realized that ChipScope Pro is a free feature of Xilinx ISE 14.7. While trying a simple example I ran into two problems, both of which I have managed to work around.

Xilinx firmware download problems

I've discovered an error in my post Making Xilinx ISE iMPACT 14.7 run on Ubuntu 20.04. I've corrected the error, and added a note explaining that a previous version contained an error.

When is impedance matching critical?

One of the questions I asked myself in my previous post was when does it become critical to have a impedance-matched traces? Today I came across an interesting presentation by Rick Hartley, then a Senior Principal Engineer at L-3 Avionics Systems, now Principal Engineer at RHartley Enterprises.

In his presentation, Rick Hartley states that impedance matching becomes critical when the trace is 1/16th the wavelength of the signal in the propagation material. Here's the relevant slide, giving the formulas.

Proof I'm not an RF engineer

Back in 2013 I did a project with a Nordic Semiconductor nRF24LE1 chip. This is an 8051 compatible microprocessor with a built-in 2.4 GHz wireless transceiver. Conscious of how poor my knowledge of RF design is I followed the sample layout of the RF section exactly for the antenna. And by "exactly", I mean I overlaid the sample Gerber file onto my PCB layout and used that to position the components and route tracks. Without the proper tools to tune an inverted-F antenna like on the original, I used a commercial 2.45 GHz chip antenna with a 50 ohm impedance.

Everything seemed to work exactly as designed except the RF section. I could not get the board to talk to a commercial board using the same nRF24LE1 chip. Clearly I'd botched something.

I called a friend who is an Extra-class amateur radio operator and asked his advice. He reviewed my choice of passive components in the RF section and had me change out a couple which he deemed inappropriate for use at 2.45 GHz. This made them work when talking to each other, but they still wouldn't talk to the commercial boards and had significantly reduced range. Without the test equipment necessary to look at a 2.45 GHz signal, the project got shelved.

Testing... testing?

In a comment on my last post, Klaus Scheffler asked: 

How do you plan to test the register board? I first populated only all the DRAM cells without column and row selection logic, connected an Arduino to all column and row lines, and tested the DRAM bit by bit.

That's an excellent question.

Scratchpad board assembled

I've finished assembling the Scratchpad Register board. Here it is, in all its glory:

Poor Prior Planning Problems

Having received my new Scratch Pad Register boards from JLCPCB, I collected the parts I needed to populate the board. Everything was going well until I opened the container of solder paste: it was completely hard and dried out. I really should have anticipated this, since the last time I used it was three years ago. *sigh*

Scratchpad Register board delivered

This afternoon a DHL courier dropped a package at my doorstep. JLCPCB shipped it with a signature release required, but I waived the signature in advance.

I'm old enough to remember when placing a domestic mail order came with an "Allow 6 to 8 weeks for processing and shipping" disclaimer. Yet I sent this order to China electronically only 10 days ago. A week ago this physical package was in China, and now I'm holding printed circuit boards.

Scratchpad Register board ordered

After starting the layout of the Scratchpad Register board in August 2012 — yes, 11 years ago — it has finally been sent out for fabrication by JLCPCB in China. Here's what they say it will look like:

 

If they keep to schedule, production should start Monday (China time) and take 3-4 days. This would have the boards and stencil ship Friday-ish. I opted for the default DHL Express (2-4 day) shipping so they should arrive sometime the following week.

Scratchpad board layout progress

I've just about completed the layout of the Scratchpad board for my Intel 4004 CPU recreation. The only big changes in the layout since 2016, other than the signal routing, has been to reorient some of the decoding sub-circuits on the right side of the board.

Congratulations to Klaus Scheffler

Way back in 2012 I came across the Intel 4004 35th Anniversary Project, which had unearthed the original schematic for the Intel 4004 CPU and related chips, and got the idea to implement the CPU using discrete components. This seemed like the kind of project that would teach me a lot, while not representing much of a risk. After all, the Anniversary Project had already done this once; I'd seen it running in an exhibit in the Intel Museum.

I had the "hobbyist" license for Eagle, which limited me to 100mm x 160mm boards. This was nowhere near large enough to implement the entire CPU, so I divided the CPU into several smaller modules. I decided my first board would implement the Instruction Pointer module. 

After I assembled and tested the Instruction Pointer board, Tim McNerney informed me that they'd run out of time and funds to do a discrete component implementation, and the museum exhibit runs on a PC. Talk about a surprise; I didn't realize I was blazing a new trail. Still, thousands (millions?) of the original chip proves the basic design.

I'd fully intended to complete my implementation of the CPU, but Real Life intervened and the project got shelved. Since then I've corresponded with several people who wanted information about my implementation, and I've always been happy to comply. The 4-terminal MOSFET I used, the NXP BSS83N, went out of production, and we discussed alternatives.

Now the renamed 50th Anniversary Project has announced that Klaus Scheffler has succeeded in constructing a complete, working CPU from discrete components. Congratulations to him! 

I was hoping to find details of their implementation, but the Anniversary Project website doesn't have much more than a photo of the board. Not having the constraints imposed by my Eagle license, he was able to put everything on a single board. To someone who has studied the schematics and original chip design, the functional blocks are readily apparent. I know this was Tim McNerney's original intent, and it would be much more useful in a museum exhibit than my stack of smaller boards.

Klaus tells me he used the SST-215 MOSFET throughout, which is quite similar to the NXP BSS83 I used in critical places. He also mentioned  it's currently running at 25 KHz, but I don't know if that's its maximum speed.

I still plan to finish my CPU re-construction at some point. Being "first" was never part of my plan, as I thought Tim had already done this when I started. I have all the parts I need except the boards themselves, and it would be a shame to have come this far and not complete the project.

Back to the Scratchpad board

i4004 CPU Block Diagram

As I mentioned in the previous post, I've started working on the Scratchpad board again. This is the board that implements the 16 x 4-bit array of internal registers.

Internally, as depicted at the far right side of the i4004 CPU block diagram, this is actually an 8 x 8-bit DRAM array. It's quite similar to the 4 x 12-bit array used in the Instruction Pointer, which I successfully implemented some years ago.

Problems importing Eagle projects into KiCad

This time last year ago I tried importing my Eagle project for the i4004 Scratchpad board into KiCad. My reasoning was that I'm now much more familiar with KiCad's user interface than Eagle's, and the KiCad PCB router has features not available in Eagle v7. (Later versions of Eagle have improved the router, but I'm not paying Autodesk $70/month to rent it.)

It took a few experiments to get KiCad's importer to produce results I liked, but eventually I checked the results into my version control system (I use Git). Then I began fixing the few visual problems I noted (some of these have been fixed in KiCad v7). Then I got busy with other things again and, well, you know how these things go.

A few weeks ago someone posted to the KiCad forum that he was having problems importing an Eagle project. I did some more experiments importing some other Eagle projects and was able to help him through many of his issues, most of which were misunderstandings of the difference between KiCad and Eagle. However, one serious problem remained. KiCad has a tool that lets you cross-probe between symbols and nets in the schematic and footprints and tracks on the board. This is a critical feature, but it only worked with a small number of nets and tracks in an imported Eagle project. Further experiments exposed a serious flaw in the Eagle schematic importer.

Eagle supports schematics with multiple sheets. This is convenient when a schematic is too large to fit comfortably on one sheet. However, Eagle doesn't support hierarchical schematics. All Eagle nets are global to all sheets. This is very different than KiCad, where nets are local to a sheet unless explicitly made global by applying a global label to the net.

When KiCad imports an Eagle schematic, it only creates global labels for the nets that connect on multiple sheets; all other net names are dropped. However, the imported board retains all the net names assigned by Eagle. Since the cross-probing tool depends on matching net names, the result is that only inter-sheet connections and certain supply nets can be cross-probed.

If you're starting with an Eagle schematic and create the board in KiCad this is may not be a problem. However, if you've already created the board in Eagle, or explicitly named nets in your Eagle schematic, this may be a huge issue for you. Because I wanted to maintain the same net names used in the i4004 simulator, all of my nets have explicit net names. Losing these net names is a non-starter for me.

I reported this bug to the KiCad development team (Issue #14620) and proposed several possible solutions. However, I don't expect to see a fix for this any time soon.

Thus I've reluctantly abandoned my plan to use KiCad for further development of the i4004 CPU recreation. Instead, I've started working on the Scratchpad board using Eagle v7 again.