altufm with i2c not working

[Altera_Forum]

Hello 

 I'm using a MAXII EPM570 in one of my Projects. I'm trying to replace a serial EEPROM with the EPM570 thats on the board for other purposes. Therefor I'm using the altufm Megafunction in Quartus 7.2 to build the serial EEPROM.   It is working just fine in the simulation (functional AND timing) but doesn't work on the chip once programmed. The slave doesnt give an ack when addressed. I even tried with a I2C scanner to check if the address is wrong, but had no luck. The Signals meet the timing requirements and the data sent is correct. I built the same waveform in the simulation waveform file, where the CPLD is acting as expected.  My only warnings (14 of them) I get is:  Found 14 nodes in clock paths wich may be acting as ripple and/or gated clocks.--nodes analyzed as buffers resulting in clock skew.     So here is my detailed setup:  Quartus 7.2 Web edition and/or Quartus 7.0 full Licence (same Problem) Target Chip: EPM570T100C5N SDA and SCL defined as bidirectional LVCMOS pulled up with external 2.1k Resistor. altufm 4K acting as read only, Initialized with a .mif file, Interface I2C I2C address is set to 50. scl frequency is 100kHz Bus voltage is 3.3V (same as supply) There is no logic between the altufm and the physical pin I use.  Can anyone please help me on this? :confused:

[Altera_Forum]

--- Quote Start ---  ... It is working just fine in the simulation (functional AND timing) but doesn't work on the chip once programmed... The Signals meet the timing requirements and the data sent is correct. I built the same waveform in the simulation waveform file, where the CPLD is acting as expected.  My only warnings (14 of them) I get is:  Found 14 nodes in clock paths wich may be acting as ripple and/or gated clocks.--nodes analyzed as buffers resulting in clock skew.  --- Quote End ---     Did you constrain all timing paths? Verify this with Processing --> Start --> Start Classic Timing Analyzer Constraint Check.  Do you have reported timing violations? If so, those could cause problems in hardware even if timing simulation works.  Even if you correctly constrained all paths and have no reported timing violations, the ripple and gated clocks can cause problems. See my posts at http://www.alteraforum.com/forum/showthread.php?t=754.  Your I2C problem might be caused by something else, but you need to be careful with the ripple and gated clocks anyway.

[Altera_Forum]

--- Quote Start ---  Did you constrain all timing paths? Verify this with Processing --> Start --> Start Classic Timing Analyzer Constraint Check.  Do you have reported timing violations? If so, those could cause problems in hardware even if timing simulation works.  Even if you correctly constrained all paths and have no reported timing violations, the ripple and gated clocks can cause problems. See my posts at http://www.alteraforum.com/forum/showthread.php?t=754.  Your I2C problem might be caused by something else, but you need to be careful with the ripple and gated clocks anyway.  --- Quote End ---    Thanks for you help, but I constrained all the timing paths(No warnings/Errors in constraint check). I also don't get any timing violations. I0m using the atufm Megafunction so I cannot avoid gated/rippled clocks. I'm assuming that altera checked that Megafunction. I'll read your post in detail tomorrow. Thanks a lot anyways.  (And its not a chip failure, tried it on several hardware)

[Altera_Forum]

Do you mean the MAX II device did not even issue the ACK after the first 8 data bits transferred from the master? Normally this is because the slave address issued is incorrect. Can you double check? 

 The I2C megafunction uses gated clock. If you do not have additional logic between the megafunction and the I/O pins, you shouldn't have any problem.