More musing on a 6th board

As I mentioned a few days ago, I'm considering a sixth board. This one would carry a modern FPGA and components and serve two purposes:

1. An easily reconfigurable test board to allow testing of any single board or set of boards in the i4004 CPU board stack.
2. A system emulator for the i4004 CPU board stack, emulating the rest of the components of a Busicom PF-141 calculator.

Didn't I already achieve purpose #1 with my Spartan-3E reference board and the test jig? Yes, but with only 40 I/Os available I'll have to physically re-wire the test jig to test the Scratchpad or the I/O and Timing board. The Instruction Decoder and ALU boards would have to be tested as a pair because of this. The iCE40-HX4K chip in the 144-lead TQFP package has over 100 I/Os, so I could connect all 72 inter-board signals to the FPGA at the same time. I could then wire another 17 signals to a connector that would mate to my logic analyzer, and still have more than 10 I/Os for things like external clock sources, an async serial interface, etc. I already know this configuration will fit in the 1K part, so the 4K part is needed only for the extra I/Os.

How about goal #2?

With the full CPU board stack the entire FPGA is available for system emulation. As I understand it, the Busicom calculator had five 4001 ROMs, two 4002 RAMs, and three 4003 shift registers. A 4001 ROM is a 256x8 bit array, and two of these will fit in an iCE40-HX BlockRAM. A 4002 RAM is an oddly-shaped 4-bit array totaling 320 bits; squaring the array to 128x4 would fit eight into a single BlockRAM. Thus a full calculator emulation would require only 4 of the 20 BlockRAMs in the 4K part.

This sounds like an easy fit, but there's a catch. I'd like to emulate the Busicom printer and keyboard using a standard serial port interface and ASCII characters. That means implementing a UART in the FPGA, a state machine to convert the Busicom printer interface to ASCII character output, and another state machine to convert received ASCII characters to keyboard switch closures. Nothing terribly complex IF there are enough FPGA resources to do the job. And, as I mentioned above, you can't assume you can use 100% of the FPGA and get the tools to successfully place and route.

So before I build a board with an iCE40-HX4K on it I'd better be sure I can achieve both goals.

If it won't fit in an HX4K part the 8K part really isn't an option: I'm simply not set up to route or mount a BGA. There is mention of an HX16K in a 144-TQFP in Lattice literature from 2012, but it doesn't appear on their website. I suspect they didn't see sufficient demand to make a part of that size.

Another option is to revert to my Xilinx roots. This has the advantage of being a development environment I've used a fair bit with a simulator that runs under Linux. The Spartan-6 LX9 FPGA is available in a 144-TQFP with 102 I/Os and 9152 logic cells (by Xilinx's reckoning). Not only is that 2.6 times the number of logic cells in the iCE40-HX4K, but the Spartan-6 has 6-input LUTs instead of the 4-input LUTs of the iCE40. Look-Up Tables (LUT) with more inputs often means that fewer logic cells are required to implement the same logical operations. If I can't squeeze these functions into an LX9 I should probably stop playing with FPGAs.