Add support toward single-source-of-truth for signal directions

[mgeier]

Currently, three components within an UltraZohm system that uses this card have to “agree” on the signal directions of the card’s I/O pins, i.e., which ones are inputs and which ones are outputs (currently set in groups of eight by a DIP). These components are

• the SoM (more specifically, the toplevel VHDL entity that defines the signal directions in the PL),
• the CPLD (with its card- and here-also-switch-position-specific bitstreams), and
• the card itself (more specifically, the configuration of the four DIPs).

Moving toward the automatic identification of adapter cards, it would make sense to make those four “direction” bits accessible as well - Either for “just” warning the user that PL, CPLD and card configuration does not match, or even for partially automated configuration of some/all components. There are two general approaches to do so, either

1. by extending the card in such a way that its current (DIP-defined) configuration is exposed to the carrier, or
2. by extending the card in such a way that the signal directions can be configured by the carrier (= software).

There are (at least) three ways to do so [implementing either approach 1 or 2 as described above]:

• Make the signals directions an assembly-time parameter (i.e., replace the DIP switch with DNP/0R resistors) - not a good path, I’d say… - and store the resistor-defined signal directions in the card’s EEPROM [approach 1], or
• keep the signal directions a “run-time” parameter (i.e., keep the DIP switches) and adding an I²C GPIO to the card that enables the carrier to read the (DIP-)configured signal directions into the software [also approach 1], or
• make the signal directions a “software run-time” parameter by replacing the DIP switches with an I²C GPIO in output mode (in contrast to the previous bullet where the I²C GPIO is in input mode) to enable the software to set the signal directions during the initialization stage of uz-sw [approach 2].

[FTR: Yes, this is another one of those while-on-a-walk thoughts - But maybe it finds some supporters :)]

[mgeier]

Personally, I’d prefer the middle option where

• the DIP switches remain on the card as before and
• their configuration becomes readable by the SoM.

This way, the

• user experience is as before w.r.t. configuration (i.e., the card’s switches define the directions no matter what), and

• future versions of the uz-sw can not only rely

  • on I²C communication to the CPLDs (to read or even set the directions) and
  • on I²C communication to the adapter cards EEPROM (→card type/revision),
    but also
  • retrieve the setup-specific I/O configuration (i.e., the positions of the DIP switches) on this particular card
    and act accordingly (e.g., print a warning in case of a mismatch).

‌