Extension module connector baseline functionality

[jordens]

@hartytp @jbqubit
Let's try to do a preliminary freeze on the extension module connector functionality so that (1) Sayma/Metlino can start gauging the resource usage, (2) Kasli can tie down resource usage and features, and (3) that Novogorny and Zotino have a design envelope.

This is a baseline idea. It can change later if we have more data.

It looks like we can plan to support two different (bitstream compile time) types of IO:
(a) SERDES-TTL
(b) TTL or SPI selectable at runtime.

Then, we could plan to support the following extension types (bitstream compile time):

(1) 8x SERDES-TTL
(2) 4x TTL/SPI + 4x SERDES-TTL
(3) 4x TTL/SPI + 4x TTL/SPI

Metlino would probably go with 8x (1) as per Joe's request. Sayma may start with 4x (2) on the FMC-VHDCI to support e.g. Novogorny, Zotino, Mirni, and Urukut.
Kasli may do 4x (1) + 4x (2).

Does that sound like a good idea?

[hartytp]

@jordens Thanks for writing that up.

That sounds like a good starting point to me. As you can say, we can tweak this once we've got some experience using the hardware and our use cases are better defined.

[jordens]

entered into the wiki