Catherine

OK. No objection to DAC out on accessory connector.

We can use [PCA9544A](https://www.ti.com/lit/ds/symlink/pca9544a.pdf) as the I2C mux, connecting all of our level translating GPIO expanders behind it. It has four interrupt inputs and one interrupt output. We can connect...

Actually, not PCA9544A, since it does not have a reset. [PCA9545A](https://www.ti.com/lit/ds/symlink/pca9545a.pdf) seems fine tho.

Note that while PCA9545A is a voltage translating I2C switch, I think we should run all of its subordinate buses at 3V3 as well. First, the ~INTn inputs are referenced...

> The list of available I2C addresses becomes part of the addon interface guarantee, right? We already use up a lot of address space for common stuff (like EEPROMs, DAC,...

I'm really unhappy about the increase in complexity. I think neither the hardware global shutoff feature nor the reduction in reserved addresses is really justifies adding all this.

After discussion on IRC and careful consideration I changed my mind. Let's prototype this. Instead of rewriring ICE-LED to iCE40 we should rewire it to CDONE, I am not sure...

Okay, this isn't really an RFC because this doesn't explain the exact mechanism through which this will happen. There isn't anything to comment on.

> I propose, that we just allow to pass and `Elaboratable` object instead of a `Pins` object to `Resource`. I like this direction. I think wrapping `Instance`s is reasonable: you...

Here is my counter-RFC. # Mechanism We currently have a bunch of methods like: ```python def get_input_output(self, pin, port, attrs, invert): ``` Let's add two more, which connect IO of...