External Interconnection issues

I've been trying to figure out how to interface the Canon P170-DH calculator I bought for its keyboard and printer and the discrete-component implementation of the Intel 4004 CPU. Long ago I decided to replace PC board in the P170 with one of my own design hosting an FPGA.

One of my design goals is that the rebuilt P170 should be able to operate either standalone with the i4004 CPU implemented in its FPGA, or using the discrete-component board stack as the CPU. As a standalone device the design is fairly straight-forward. To interface it to the external CPU it need some sort of external electrical interconnect.

It's resolving the nature of this interconnect that has been blocking my design of the new PC board for the P170.

My plan for mating the P170 with the discrete-component CPU was to emulate everything except the CPU in the calculator FPGA. The i4004 has 14 interface signals, so this would require running the 14 CPU signals plus ground across the interconnect. The most obvious solution was a 16-pin ribbon cable. However I worry about signal integrity.

The fastest of the CPU interface signals are the two clock phases, which the original i4004 ran at between 500 and 741 KHz. However, these are not 50% duty cycle sine waves. Instead, they have active pulse widths of 380 to 480 ns, with rise and fall times of 10 to 50 nanoseconds. A signal with a 10 ns rise time has to be treated as if it's a 100 MHz signal.

A ribbon cable connected so there is a ground on either side of a signal conductor gives a pretty consistent 100 ohm impedance and good behavior up into the hundreds of megahertz with proper termination. That would take care of the signal integrity concerns, while requiring a wider cable. Looking around my workbench I spied a 34-pin flat ribbon cable commonly used to connect floppy disk drives (remember those?). This would allow for a ground between each of the 14 CPU signals, plus a couple for power and some spares. The problem with this idea is that the 34-pin connector is 2 inches wide, which would be hard to mount in the P170 calculator shell. Bummer!

How about a ribbon cable that's wider than 16 conductors but narrower than 34? The non-clock signals transition at most once per cycle, or 250 to 370 KHz, and have 500 ns (max) rise/fall times. 18 conductors would allow for ground pins on either side of the two clock signals but these are scarce: Digikey quotes 7 week lead time, so no thanks! 20 conductors seems to be easily and cheaply available, and a 20-pin connector is about 1.3 inches wide. That's a possibility, but I still need to figure out whether there is room for such a connector in the P170's shell.


My next thought was some sort of high-speed serial interface. Rather than passing all 14 signals across the interface in parallel, I could pass a synchronous clock and a serial data stream in each direction. This would allow for a much smaller connector and reduce the amount of interface electronics I need to jam into the P170's shell. It would require an FPGA on both sides of the interface, but I was already considering adding an FPGA board to the stack to allow debugging of the various boards individually. (My current scheme of using my Digilent S3E Starter board allows only 40 signals to be monitored at any one time, which is insufficient to drive the instruction decode or ALU boards individually.)

What form would this interface take? RS-422 came to mind, as it uses differential signaling for noise immunity and the drivers usually include ESD protection. Chips like the LTC1686 and the SN65HVD76D will push 50 Mbps over each pair in a Cat 5 cable, and you can find Cat 5 cables anywhere. The RJ-45 connector is fairly small and inexpensive. The problem with this is trying to pass the proper signals across the link without disrupting the timing of the i4004 CPU and associated peripherals.


Then it occurred to the that if I'm going to include an FPGA in the CPU board stack, I could emulate the rest of the 141PF circuitry in it and treat the P170 strictly as a peripheral. If I did this, the only traffic across the interconnect toward the P170 would be data to be displayed or printed, and only switch state changes would need to come the other way. This is low-speed data, much like the old PS/2 keyboard interface. I could even use the 6-pin Mini-DIN connector used by the PS/2, which is about a half-inch square. I could probably make do with a Micro-USB connector if I really want to get small, though I wouldn't use USB signaling.