search

sinara-hw / Kasli

Kasli is a powerful FPGA carrier, capable of controlling 12 Eurocard extension modules.
Other
16 stars 1 forks source link

I2C pullups and I2C repeaters #46

Closed jordens closed 5 years ago

jordens commented 5 years ago

Changes are schematics/BOM-only.

jordens commented 5 years ago

Also check:

9.3.3 VOL B-Side Offset Voltage The B-side drivers operate from 2.7 V to 5.5 V. The output low level for this internal buffer is approximately 0.5 V, but the input voltage must be 70 mV or more below the output low level when the output internally is driven low. The higher-voltage low signal is called a buffered low. When the B-side I/O is driven low internally, the low is not recognized as a low by the input. This feature prevents a lockup condition from occurring when the input low condition is released. This type of design prevents 2 B-side ports from being connected to each other.

I don't really understand the "internally" notion. But the "This type of design prevents 2 B-side ports from being connected to each other." is what we are doing with IC13 and IC22. Might be wrong.

(sidenote: I have seen I2C issues on Kasli but couldn't figure out why and where).

jordens commented 5 years ago

I think 9.3.3. means that we can't talk I2C between the FPGA I2C and the FT4232 the way we have set it up. That would be worth noting but acceptable IMO.

marmeladapk commented 5 years ago

@jordens I implemented changes that you suggested.

Regarding I2C issues, I had one on EEM with Si570, where it didn't accept low level of ~0,5V-0,55V. Changing pull-up resistor value didn't help. I added another TCA9517 with B-side connected to Kasli and A-side facing the board (A-side generates true low states) and it worked despite the warning. I can measure voltage levels on this board if you want.

hartytp commented 5 years ago

@marmeladapk what's the current time line for getting the new version of Kasli ready for manufacture?

jordens commented 5 years ago

@marmeladapk We have an EEM with a Si570? I am also worried by the 0.5 V Vol of the B side and I agree that weakening the pull ups may not be sufficient to make it robust. But I'd be equally worried about running the B side on 2.5 V. Any other I2C extender? Or should we just hope for the best?

jordens commented 5 years ago

Maybe look at PCA9306. Doesn't mention that high VOL and seems to be more symmetric. It also has a lot of advice about pull up strength on both sides. Same package but unfortunately not pin compatible.

jordens commented 5 years ago

Or maybe we could look at active pull-ups like the LTC1694 or LTC4311

marmeladapk commented 5 years ago

Active pullups don't seem to solve this problem as ~0,5V bias is inherently in TCA buffer and we can only push it up or down 100mV or so. So we can only hide this problem until another problematic part shows up.

Hmm, I'm worried about this: "Vref(1)-Vbias(ref)(2)>=1 V for best results in level shifting application" in PCA from maxim. They don't seem to specify what's worse when voltage difference is less than 1V.

Similar part from TI lists 2V5 to 3V3 translation (part has V1-V2>=0,6V) and I think I'll use it. We don't need buffering and isolation of such a short path to FPGA is pointless (it's only around 1 pF/cm). One minus is that we'll have enable signal connected to 3V3 rail, which wakes up earlier than 2V5, but all pins are supposedly open-drain, so it should not be a problem.

jordens commented 5 years ago

Yes. That's the PCA9306 I mentioned. They say that the propagation delays become more symmetric and slower the lower the voltage difference. Are you sure we don't need to buffer the FPGA? The I2C switches are all is passive and in the worst case there is about 1m of ribbon cabling, a couple 10k (hopefully no 2k anymore) pullups, a couple more I2C switches (e.g. Banker, Humpback, VHDCI Adapter) plus slave devices, and maybe even some VHDCI cable on it.

marmeladapk commented 5 years ago

Yes. That's the PCA9306 I mentioned.

You linked PCA9306 from NXP (not from maxim as I initially wrote) which has a different threshold.

Are you sure we don't need to buffer the FPGA?

This way can only shave off around 10 pF of PCA input capacitance + 4-5 pF as there's only trace capacitance on the path to the FPGA. I don't it will make a huge difference and if we're worried about it then we should place repeaters on slave devices where it will make a real difference.

jordens commented 5 years ago

Right. The TI version differs quite a bit, also in switch resistance.

I don't get your logic of the repeater. Both master and slave need to be able to drive down the lines and see the pull up raise them. Ignoring transmission line effect (as one apparently does with I2C), that will look the same from both ends independent of where the pull up is, and will require the same "beefiness" on both sides.

marmeladapk commented 5 years ago

Repeaters = active buffers in my train of thought (maybe I didn't state that clearly). So effectively the capacitance (and pull ups) of I2C bus after the buffer won't be visible for devices driving the buffer. They only need to drive the bus up until the buffer part, and the buffer will drive the part of the bus after it (both ways). So if we put buffers near EEM connectors on slaves then we "cut" the bus in ~half (as well as we can).

If we put a buffer 5cm from the FPGA then we only separate 5pF of trace capacitance that the FPGA has to drive. That buffer has to drive the rest and I think that it doesn't make any difference.

jordens commented 5 years ago

Ok. Then we agree that EEMs like Banker, Humpback, VHDCI Adapter should get some buffer because they are likely to sit mid span. And if we say that both the FPGA and e.g. some 24c EEPROM on an EEM are ok driving the bus segment between them un-buffered, then we are ok with those passive level translating switches.

marmeladapk commented 5 years ago

I'm not sure if we need them. Artix-7 has higher drive strength than PCA9517 is specified for (16mA vs 6 mA) so for the FPGA it shouldn't make a difference. Meanwhile slave devices on EEMs shouldn't feel a big difference between TCA and PCA sitting near the FPGA (it's additional 5pF of trace + 8 pF of pin capacitance). Plus I changed pull up resistors on slave side following your request. So if slave devices on EEMs like Banker worked before then they should also work now.

If you're still worried about it and would rather avoid changes in EEMs (altough I think it's a good idea to place buffers on EEMs that may rely on I2C) then I can place pinout for TCA9517 on the bottom and DNP it to have a backup plan. I2C proved to work in mysterious ways many times already.

jordens commented 5 years ago

I am ok with just the TI PCA9306 for translation and the 2k2 on the master segment and 10k on the EEM segments. That should improve the situation a lot.

marmeladapk commented 5 years ago

Currently we have (in my unpublished schematics): 10k on 2V5 bus to FPGA <- PCA -> 2k2 on 3V3 bus <- TCA9548 fanout -> 10k on downstream bus to EEMs.

jordens commented 5 years ago

Excellent.