redesign platform resource

[jordens]

• better support for extension module connectors
• better support for adapters between extension modules (fmc-lpc to vhdci)
• better support for different io standards on extension module connectors
• make writing physical layers e.g. for spi easier (lvds vs single ended, merging multiple busses)
• better and maybe native support for differential pins and using them as differential or non-differential (see pmod)
• better support for different use cases of the same resource set (quad spi vs spi)
• easier splitting and combining of resources (pmod as individual gpios or mix of spi and gpios)
• support for resources without pin constraints (currently fails because the signal width is derived from the number of pins)
• it should work well with simulation (where platform parts are replaced by testbenches)
• work with https://github.com/m-labs/artiq/issues/823

[jordens]

also relevant: #77 , #76

[mithro]

This is something I'm interested in. I've already started playing with a classed based approach at https://github.com/mithro/HDMI2USB-litex-firmware-old/blob/pmod-extra/pmod.py

[mithro]

Oh, there is also some stuff for my "TOFE" standard in the HDMI2USB-litex-firmware repo.

See https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/platforms/tofe_axiom.py and https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/platforms/tofe_lowspeedio.py

This is then used in

• https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/gateware/tofe.py
• https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/targets/opsis/base.py#L289-L293
• https://github.com/timvideos/HDMI2USB-litex-firmware/blob/master/targets/opsis/axiom.py

This is all very clunky at the moment and I no doubt doing things in a really crappy way.

Things I've been thinking about;

• Many expansion boards / connectors have an "identification" type EEPROM.
• Many expansion boards do not have this identification.
• There are frequently boards which convert from one type of connector to another.
• Most gateware is going to be hard coded for a given expansion board connected.
• It would be a good idea to have a library of connector standards for things like FMC, Pmod, TOFE, RPi Hat, Arduino