Quote from: TheSeven on July 14, 2011, 11:15:23 AM

[...]
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.

I am still not convinced that putting extra protocols on the DIMM bus cannot hurt: in the best case, we are locking future DIMMs and backplanes into a more complex interface than it needs to be. How about this: we define several interfaces, e.g. the ones we were talking about all the time (JTAG, I²C, SPI, USB) and we make all of them optional. The DIMM can inform the backplane via a couple of low impedance connections which protocols it supports and which are not connected. That makes the backplane a (very little) more complicated because you need to read out the signals from these key-pins. But it keeps the DIMM design completely open: a later revision could really employ "head-less" DIMMs that don't work stand alone. Or use an FT2232H design that is incapable of tri-stating the JTAG and SPI pins for use by the backplane.

Of course, this way all DIMMs will work on a backplane that supports all protocols. But if the backplane designer starts cutting corners, then some DIMMs won't work in that backplane. There are three solutions:

Make all protocols mandatory (current situation). Safest option, but precludes making the boards simpler at a later stage.
Define one of the protocols as compulsory (my preference: USB) and leave the others optional. All DIMMs and all backplanes must support the compulsory protocol and can fall back to that if no other protocol is available.
If you have one compulsory protocol that must be supported, why do you need the others? So only support that one protocol. Very lean bus design, but forces all future DIMMs to have adapter logic to translate between the bus protocol and what is used on the DIMM.

It's basically a philosophy question: many choices but (mostly unneeded) overhead to provide them on one hand and lean design but less flexibility on the other hand ("less", not "no"! You just cannot remove the adapter logic). A bit of an IBM/PC clone vs. Mac question

Quote from: TheSeven on July 14, 2011, 11:15:23 AM

[...] And yes, we should go for an unbrickable MCU.

Haven't found one, yet. I was suggested the Analog Devices ADUC series as unbrickable, but that one does not support USB.

Quote from: fizzisist on July 14, 2011, 05:17:49 PM

[...] I have more experience with Atmel AVRs and I would prefer the AT90USB82. [...]

My understanding was that it is possible to brick the Atmels. Can you confirm (or better: rebut) this?