Scoping the CCLK line

Given how much time I spent fretting over the layout of the configuration clock (CCLK) circuit (1, 2, 3, 4), it seemed strange that I hadn't gone back and checked what the signal actually looked like on the board.

Running the Busicom software in a Spartan-6

Eight years ago I decided I wanted to learn about programmable logic: PLAs, CPLDs, and FPGAs.

About the same time, I became aware that a group of engineers and computer history buffs had gotten Intel to release the schematics for first commercially-available microprocessor: the Intel 4004 CPU. They'd also retrieved the software that drove the first commercial product that used the i4004: the Busicom 141-PF.

I decided to re-create the i4004 CPU in an FPGA.

It turns out that's a lot like learning to swim by attempting to cross the English channel. But I've never been known to shy away from a challenge.

Load testing the AC Mains supply

In the previous post AC Mains power supply I asked, "I wonder what will happen when I fire up the VFD filament and +30V supplies, plus a complex FPGA design?" Well, there's no time like the present to find out.

What I did was to take the printer test I described in the post Testing the printer interface and added the VFD display test I described in the post Proof of Life. The two don't interact so this was easy to do.

With the bench output supply set to 7.5VDC, the board draws about 124mA. This varies depending on how many digits and segments of digits are illuminated.

AC Mains power supply

This morning I wondered what the output of the AC Mains power supply would look like while the printer was running. I hate leaving questions unanswered, so I took a look:

This is a screen capture from my oscilloscope connected across the unregulated DC supply. The vertical scale is 2.00 volts per division, DC coupled, and the horizontal is 100 milliseconds per division. The single-sweep trigger is set for the negative edge at 8V DC.

With the AC power applied and the regulators turned off, the unregulated output of the bridge rectifier is 10.5 volts. Turning on the regulators drops this to about 10.1V. Printing the same eight-character pattern as before pulls this down to about 6.5V as the motor starts up before stabilizing at about 7.5V with a 0.75Vp-p, 120 Hz ripple. If you look closely you can pick out the seven small dips where the print hammer solenoid fires, with the big valley at the end occurring when the solenoid fires to print the eighth character and is held engaged to trigger the paper feed. Once the motor shuts off the big filter capacitor recharges with the classic RC charge curve.

Testing the printer interface

In November I tested a prototype of my FPGA interface to the M32-TL printer using the Lattice iCEblink40-HX1K and a circuit assembled on solderless breadboard, described here. Since this worked well I was pretty sure this would also work on the P170-DH replacement board. But there is always a chance something didn't get laid out correctly, or something I overlooked.

When I put the replacement PCB into the P170-DH shell last month, I decided I really didn't want to be taking the board out again if I could help it. All the logic is on the exposed side of the board, and removing it requires removing 20 small screws. So I also connected the AC mains transformer and the printer. After proving out the keyclick sounder, the last untested subsystem was the printer interface.

Keypad remapping

When I wrote the previous blog entry Sunday I fully expected I'd implement the first option I listed, which was to scan and decode the Canon P170-DH keypad matrix, then convert these keycodes back to Busicom 141-PF matrix signals. As usual, things did not go according to plan.

Busicom keyboard interface

Now that I know the replacement board's keypad works, I started thinking about how to interface this to the emulated Busicom 141-PF calculator's "circuitry".

The Busicom scanned its keyboard using two MCS-4 family chips: a i4001 ROM and a i4003 shift register. A ROM may seem to be an odd device to use in this situation, but the i4001 also provided a 4-bit I/O port. The shift register provided 10 output pins and a simple way to walk a "0" bit down the outputs in sequence. Thus the keyboard was arranged electrically as 8 x 4 matrix. The shift register selects which of the eight columns is being read, and the I/O port reads which of the four rows contains a pressed key, if any. The last two "columns" selected by the shift register return 4-bit coded values from two slide switches.

This dictates the interface my emulation must present.

Keypad and Switch tests

For some reason I've been hesitant to test my keypad design. Maybe because it's something that is either going to work right or I'm going to have to scrap the board and have another one fabricated. But I figured it was time to find out.


High on my eventual success with the keyclick sounder, I decided to test the keypad and associated slide switches. My original plan was to do a simple "walking ones" test to make sure each keypad column could be driven high or low. However, because I decided to put Schmitt trigger inverters between the keypad row tracks and the FPGA pins, I couldn't do the same for the rows. To see what the row inputs were getting I decided to drive the 32-bit debug connector with both the column outputs and the row inputs. Having gone that far I added the inputs from the slide switches to the debug connector too.

Keyclick sounder tests

