cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kriss.osmanis
Visitor
Visitor
9,295 Views
Registered: ‎11-29-2012

IOBUF delay issues

Jump to solution

Hello everyone, I am working on I2C master core on ML605 development board to access U6 (8Kb nv eeprom), located in main i2c chain.

I am having some issues and misunderstanding with outputs from Virtex-6.

 

Im driving the I2C lines (scl, sda) using iobuf modules, I instantiate them in my top module like this:

   IOBUF_sda : IOBUF
   generic map (
      DRIVE => 12,
      IOSTANDARD => "LVCMOS25",
      SLEW => "SLOW")
   port map (
      O => i2c_sda_i,
      IO => iic_sda_main,
      I => i2c_sda_o,
      T => i2c_sda_oe
   );

For i2c protocol (open drain with external pullups), I am connecting the I of iobuf (i2c_sda_o signal) to '0' and control only T input of iobuf (signal i2c_sda_oe). Im thinking this as: pulling either the line down, or releasing it to pullup.

Im monitoring the sda - output O of iobuf (i2c_sda_i signal) - in chipscope - I connect it directly to the iobuf module, (without any registering). IO of iobuf is the pin (AE9, AK9)

 

The problem is with line observation (O of iobuf) in chipscope. I see somehow larger than expected (actually, I dont know what to expect here) delay from pushing T to '1' and seeing this in I output of iobuf.

 

My i2c state machine is driven with 4x the SCL speed (1.6mhz for 400khz operation, 400khz for 100khz operation)

Observation clock in chipscope is 8Mhz

All clocks are derived from 200MHZ system clock on ML605.

 

In 100khz mode, i see i2c_scl_i and i2c_sda_i signals rise some time after the i2c_scl_oe/i2c_sda_oe goes to '1',

In 400khz mode the i2c_sda_i signal rises a bit after the oe, but i2c_scl_i signal does not rise at all!

 

Please see the attached images (the clk_400 signal actually represents 4x scl clock (400khz and 1600khz))

100khz:

i2c 100khz

and 400khz:

iobuf_400.PNG

 

 

Does iobuf really cause such delay or have I missed something? Should I register I, O, T signals of iobuf?

 

Tags (4)
0 Kudos
1 Solution

Accepted Solutions
gszakacs
Instructor
Instructor
11,846 Views
Registered: ‎08-14-2007

The I2C bus specification has a long discussion of appropriate values for pullup resistors.  My

guess is that 4.7K is too high for 400 Kbps I2C since the rise time must be no more than 300 ns

per the spec.  Figure 17.5 shows a plot of maximum Rp at 5V for capacitive loads up to 400 pF.

Lower Vcc values don't affect the maximum pullup resistance as much as you might think

because the threshold voltage typically also scales down with Vcc, so you're still dealing

with about the same RC time constant.  In any case you'de need to look at capacitive loading

to find a reasonable maximum for Rp, or else you could just use the minimum allowable

value which only depends on Vcc max vs the max allowable pullup current.

 

-- Gabor

-- Gabor

View solution in original post

0 Kudos
7 Replies
avrumw
Expert
Expert
9,265 Views
Registered: ‎01-23-2009

The issue has nothing (really) to do with the IOBUF. As you stated, the I2C signals are open drain, which means that you actively pull them low, but passively allow a pull-up to pull them high. In the case of the ML605, there appear to be 4.7K resistors pulling them high.

 

As you can see from your 100kHz waveform, which shows the OE of these signals and the buffered input from the board, there is no (or little) delay on the falling edge - this is because the FPGA driver is actively pulling it low. However there is significant delay on the rising edge, since we are relying on the resistor to pull it high.

 

The resistive pull up is slow. It relies on the current through the resistor to charge up the node on the board. The I2C bus goes to lots of destinations on the board, and will therefore have a significant capacitance - lets say around 30pF. Therefore, the time constant for this RC circuit is 4.7e3 x 3e-11, or around 140ns - we need around 2 time constants to make a real transition, so lets say 300ns. However, looking at your diagram, the delay seems much larger - if the ChipScope clock really is 8MHz, then the delay looks to be around 10 samples, so 1.25us - roughly 4x what I would have expected.

 

At 400kHz, the period is 2.5us, and your SCL_OE looks to be around 50/50 duty cycle, the high time of the OE is 1.25us - so the FPGA releases the SCL signal, the resistor starts charging it up, but 1.25us later, your FPGA pulls it back downs BEFORE the resistor has time to get the voltage high enough to be seen as a 1.

 

