Catherine

To be clear, zealous handling of I2C errors is something that's *possible* to do, but given that errors on the bus potentially affect DUT reliability (e.g.: your DUT can't handle...

It's also kind of ridiculous that most I2C muxes are controlled via I2C. I think the only reliable way to use such a mux is to just reset it every...

> This is only going to work if the mux has a reset line we can control, so we can unwedge it if a downstream peripheral is stupid. Right, but...

I am weakly against having such a feature on revD and not having it on revC for the following reason. revC and revD are supposed to be more or less...

Let's keep this open until we figure out for sure whether there's going to be a mux before revE.

I'm thinking we could use the "aux" connector on revC to make the FPGA "proxy" I²C if it comes to that. But I still think that a solution that only...

> The problems you talk about appear when hotplugging something into the internal I2C bus, correct? Is hotplugging necessary? Wouldn't it be possible to adapt the spec of Glasgow to...

I see these possible routes to addressing this: 1. Do nothing. Cons: no defined way to autodetect addon boards or communicate with them. 2. Explicitly define AUX as carrying I²C...

> 3\. I think PCA9306 fits between the level shifters Of course, PCA9306 is another one of those awful I²C devices that come with severe restrictions on operating them that...

@electroniceel So, the I²C switch exists (a regular analog switch can be used in this application if level translation is not required), but we couldn't find a connector configuration that...