Today dawned dreary and rainy, so I decided I needed to spend some time working on the Canon P170-DH calculator rebuild. I pulled out my checklist of things that needed testing and decided to start with the audible keyclick sounder.


Before I decided I could make the fluorescent display of the P170-DH work, I decided that it would be advantageous to provide an audible feedback to indicate that a key had been pressed and recognized. I described my search for the "right" sound in my posting Tick... tick... tick... a couple of years ago, and I did a proof of concept using a 556 dual timer and a piezoelectric sounder. But I'd never actually tried driving the final circuit from an FPGA, figuring there really wasn't much to test with such a simple circuit.

Testing the External I/O interface

I finally got time to test the new P170-DH board's external I/O interface with the Spartan-3E Starter Kit's PS/2 interface. I found the results most interesting, and not quite what I expected.

Testing the Verilog RAM-based VFD driver

Over several evenings I wrote the Verilog to drive my VFD from a RAM-based i4002 RAM emulation. The comparison between this and the previous one is apples and bananas, which is to say they're not very similar. But I did get it working.

This evening I finished debugging in the simulator and loaded the bitstream into the FPGA through the JTAG. The test is set up to increment the content of the emulated WR register twice a second.

Although most people reading this blog wouldn't have trouble picturing a counter incrementing twice a second here's a video anyway, showing the carry from the low order digit to the higher digits as it counts from 1990 to 2012.

 

Spice simulation of the External I/O

I got to wondering how accurately my "back of the envelope" calculations modeled the External I/O interface circuit. So I set it up in LTspice:

The best laid plans

When I decided to add an external interface using PS/2 compatible 6-pin mini-DIN connectors, one of the ideas was to be able to interface it with my Digilent Spartan-3E Starter board (on sale now, btw) which has a PS/2 connector. Rather than connect it to the FPGA with resistors, I decided to use SN74LVC1T45 level translators in a configuration taken from the Digilent PmodLVLSHFT level-shifter:

One of eight channels of the PmonLVLSHFT circuit

Proof of Life

I got tired of taking baby steps. Here is the VFD in operation on the replacement PCB:

Supplied with 5 VDC, the board draws about 205 mA in this configuration. The digit values are hard-coded, and I haven't coded the RAM-based implementation described in the previous post.

The odd brightness variation is a beat frequency between the VFD's refresh rate (5.85 ms or ~171 Hz) and my phone's camera. It's not visible to the naked eye.

i4002 emulation and the VFD interface

The last time I posted on interfacing a VFD with the Busicom emulation I commented that "All I need to do is connect the WR register in an emulated 4002 to my VFD driver logic. […] I can peek into the internal circuits and use the contents stored there." The Verilog I wrote to test the VFD assumed this would be true. The effects of this can be seen in the surprisingly high resource requirements I noted in my post Packing worms into a can, though I didn't realize it at the time.

In software, the emphasis is on abstracting the implementation away from the underlying hardware. This was true when I started back in the 1970s, and the emphasis has only gotten greater as years have passed. It's so extreme now that many recent Computer Science graduates no longer understand anything about cache line utilization or translation lookaside buffer churn. I owe much of my professional career to bucking this trend and understanding how software interacts with hardware in great detail. But here I neglected to consider the hardware implications of this design decision.

VFD Driver walking-one test

I ran my walking-one test on the Vacuum Fluorescent Display drivers. Initially I had some confusion because I'd forgotten that the VFD mounts on the bottom (keypad) side of this board, rather than the top (component) side as with my VFD driver test board. Thus the ones walked from the right side of the board as I look at it, rather than from the left as I'd intended. But the +30V boost regulator and all of the drivers are working as planned.

With this test configuration loaded I measured the supply current. While supplying 7.5V the board draws about 36 mA, and about 52 mA at 5V. That's about 270 mW, which is in the range I expected to see.

Found my lost electrons

To confirm my analysis, I told iMPACT to verify the contents of the Flash ROM with the image I'd previously written. This loads the JTAG-to-SPI core, which sets all the non-SPI I/O pins to PULLUP. While this was running I noted that the supply current spiked to about 200 mA. I measured the voltage on the LTC3494 and SN6505B enable pins and found them just under 3V; they need to be below 0.3V for these chips to be disabled.

Having created valid test conditions, I changed out the 100K ohm pull-down resistors on the VFD +30V boost regulator and filament transformer driver, replacing them with 750 ohm resistors. Now when I access the Flash ROM from iMPACT the ammeter now barely twitches and the enable pins sit at about 0.25V. Satisfied, I changed the pull-downs on the printer drivers circuits.

