I just joined the list, but looked over the recent i2c discussion. I
have a related question which I don't believe was answered.

The directions in the I2C documentation say to use a tri-state pin for
SCL and SDA, but I thought that an open-drain was necessary. My
thinking is this:

I2C is not collision-free by design. The intention is that you can
detect when there is a collision if you intend to send a 1 and the bus
looks like a zero because someone else is driving it low.

In the case where there are 2 devices driving the bus, if they both
drive low, there is no problem. If they both "drive" high (really
disconnected since they are open-drain, letting the pull-up do the weak
driving) then there is no problem. If one drives low and one "drives"
high, the one driving high detects a collision, but nobody's outputs are
shorted since you don't actually drive the bus high, you just let the
bus be pulled up.

However, if you use a plain tri-state output, then when you drive high,
you are really driving the bus high, and someone else driving the bus
low will result in a short.

Am I missing something here? The only other option I can see is to
de-assert the OE signal when you want to send a 1, thus turning off the
drive and simulating an open drain, but I don't know if that works in
practice. Most FPGAs don't have real open-drain outputs, do they?

Thanks,
Matt

On Wednesday 11 April 2007 17:07, Matt Ettus wrote:


[...]

Yes, this the way to do it, it's not that hard. You drive low for a low, and don't drive at all for a high. Obviously the entire bus needs to be pulled up. And if you want to actually be compliant, as opposed to just doing some ad-hoc messing around, make sure you actually meet the I²C electrical as well as timing specifications for the bus speed you are targeting. -- Wesley J. Landaker wjl at icecavern.net> wjl at icecavern.net> OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20070412/119b1bf6/attachment.pgp

The way you drive I2C to meet the spec is to use a tri-state pin, but the data goes to the ENABLE of the gate (enable if want low), and the data is set to gnd. This effectively makes the pin an open collector signal. This works for almost all devices. The only problem would be a device that has a limited number of Enable signals. Richard -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Matt Ettus Sent: Wednesday, April 11, 2007 7:08 PM To: cores at opencores.org Subject: [oc] recent i2c questions I just joined the list, but looked over the recent i2c discussion. I have a related question which I don't believe was answered. The directions in the I2C documentation say to use a tri-state pin for SCL and SDA, but I thought that an open-drain was necessary. My thinking is this: I2C is not collision-free by design. The intention is that you can detect when there is a collision if you intend to send a 1 and the bus looks like a zero because someone else is driving it low. In the case where there are 2 devices driving the bus, if they both drive low, there is no problem. If they both "drive" high (really disconnected since they are open-drain, letting the pull-up do the weak driving) then there is no problem. If one drives low and one "drives" high, the one driving high detects a collision, but nobody's outputs are shorted since you don't actually drive the bus high, you just let the bus be pulled up. However, if you use a plain tri-state output, then when you drive high, you are really driving the bus high, and someone else driving the bus low will result in a short. Am I missing something here? The only other option I can see is to de-assert the OE signal when you want to send a 1, thus turning off the drive and simulating an open drain, but I don't know if that works in practice. Most FPGAs don't have real open-drain outputs, do they? Thanks, Matt

After further perusing the code it appears that this is done by the core
itself. It wasn't clear from the docs.


Thanks,
Matt

Matt Ettus wrote:


Well, the HDL for an open drain and for a tristate which is never "1" is
identical in both Verilog and VHDL. In Verilog, you would write either as:

assign output = output_active ? 1'b0 : 1'bz;

Even if you explicitly instantiate an open drain buffer, any FPGA
synthesizer will simply instantiate it as a tristate buffer with its
input tied to zero.

So, there is nothing the core has to do.

-hpa

After further perusing the code it appears that this is done by the core
itself. It wasn't clear from the docs.

[rih] What do you mean it wasn't clear from the docs??
This is the 3rd person claiming this, so apparently it isn't clear.
But the doc explicitly explains how to create the open-drain from the
tri-state buffers. It actually says i2c uses open-drain and that the
open-drain is implemented with tri-states.
There's a graphical representation and VHDL and Verilog codes on how to
implement the pads. What else do you need???

(the other) Richard

Am I missing something here? The only other option I can see is to
de-assert the OE signal when you want to send a 1, thus turning off the
drive and simulating an open drain, but I don't know if that works in
practice.

[rih] This is exactly what the core does. See the documentation.

Richard

In the diagram, it shows scl_pad_o going to the tri-state buffer
input. If it had shown a 0 going to the buffer, or had stated that
scl_pad_o is always 0, then it would have been clear. Without that,
it just basically says that you need to create an open drain, but
shows using a tri-state buffer.

[rih] OK, I'll add the line that scl_pad_o and sda_pad_o are always '0'.
Initially I had drawn a '0' (and the core did not output scl_pad_o or
sda_pad_o), but then people started complaining they did not understand the
'0'. So I though I'd make it simple, just hookup the signals and it works.
But apparently that confuses other people(sigh) :)

Richard

In the diagram, it shows scl_pad_o going to the tri-state buffer
input. If it had shown a 0 going to the buffer, or had stated that
scl_pad_o is always 0, then it would have been clear. Without that,
it just basically says that you need to create an open drain, but
shows using a tri-state buffer.

Thanks,
Matt