CPLD 1.8V to 3.3V bidirectional SDA

Having taken a closer look at the XAPP785 I have a hardware issue on my board. Both the VCCIO1, pins 58 and 38, are driven by 3.3V as well as VCCIO2, pins 98, and 88.

As a general rule, while you can (have to) set IO voltages in the FPGA software you still have to wire the bank VCC pins to the right voltage rail. I'm not aware of any FPGAs which can dynamically switch bank voltages.

Theo

I need to make the SDA bidirectional and level shift SCL, int, and fsync. Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD hardw are that I would like to use to make the bidirectional level shifted SDA as well as level shift the other three.

s to be performing the bidirectional communication, but all logic is a ~3.3 V level.

This is not a problem really. The data line should be open collector which is what I2C is intended to use. I believe SDA is the 3.3 volt I2C data li ne and I2C(1) is the 1.8 volt I2C line. Your code should be written as bel ow.

enable

Level shifting bidirectional signals is not a trivial thing to do.

Agree with Rick's post where the output should either be pulled low of Hi-Z.

What is wrong with the classic way of doing it as per:

The SCL may also need to be truly bidirectional if there is any device clock-stretching.

e. I need to make the SDA bidirectional and level shift SCL, int, and fsync . Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD har dware that I would like to use to make the bidirectional level shifted SDA as well as level shift the other three.

ems to be performing the bidirectional communication, but all logic is a ~3 .3V level.

e 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows:

-Z.

Your point is well taken. There isn't much chance of clock stretching bein g used though as some number of I2C masters don't implement it. I would be more concerned with proper management of the direction control signal.

In the app note you point to they don't seem to compensate for the loss in voltage across the source to gate. So while there are pullups on both side , the active drive from either side won't drive the full range and in fact may be very cramped by the 1.8 volt power supply. If this bus isn't using the fast bit rate I guess that won't be a problem.

Rick C.

'active drive'? I2C (at least at base speeds) is a purely pull up protocal. The only time logic is supposed to actually drive signal high is if you transition into 'High Speed' (above the 400KHz fast mode) mode. The App note specifically says it is for full / fast ((not High Speed), so the bus is designed to be just restive pulled up.

ice. I need to make the SDA bidirectional and level shift SCL, int, and fsy nc. Voltage level on the sensor board is 1.8V the PI is 3.3V. I have CPLD h ardware that I would like to use to make the bidirectional level shifted SD A as well as level shift the other three.

seems to be performing the bidirectional communication, but all logic is a ~3.3V level.

the 3.3V I2C and ancillary pins on 15, 16 and 17. The UCF is as follows:

Hi-Z.

being used though as some number of I2C masters don't implement it. I woul d be more concerned with proper management of the direction control signal.

in voltage across the source to gate. So while there are pullups on both side, the active drive from either side won't drive the full range and in f act may be very cramped by the 1.8 volt power supply. If this bus isn't us ing the fast bit rate I guess that won't be a problem.

That's why I said if they weren't running fast it won't matter. I didn't m emorize the names they use for the various modes, so "fast" was descriptive rather than nominal.

The real issue is using a device that will actually be turned on with only a 1.8 volt gate drive which will potentially be even less since the driving signal may not pull fully to ground.

I don't recall the details of the I2C interface timing, but it might be mor e realistic to implement a repeater that receives and retransmits the I2C s ignals rather than just level shifts. The devil is in the details so it is hard to say without at least simulating this circuit.

Rick Collins

Is it not the slave that holds the clock low, not the master?

Not all devices do this.

The big point is that the High Speed I2C bus is very much a different beast than the Full / Fast speed bus, with very different requirements. The notes on implementing High Speed mode often talk about the need to isolate High Speed devices from 'Normal' speed devices because they might not tolerate the bus suddenly running faster than they were designed for, even if they aren't being talked to.

As I mentioned, the App Note specifically limited its applicability to the modes with the passive pull ups.

Also, High Speed I2C devices are fairly rare.

Geting Fets that turn on at 1-1.2 volts isn't that hard (and the current needed isn't that high which makes the lower threshold easier to implement).

If by an I2C Repeater, you mean something that receives an I2C message on one side and then send it to the other, this is basically impossible if you want it to be transparent due to acks and reads. You basically need to be re transmitting bit by bit.

There are devices that are a bit more complicated that can do this task, and even handle High Speed, which operate by assuming that the signal driving to them drive low with better than required margins, and then the repeater drives a weaker low so it can detect which sides are being driven (something like if Ain < 0.3V then pull Bout to 0.5V) with the disadvantage that you can't repeat a repeated signal.

Yes, the slave holds the clock low, but the master has to be paying attention. If not the network screws up.

Rick C.