I2C controller core

After a communication (write) failure with just a master(I2C controller Core) and a slave on a bus, I scoped the SCL and SDA signals and counted 10 SCL ticks with the second byte out (first data byte). There seems to be a tick before the data comes out. The other 9 ticks align with the data. And of course the slave fails to ACK this second byte. I also scoped scl_padoen_o so I know the core is generating the extra pulse.

I am using an Altera CycloneII Nios Dev board and Quartus 9.0

stu

Follow up... I can suppress the anomalous tick using brute force (counter and logic) and the slave can complete the transaction (ACK occurs). So there is something going on in the core that generates this extra tick.

scope traces are available.

stu

I can't replicate this. The only time I see a 10th rising edge is when the core enters repeated start or stop states, which should be ok.

Can you please prepare a testbench or at least a wave snapshot?

Thanks, Richard

I am implementing it in a Cyclone III and have exactly the same problem... there is an extra clock after the address is written (or before the data byte is written) - during the extra clock the data goes high... the data is aligned correctly with the clock thereafter. The implementation is in an Altera NEEK eval. board.

Any thoughts on this would be appreciated - otherwise I would appreciate the "work-around" fix that stu used to make it work.

Thanks Bill

Hi Bill, I had that same problem also. My application required a different processor interface (wr,rd,addr,data) so I had to strip the whishbone interface.

From what I see in the simulation is that the state machine c_state moves from st_ack to st_idle when the core_ack from the bit controller goes high. Thereafter the idle state samples the control register (START,STOP,READ,WRITE...) and the START bit from the address write is still there. By the time the interrupt has propagated through it is too late and the state machine has entered a st_start state, generating a start sequence.

My solution is to clear the control register where it enters the byte controller using the core_ack signal from the bit controller. So a write from the processor set it to the value on the databus, when the core_ack goes high a Just be certain to write the whole control word and not to use read-modify-write instructions on the individual bits.

Jan.

Hello,

I am wondering if there are any developments about this bug. If Richard can't replicate this then does it mean that it may be random and related to a fpga specific issue? I am planning to use this core for my project. I think a lot of people are using the core without problems so it should be safe to use it.

I would be happy to hear about this. thanks a lot rifo

This should have been fixed now.