I also chased down the problems with my walking-one test of the debug interface. When I reattached the FPGA to the board after reorienting it, I didn't remove all the solder from the pads. My thinking was that since I couldn't put down new solder paste, I'd just re-heat the solder already there. The problem is that now the FPGA isn't sitting flat, and some of the pins (fingers?) didn't get soldered. The debug interface pins that were misbehaving were floating. By careful inspection I found several such pins and fixed them. Or at least I think I fixed them.

With this in mind, my next test will be to do the walking-one test on the VFD interface. This will show whether any of those pins are disconnected. I wrote the code this evening, and I'll run the test on the board in the morning.

Where have all my electrons gone?

I think I found the reason the +30V boost regulator is getting turned on, and it isn't pretty.

Both the LTC3494 boost regulator and the SN6505 transformer driver have active-high enable inputs. The control inputs in the circuits I designed to drive the vacuum fluorescent display's grids and anodes are NPN transistors in common emitter configurations. The printer and keyclick sounder circuit inputs are N-channel FETs in common source configurations. All of these want to see inputs of no more than 0.3 to 0.5 volts to remain off.

When a Spartan 6 FPGA resets it has to load its configuration from external storage. During this period it normally configures its I/O pins with soft pull-ups. In this state, each pin could source up to 500 µA. Because this would turn on all my external circuits, I disabled this behavior by strapping the HSWAPEN configuration pin high.

Apparently I didn't notice this paragraph in application note XAPP974, Indirect Programming of SPI Serial Flash PROMs with Spartan-3A FPGAs:

Once the FPGA has been configured with the JTAG-to-SPI core, the unused I/Os are set to PULLUP, activating the internal pull-up on the I/O. The user can still pull down the I/O using a 1.1 kΩ resistor if dictated by system requirements.

Gee, thanks Xilinx! Wouldn't it have been better if the JTAG-to-SPI core honored the state of the HSWAPEN input?

With all 25 of the VFD drivers enabled, the +30V boost regulator is trying to drive 25 pull-down resistors presenting a load of about 752 ohms, and that's without the VFD itself attached. This circuit isn't intended to source 40 mA or more, and needs to be shut down to avoid damage to the circuit due to overloading.

If I disable the +30V boost regulator it doesn't matter if the VFD drivers are enabled, so I won't bother with them. Thus there are five circuits that may need to have their pull-down resistors reduced from 100K, listed here in decreasing importance:

1. The VFD +30V boost regulator
2. The printer hammer driver
3. The printer motor driver
4.  The VFD filament transformer drive
5. The keyclick sounder drive

The choice of resistor value is a combination of the need to keep the voltage at the input pins below their threshold values with 500 µA sourced from the FPGA pin, and the limited selection of 0603-sized resistors I have on hand. I've chosen to use 750 ohm resistors.

I probably won't change the keyclick sounder driver pull-down from 100K. Doing so would reduce the draw on the +7.5V supply by 7.5 mA during Flash ROM programming, at the cost of an additional 4.4 mA from the +3V3 supply. But that extra draw on the +3V3 supply would occur any time the keyclick sound is being generated. So that's probably a bad thing, and nothing terrible will happen to the piezoelectric sounder if it's energized for a minute or so during Flash ROM programming.

It's ALIVE!!!

Last night I created a very simple Verilog test configuration. It drives the two debug interface clock lines with true and inverted versions of the 20 MHz external clock, and then walks a single "1" bit down the length of the 32-bit debug interface data bus. It's such a trivial setup that I didn't even bother simulating it.

This morning I went down to my lab to see whether it'd load into the FPGA through the JTAG interface. As I mentioned in my post "Contemplating worst-case scenarios", this is a critical step. If I've made an error in the board layout or some minor aspect of the design, I can still test out the other areas of the system. But if I can't load a bitstream into the FPGA via the JTAG interface the only thing I could do is respin the board and hope I hadn't made any mistakes that would force me to respin it again.

Sanity checks are never wasted

I checked the VFD +30V boost regulator and filament driver by pulling their enable lines high with a clip lead and a 1K resistor and they looked good. With nothing left to test I sat down to populate the rest of the board.

Four hours after I started placing components I had everything picked, placed and soldered. I carried the board in its PanaVise holder from my soldering bench to my test bench and thought about what I wanted to test. I was pretty confident that everything was correct, but I decided to re-run the entire series of tests from the beginning. Everything looked good until I measured the +3V3 to ground and found an almost dead short. I thought, "What the hell?" and sat back for a moment. I couldn't see any solder bridges. I'd been so careful about the orientation of everything.