So the waves are consistent - the only question is "Why is the rise time SOOOOO slow".

 

Possibilities

  - the capacitance is more like 120pF. Thats a REALLY high capacitance, even though this signal goes to several connectors (including the DIMM)

  - the resistors aren't really there or aren't 4.7K. The schematic I have shows them as 4.7K and there is no reason to believe it is wrong

  - our measurement is incorrect

 

For the last one, I am trying to measure something small on a big picture, so I could be out by a reasonable amount, but not 4-1. Of course, I am relying on the information that you provided - that the ChipScope clock is 8MHz. The problem with using logic analyzers for measuring time (and frequency) is that it all relies on knowing what the logic analyzer sample frequency is. If all your clocks were (say) out by a factor of 4, then we wouldn't be able to tell by the logic analyzer alone. In this case you would be trying to drive the I2C at 1.6Mbps, which is WAY faster than it can go...

 

So, the solutions are

  - carefully inspect your clock generation to make sure it is what you think it is or

  - (even better) - use an oscilloscope on the I2C signals on the board to look at what they really look like. You will easily be able to tell if the signals are toggling at the rates you think they are, and, even better, you will be able to directly observe and measure the RC charging of these lines

 

Avrum

0 Kudos
gszakacs
Instructor
Instructor
9,252 Views
Registered: ‎08-14-2007

When I write an I2C state machine I always use feedback from the pins (both SCL and SDA)

so that when I switch the output (either high or low) I don't move to the next state until I

actually see the pin switch in the feedback.  This takes into account any excess capacitive loading

and also allows you to have slaves that "stretch" the clock line by holding SCL low if they're not

ready to provide data.

 

An oscilloscope would be the best way to see if this long rising edge delay is capacitive or

if some other I2C device is actively holding signals low.

 

-- Gabor

-- Gabor
0 Kudos
kriss.osmanis
Visitor
Visitor
9,240 Views
Registered: ‎11-29-2012

Thank you for your answers, those were some of my thoughts as well. I just wanted to be sure I am not missing anything about the IOBUF.

 

I will look into these solutions and comment later, what I see - clocks and signals.

 

Best regards,

Kriss

0 Kudos
bassman59
Historian
Historian
9,231 Views
Registered: ‎02-25-2008

@avrumw wrote:

The issue has nothing (really) to do with the IOBUF. As you stated, the I2C signals are open drain, which means that you actively pull them low, but passively allow a pull-up to pull them high. In the case of the ML605, there appear to be 4.7K resistors pulling them high.


one pedantic point here. V6 doesn't support 5V i/o, and the I2C pullup resistor is specified as 4.7k for 5V systems. If you are using a lower voltage you need to scale down the value of the pullup. 4.7k is too weak and at faster bus speeds the signal may never transistion across logic thresholds. I typically use a 2k resistor for 3.3V I2C, and I would guess that a 1k resistor might be a good choice for a 2.5V bus.

----------------------------Yes, I do this for a living.
avrumw
Expert
Expert
9,226 Views
Registered: ‎01-23-2009

To be even more pedantic... :-)

 

V6 doesn't support 5V i/o, and the I2C pullup resistor is specified as 4.7k for 5V systems

 

On the ML605, these signals are actually 2.5V I/O from the FPGA. They then go through a level translator to 3.3V, and have a 4.7K pull-up to 3.3V. I am not saying that this is "right" - just what "is"!

 

Avrum

 

 

0 Kudos
gszakacs
Instructor
Instructor
11,847 Views
Registered: ‎08-14-2007

The I2C bus specification has a long discussion of appropriate values for pullup resistors.  My

guess is that 4.7K is too high for 400 Kbps I2C since the rise time must be no more than 300 ns

per the spec.  Figure 17.5 shows a plot of maximum Rp at 5V for capacitive loads up to 400 pF.

Lower Vcc values don't affect the maximum pullup resistance as much as you might think

because the threshold voltage typically also scales down with Vcc, so you're still dealing

with about the same RC time constant.  In any case you'de need to look at capacitive loading

to find a reasonable maximum for Rp, or else you could just use the minimum allowable

value which only depends on Vcc max vs the max allowable pullup current.

 

-- Gabor

-- Gabor

View solution in original post

0 Kudos
kriss.osmanis
Visitor
Visitor
9,122 Views
Registered: ‎11-29-2012
Update: I reduced the speed to 100kbps and it worked fine, so I the ideas about rise time issues were correct.
Although, it would be interesting to hear other people experience with ML605 and this I2C chain.
0 Kudos