As David is currently unable to post to the list he has asked me to post the following on his behalf: ------------- So it seems there's at least quite a bit of discussion generated about the board. For those curious, here are the major design points (LONG email ahead): - The main QBUS interface (before the buffers) will be an FPGA (Altera Cyclone III EP3C16 at this point, for cost, but the same footprint will fit a 3C25 or 3C40 as well). This FPGA should be large enough to fit even rather complex devices fairly handily (you can make a soft-core 32-bit processor in less than 1k logic elements, and a 3C16 has 16k). This is, of course, assuming you build it all in the FPGA fabric; you don't have to because... - The FPGA will be bolted to the bus (16-bit, of course) of a Freescale MCF5208. This is a ColdFire (68k architecture) which runs at 166 MHz (88 MHz external bus) and also contains a 10/100 Ethernet controller. The controller requires an external PHY, but this is actually an advantage; by connecting the processor's MII to both a real 10/100 PHY and the FPGA, we can provide both RJ45 for straight-up Ethernet connections and build an MII-to-AUI bridge in the FPGA (not a day's work, for sure, but certainly doable). This means you could use this as a replacement DELQA if you have a cable kit for the external AUI connector; connect to thick/thinnet, etc. Alternatively, you could stream hard disk/tape images from a remote file server. Of course, it'll have a handful of serial consoles. In theory, you could make a CPU board with SLUs and all 4 MB RAM out of the FPGA, but this would be an extensive design effort. As to whomever asked for a clock, that should work as well. Anything you can do with a QBUS card can be done on the FPGA, it's just a matter of how much work you want to put into it. :-) I currently have 32 MB RAM and 4 MB flash slated for the processor (the processor should read the FPGA image off the SD card). - My vision for the basic build of the FPGA would actually be to just provide an interrupt-based bus interface for the processor. If the processor defines apertures for the CSRs and uses an ISR to provide the data for the reads and the writes, a 166MHz processor ought to be able to respond quickly enough to make for a fairly speedy card. If that's not enough performance, one can always implement the device in the actual FPGA fabric (if one is good with FPGAs, which can take a while for people who aren't hardware designers). Additionally, we should be able to support multiple "virtual" cards in a single board; the only limitation is the number of apertures that will fit nicely in the FPGA and the overhead of the software running on processor. At least 4 should be easily achievable. A simple DMA controller in the FPGA would go a long way towards making the performance of mass storage acceptable (processor DMAs into FPGA, FPGA DMAs into QBUS, or vice versa). This means that even software-only people should be able to implement the devices in an emulator-like fashion (without excluding the possibility of actual FPGA implementations). - Since the Coldfire is 68k and has excellent GCC support, it can be programmed entirely with Free Software. The actual hardware to program it costs $80 standalone (more or less; depends on who's building it), but most of that is assembly and PCB costs. I could integrate the same hardware onto the board for an additonal $5 or so instead. The FPGA can be programmed entirely with Altera's free (not to be confused with Free) Web Edition version of Quartus, but to program it you need either a) a $75 JTAG cable to program it or b) something running on the ColdFire to program the FPGA image (which will be the default mode on boot). The JTAG cable gives you the advantage of running the FPGA-based logic analyzer. - And of course, yes, it will be a fully open architecture. I'm using KiCAD (FOSS) to do the schematic and layout. Anyone should be able to make the board if they want, but it'll be expensive for small runs. For those of you who think $200 each is in the stratosphere, here's my current (rough) BOM at two different run sizes: Part Description Qty Price at 10 Price at 25 ------------------------------------------------------------------ EP3C16E144C8N FPGA (EQFP-144) 1 26.70 26.70 DP83848 10/100 PHY 1 4.29 3.50 SST39VF3201 2M x 16 NOR flash 1 3.61 3.61 IS43R16160B-6 16M x 16 DDR RAM 1 6.00 5.40 EN5335QI DC-DC converter 3 5.51(16.53) 5.41(16.23) SN74AS641DW Octal bus xcvr 4 4.80(19.20) 4.04(16.16) J0026D21ENL RJ45 w/magnetics 1 4.825 4.825 Assembly aapcb.com, 50 parts 1 47.00 39.80 PCB 4pcb.com 1 72.44 36.26 --------------------------------------------------------------- Total 200.59 152.48 This doesn't include the scads of little resistors and capacitors and a few other cheap parts I'd need to place, which while very cheap may drive the cost of assembly up. The PCB pricing is for a 5.3" x 8.4" board, 1 edge gold fingers, 4 layers, controlled stackup (There are too many high-speed buses on this thing to risk a 2-layer board and no controlled impedance). Eliminating the gold fingers only brings the price down about $10. My $200 figure was a sort of back-of-the envelope calculation (I hadn't made out a detailed costed BOM yet). The cost is still subject to change, and a number of the parts (particularly the MCF5208) are long-lead (14 weeks and no stock anywhere). Most pricing was done at Mouser except for the components I couldn't find there (the PHY and the FPGA, and the RJ45 was cheaper at DK), which came from Digi-Key. This also doesn't include the AUI transceiver buffering, which I haven't yet worked out, and I still haven't 100% finalized the arrangement of the QBUS buffers (as it is, I'll be using transistors for a few of them since the signals don't all fit nicely in the mold of a '245-style transceiver like the 74AS641). Also, someone mentioned nonstandard thickness. As far as I was aware, the boards were 62 mils, but I haven't measured (and couldn't find a reference anywhere, and don't have a micrometer). Anyone know otherwise? In any case, I hope this answers a number of the questions out there. My plan is to implement the basic FPGA hardware mentioned as well as an implementation of the software stack for at least a few of the controller cards I have in my possession. The user end (serial console) of the processor should be able to load board personalities from the SD card as well, so setting up a repository of personalities (if others develop any) would be the way to go there.