Ideally, I'd like to synthesize the Kestrel-3 in an FPGA board with a price/performance tradeoff in the same ballpark as the venerable Digilent Nexys-2 board (no longer manufactured). However, contemporary FPGA development boards are either too simple, and thus would require me to spend more on attachments to make up for the lack of on-board features; or, they're way over-board, costing 2x to 3x that of my Nexys-2, while providing features which I'm in no position to exploit right now. Furthermore, almost everything out there uses an FPGA from a vendor whose tooling I simply have not been successful getting to run on my local workstation.

So, in a fit of not-so-quiet desperation, I've decided I should try and build my own kit that directly supports synthesizing a Kestrel-3. This is a *big* risk for me; I've never built anything with an FPGA on my own before, let alone several. Some may remember that my initial goal was to use my Nexys-2 as a proof-of-concept (since the Nexys-2 was already a working FPGA board I could depend upon) and then work on a real motherboard, meehhh, about a year or so afterwards. However, my repeat failures in getting any FPGA development IDEs working have resulted in a change of my priorities. Since I'm able to get iceStorm and related tools working quite trivially, the development kit will be based around one or more iCE40HX4K-TQ144 units (primarily because of the gull-wing package, which makes it possible for me to solder, albeit with some difficulty). The disadvantage of these FPGAs, though, is somewhat limited logic density combined with reduced quantity of I/O pins. I need multiple FPGAs to realize a Kestrel-3 using this configuration of hardware; at least two, in fact. One for the CPU, and one for "everything else" that makes up the Kestrel-3 motherboard logic. I may even need three.

Since I don't want to exceed the net cost of a Nexys-2, I decided that my success criteria will be a working Kestrel-3 in less than $250 of parts; labor is not included, since I'll be building it myself.

To facilitate incremental development of individual pieces, since I have no idea what I'm getting myself into, I decided on building the FPGA development board around a custom, passive backplane using DIN 41612 connectors. Each connector would provide somewhere in the vicinity of 64 (or more) uncommitted, shared I/O. I figure with a 50MHz oscillator driving the backplane bus, I'd need at least 32 pins reserved for Vdd or ground. I'm planning on placing the grounds and Vdd signals on pins B1 through B32 (right down the middle of the connector). That should leave plenty of pins to provide an externalized Wishbone bus with 28 ADR pins, 16 DAT pins, 2 SEL pins, plus pins for write-enable, cycle request, cycle grant, strobe, and acknowledge. Adding clock, reset, and FPGA CDONE signals, this comes to a total of 53 pins, so I still have some reasonable amount of room for future growth. This also occupies about one half of the available I/O pins of one of the FPGAs, so if I dedicate one FPGA to just the CPU, it poses no problem.

However, when I consider the other half of the Kestrel system, the MGIA/CGIA, GPIA, KIA, and other peripherals, I need to use up more I/Os for talking with peripherals than what I can afford to devote to the backplane bus. I wager 17 pins for 32K-color VGA, 4 pins for PS/2 ports (input only), 8 pins for a PMOD port to attach my SD card reader, 23 address pins to external RAM, 16 data pins, 2 pins for OE# and WE#, plus another 2 pins for upper and lower data strobes. Adding all that up, I get a total of 72 pins. Again, taken on its own, it looks like the FPGA can handle things well enough.

The problem is when trying to tackle all those I/O responsibilities at the same time as interfacing to the backplane bus. The backplane plus I/O load results in 72 + 53 (optimistic) = 125 pins, exceeding the iCE40HX4K-TQ144's 107 available I/O pins (and that's assuming no limitations on those available I/Os). So, either one of two things needs to happen:

1. I use a narrower bus in exchange for increasing the number of clock cycles required to accomplish a bus transaction. Because the backplane is passive, this interconnect must be strictly master/slave.

2. I use multiple FPGAs, each dedicated to one specific task. This means I have dedicated cards for CPU, memory (RAM and ROM), and I/O. But since the CPU and I/O cards will need access to memory, the interconnect will need to support multiple bus masters.

My (amortized!) cost of a backplane board is expected to come out to $50 or so, including the DIN sockets. That's double that of the RC2014 computer on Tindie, which makes me sad; but, then again, I'm considering prototype prices, and RC2014 looks like it's in regular production, so I'm sure that affects prices. Anyway, to fit a DIN plug, each adapter card will need to be at least three inches long. I can't imagine any reason why a board would need to be wider than two inches, so conservatively, let's say that both the CPU and the I/O plugin boards would come to six square inches. Using OSHPark and Digikey prices, a crude (amortized!) estimate for a plug-in card equipped with one DIN plug ($7 est.) and one FPGA ($7 est.) comes to around $24 for the CPU card, to maybe $44 for the I/O card.

So, if I have a two-card approach interfaced with a narrower interconnect, I'm looking at $50+$24+$44 = $118 total investment best-case. If I need a third card for hosting memory, which might afford me the simpler, yet wider, Wishbone bus, that would go up to $118 + $44 (worst case!) = $162. Even with prototype pricing, I have lots of headroom left over on my budget, so I think I'm doing this right no matter which route I take.

I've spent the past several days reviewing RapidIO, SD card protocols, and SPI flash memory protocols for inspiration with the narrower bus approach. However, I think the right choice is actually the externalized, multi-drop Wishbone interconnect. After all, premature optimization is the root of all evil, right? This includes cost optimization. As long as I am meeting my budget, I think I'm going to do OK.

Of course, the disadvantage of ordering from some place like OSHpark is that I have a minimum order of 3 boards for each of what I need. So, for these amortized prices to work out, I need to get things right the first time every time. I'd love to hear from folks who have worked with FPGAs before, specifically with respect to rework expenses.