I2C master logic implementation

[Aani]

Hi,
Iam using the I2c communication protocol considering FPGA as I2C master and TMP513 as I2C slave device.
But during the process of this I2C communication, I am able to write the data to slave device and get the slave acknowledgement back. But during read operation, the slave is giving out the data as 0x0000 to the master (FPGA) for any internal register access.

The A0 pin has been grounded in the hardware, so the 7-bit slave address given is 1011100.
And also I do see the device returning the value 0x0000 on the Logic Analyzer, to master (FPGA) instead of non-zero value, during the read operation performed for one of the Internal Register (i.e., Device ID register (Address = 0x1F/FF) with data 0x23FF).

Please help me out where am I doing wrong for the data is being read as 0x0000 all the time.

SDA line conditions in code:
SDA <= SDA_OUT when SDA_OE = '1' else 'Z';
SDA_IN <= SDA when SDA_OE = '0' else '0';

Thank You.

 

[KlausST]

Hi,

Post your hardware (schematic, photo)
Post your code

Klaus

 

[Aani]

Hi,
Thank you for the reply.

I have attached the schematic and the vhdl code file.

 

[dpaul]

How did you test that the I2C master implemented inside the FPGA is working correctly?
Have you connected it to a dummy slave module (imitating the I2C registers of the TMP513) and run functional verification to ascertain that R/W are working correctly?
I would first ascertain this and if everything is working correctly then go for board/hardware level debug.

 

[Aani]

Yes, I did test with TMP513 device for the code.
I am attaching an image captured on the logic analyzer and it can be seen that write op is working but during read, it is always 0x0000.
I am not able to make out what is going wrong? Please help.

 

[ads-ee]

Yes, I did test with TMP513 device for the code.
I am attaching an image captured on the logic analyzer and it can be seen that write op is working but during read, it is always 0x0000.
I am not able to make out what is going wrong? Please help.

How did you test that the I2C master implemented inside the FPGA is working correctly?
Have you connected it to a dummy slave module (imitating the I2C registers of the TMP513) and run functional verification to ascertain that R/W are working correctly?
I would first ascertain this and if everything is working correctly then go for board/hardware level debug.

You did not test it using a functional simulation as @dpaul suggested. You went and put it on hardware without verifying functionality before implementing it an FPGA.

You don't show the entire write transfer, which may be incorrect. It also appears you may be violating the setup time of the ACK for the MSB of the read as you have a half cycle of not-ACK. Not sure why you are producing an NACK on the LSB of the read.

 

[Aani]

You did not test it using a functional simulation as @dpaul suggested. You went and put it on hardware without verifying functionality before implementing it an FPGA.

You don't show the entire write transfer, which may be incorrect. It also appears you may be violating the setup time of the ACK for the MSB of the read as you have a half cycle of not-ACK. Not sure why you are producing an NACK on the LSB of the read.

I did test the code through simulation and the simulation results were as expected and the code seems to be working correct.
But when testing it on hardware, there is no data read always 0x0000.

I want to know the reason for it even though the FPGA (master) is receiving the slave ACK for the provided data.

 

[KlausST]

Hi,

Please use a scope and show only the read transfer (where you get the 0x0000)
maybe you need two pictures:
* one where we can see the timing and the voltage levels in detail
* one where we can see all the single bits of data transmitted

Currently I can only guess: The FPGA does not release the SDA line, or wrong open_drain implementation.

You can check with the same data (read) transfer but all slaves disconnected. Pullup still needs to be connected.

Klaus

 

[zian]

SDA line conditions in code:
SDA <= SDA_OUT when SDA_OE = '1' else 'Z';
SDA_IN <= SDA when SDA_OE = '0' else '0';

Can you post your HDL code for SCL ? It's not very famous but SCL is also a tri-state with I2C : the slave is allowed to force SCL to GND for asking more time for its treatment, it can be your problem.

 

[Aani]

Hello,
Presently, I am working on I2C protocol for a project. Here, FPGA is the master and LTC4151 is the slave.
I am able to do I2C write and read operation successfully.
But one of the issue I am facing now is that whatever the data that has been read from the slave is serial and now I want to convert that received serial data to parallel and store that in one of the register which I am not able to do it. I mean to say the register data_out1 and reg1 always has a default value 0xFF and not the intended data.
Can anyone please tell me what can be the reason and how do I resolve it?

I am also attaching a small snippet of code, where I am facing the issue, for reference.

 

[Aani]

Can you post your HDL code for SCL ? It's not very famous but SCL is also a tri-state with I2C : the slave is allowed to force SCL to GND for asking more time for its treatment, it can be your problem.

I have attached the code file.
whatever changes are made , even then the data from slave is always stuck at 0x00. I am not able to figure out the reason for it.

 

[KlausST]

Hi,

I think it´s the most often mistake with I2C.

SDA as well as SCL have to be treated identicaly.
Both have only two states: LOW (actively driven) or HIGH-Z
(using SCL as OUTPUT is against I2C specification and may lead to short circuit when clock_stretching_devices are on the bus)

Neither SDA nor SCL will ever be driven HIGH.

***

When using a tri state output buffer:
* let the data input of the buffer always be LOW
* control the signal state only with OE.
(again: both for SDA and SCL)

Output_Enabled then automatically switches LOW
Output_Disabled then automatically switches to HIGH-Z

Use just two internal signals for SDA:
* SDA_OUT which just controls the BUFFER_OE
* SDA_IN which reads the pin state

I recommend the same for SCL:
* SCL_OUT which just controls the BUFFER_OE
* SDA_IN which reads the pin state (only needed when clock_stretching is implemented)

***
Please check your SDA_OE polarity:
you say "--output buffer enable, high=input (hi-Z output), low=active drive"
This is inverted logic.But often it´s straight logic.

***

I recommend to read I2C specification.
Or use ready available code.

Klaus