I think you all should try to keep it simple. That increases chances to produce something that is working in time and without multiple iterations for PCB production and assembly (money!). The later this thing is ready probably the higher is mining difficulty, this in the end also costs money.
I couldn't agree more. This is why I don't see the advantage of doing all the work to implement a bus protocol, when USB functionality costs nothing more than an FTDI chip ($3-4). If we're discussing overall strategy here, I think the priority should be on developing the FPGA daughter board. Right now, we're spending this time trying to design the perfect backplane, that will have sorts of cool features and allow for all different types of daughterboards. That's a very difficult task. It's very easy to get bogged down in this design and delay the overall development.
Yes, we should keep the early tasks as simple as possible. But we shouldn't sacrifice too much flexibility for that.
That's why we want to build hybrid cards, so that we can first focus on the cards and run them standalone, but at a later point are able to make a nice backplane for them.
The difference between standalone or hybrid cards is really just a DIMM connector and a couple PCB traces. Possibly a better USB bridge or MCU. Yes, it's a <$10 difference on a >$200 board. Do you really want to sacrifice the possibility of building a backplane for it later for these few bucks?
And regarding that backplane-only card idea, with a trivial one-slot FTDI backplane, I have two concerns:
- While this reduces cost for the board by a bit, it adds cost for a second board and a DIMM connector.
- It makes things less flexible. USB on the DIMM would allow future cards to change internal protocols as neccessary.
Nevertheless I would still route the SPI and JTAG interfaces to the DIMM as well. It just can't hurt.
If we're going for an MCU instead of an FTDI anyway, tristating won't be an issue. Just provide a dedicated tristating pin on the DIMM, which has a pulldown on the card, and gets pulled high on the backplane. If the MCU has the neccessary resources, adding an additional SPI link between the backplane and the MCU can't hurt as well. Oh, and having the MCU's JTAG pins on the DIMM can't hurt either. That way you can do MCU firmware upgrades from the backplane. And yes, we should go for an unbrickable MCU.