XILINX I2C controller core in FPGA and multisource problem.

Hi, I have implemented a I2C bus core by myself.

When reading, a multiple source 'error' would happen if your code assertes the acknowledge bit slightly earlier than the target deasserts the bus from the last read data bit or when writing, if your code deasserts the acknowledge bit slightly later than the target asserts the acknowledge bit on the bus.

You may ignore them totally without any problem.

Weng

schrieb im Newsbeitrag news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

Weng, the multipy source error is usually fatal synthesis error and prevents the bitstream generation until fixed.

the OP has problem wiring up the processor data bus, not the SDA/SCL lines IMHO

Antti

Hi Antti, Thank you for indicating my wrong answer.

I misunderstood the problem.

One of errors is multi-source data_bus(7 downto 0) are assigned in more than one processes!

It is easy to correct it: Use search key to search signal 'data_bus' through the module source file and see how many times the data_bus are assigned. Put all assignments in one process only.

Weng

schrieb im Newsbeitrag news: snipped-for-privacy@g14g2000cwa.googlegroups.com...

Weng you are a bit mistaken again the data_bus is assigned once outside process

data_bus 'Z');

in the uc_interface.vhd

so the ip-core is 100% proper for its intended function - controller for external microcontroller.

for on-chip soc bus, the uc_interface module should be replaced, or modified.

antti

Hi Antti, I don't have his source code and made a judgement based on the following warnings: Unit i2c_tb: 8 multi-source signals are replaced by logic (pull-up yes): data_bus, data_bus, data_bus, data_bus, data_bus, data_bus, data_bus, data_bus.

1. data_bus are multi-source signals;
2. data_bus is in the module: i2c_tb. It may be in his test bench code to make the multi-source error.

I never claimed that it was the IP code error. Any IP code never makes such basic and fundamental error.

Weng

schrieb im Newsbeitrag news: snipped-for-privacy@g44g2000cwa.googlegroups.com...

no problems - I just checked the original - form without doing that your guess was 'close'

antti

Hi all, Thanks for your discussion.

I figured so much that we cannot be using the bidirectional buses all over the program. but i for sure have my doubts on whether the IP core is 100%proper even just as an individual unit. The reason is after the address match where the I2C controller is addressed as slave it does not send the acknowledge bit. I have enabled both the options in the control register and checked it but to no avail.

regards vasu

Antti Lukats wrote:

Hi,

1. I2C IP is so simple that it will never fail, in my opinion.

1. You are a newbie in this respect, the chance you make a mistake is beyond 99%.

2. If I2C controller contained in the IP doesn't send the acknowledge bit, your design is fundamentally wrong.

Can you imagine an IP fails to response with an acknowledge bit?

You may post your code and I will help you ID the first error, not all errors.

Weng

schrieb im Newsbeitrag news: snipped-for-privacy@g14g2000cwa.googlegroups.com...

simple things fail too, and too often

NO, the chances for an total newbie to get things right are defently better than 1%

The I2C core at opencores had been available for many years, still when I needed it I found a fundamental error in it. So similary the XAPP333 may have error in it as well

There are a well know errors with I2C, one way with half finished transmissions where on partner in the transmission keeps pulling SDA or SCL low. SMBus introduces timeouts into the protocoll, pure I2C may need to switch off the partner, pulling the bus low. Sometimes this has to be done with the supply line...

Hi Antti, I am surprised to learn your opinions:

1. "simple things fail too, and too often", I agree.

1. "NO, the chances for an total newbie to get things right are defently better than 1%", I disagree.

Let's see what is wrong with his problem.

Weng