I2C protocol to communicate between FPGAs

Well you could just wiggle the wires and see what happens or you could check out the i2c core at opencores.org and you could even get the documentation and read how it all works.

;-) Also, if he's looking to sell these, he will need to obtain a license from Phillips.

IIRC you do if you want to market it with "I2C" mentioned anywhere, but if you call it something else (e.g. Two-Wire Interface or TWI) then you do not. I see "TWI" in data sheets that look remarkably like I2C at first glance and may be identical.

Then again, they may have just made a mistake in the implementation so that it doesn't fully meet the I2C spec and they would get sued if a customer product failed for not meeting the spec.

I2C may not be the best choice for the OP.

I2C is an open-collector bus, great for talking to multiple slaves without conflict causing damage. However, it is speed limited by the rate the passive pull-ups can pull up.

SPI is less clever but simpler because it does not need a clever conflict arbitration scheme. And faster as well.

OP> I am a newbie and am OP> currently having a project to develop an I2C protocol in VHDL.

The protocol is already developed and specified.

Regarding implementation, I2C slave behaviour should be done with hardware assistance, while I2C master behaviour is easily implemented by bit-bashing a pair of open-collector pins.

OP> I2C has 2 wires, SCL and SDA; all I have to do is to play with these two wires?

Yep. You can even bit-bash I2C master behaviour on an LPT port.

OP> What else should be considered?

How will you set the address(es) of the slave(s)? How will you handle protocol failures (slave not responding, duff data, etc)? Is there a CPU in your system? How will you develop code for the 4005? IIRC it is obsolete and no longer supported by the Xilinx webpack.

OP> What I should do next?

If you've been set this as a university project, and the exercise is specifically for you to learn I2C, then I guess one is stuck with it.

If it is your own project, ask if you really need the extra sophistication of I2C. Are there ever going to be more than one slave? If not, the slave arbitration features are pointless.

As a further aside, if SPI is not to your liking then you could look at the Inmos Transputer Link protocol that Inmos developed for high-speed comms between networked transputers. I have the data sheet I could scan for you.

20 Mbits/sec, about 2 MByte/sec data rate. That's about 200 times faster than I2C, and simpler too.

then you

glance and

I see this done also but, according to Philips, it doesn't alleviate the end user of the responsibility of acquiring a license. Here let me quote them, I hope they don't sue me for copyright violations:

==============================

"A license is required for implementing an I²C interface on a chip (IC, ASIC, FPGA, etc). It is Philips's position that all chips that can talk to the I²C bus must be licensed. It doesn't matter how this interface is implemented. The licensed manufacturer may use its own know how, purchased IP cores, or whatever.

This also applies to FPGAs. However, since the FPGAs are programmed by the user, the user is considered a company that builds an I²C -IC and would need to obtain the license from Philips. "

==============================

Well, how do you like that? They see no end to their patent's reach. I maintain, however, that many of their patents have likely expired. I've sure never seen Philips defending their patent on I2C as vehemently as the above quote would indicate. Me thinks they don't want to make to many waves about their "obvious" technique lest they lose out on all the companies that currently pay them.

that

customer

without

up.

conflict

As long as you need to send data in both directions simultaneously, I suppose it is. It does require 50% more wires though (2-wire I2C vs

3-wire SPI) ;-) Isn't it amazing how no-one needs a ground to communicate?

You kinda make SPI sound like a panacea compared to I2C and I disagree with that. Real SPI requires chip select pins for each slave device on the bus, bringing the total number of wires to 3 + number_of_slave_devices (not counting the ground), that's a bit inconvenient and wasteful IMO. There are also I2C devices that have a maximum speed of 2Mhz. AFAIK, SPI is not that much faster than that even with being able to transfer data full duplex.

There does seem to be some discrepancy out there as to what constitutes a START condition. Some vendors think you have to bring the clock low after bringing the data low before considering it a START. That's not how Philip's describes it though as they say nothing about bringing the clock low to complete the start condition.

hardware

bit-bashing

I agree. I've just been doing this for the first time ever with some serial eeproms and a DS1307 real-time clock chip. I like it, it's a cake walk compared to Dallas 1-wire i/o. ;-)

these two

data,

sophistication

at the

comms

you.

faster

Any microcontroller with two I/O pins that can be switched from 0V to hi-z can talk to the I2C bus.

I heard that they didn't mind you making an I2C master that can talk to I2C slaves, since most of their I2C-ready chips were slaves for TV innards etc. and they could not really demand a licence from potential customers.

However I heard they did not want to allow people free rein to make competing slave chips, so they did demand a licence fee on that.

When I was in the consumer electronics arena, word was that Philips developed stuff like the I2C chips for TVs and RC5 / RC6 for their own TVs etc, and their chip making branch was their to serve their consumer goods making branch. They would sell their chips to others to spread the NRE but they would not make much effort to support them. After all you might be a competing TV maker.

They made the RC5 standard public but it was not a very tight spec and some manufacturers used unassigned codes for their own purposes. So when they came up with RC6 they didn't bother publicising standards at all.

Well, just ignore the stuff you don't want.

One more wire is not a huge burden.

Not my intention.

The OP sounded like he just needed a point to point link, thus the SPI would be good enough.

I know.

But if he only has the one slave, that's only one pin.

True, and I2C tackles that issue.

That is beyond the I2C spec, which is 100 kbps or 400 kbps in the faster version. I2C slaves are not obliged to run that fast, so you cannot rely on an I2C slave being that fast.

But the SPI spec insists on a higher speed, thus if a slave say it uses SPI then the guaranteed speed is higher.

If Philips own the spec, then what they say _is_ the spec. If other vendors wish to diverge, then they should look out.

Maybe Philips should tighten up the spec.

I have noticed that I2C slave interface on Microchip's PIC is a crock of shit. It locks up if it gets confused, then doesn't allow you to escape from it by software.

It is nice eh?

Though I did find there were some quirks in various I2C slave chips. My LM75 thermometer isn't talking to me yet! I think it wants a 100 nF decoupler.

You can also call it AccessBUS, which is a PC variant.

Maybe, but I have a Philips data book IC12 that states : " i2c BUS based system designs require no special license, and the i2c bus protocol is easily implemented by virtually any microcontroller on the market"

i2c IS a trademark, and so if you want to get the perceived marketing of that trademark, and use it in your DOCs, Philips have to give the OK.

i2c has Speed nodes at 100Khz, 400KHz, 1MHz, and 3.4MHz, but few devices can be found at 3.4MHz.... SPI is now commonly spec'd to 25MHz, and some devices are 50MHz.

Some SPI designs use a RING scheme, which removes the multiple chip-select issues. With most SPI HW ports in uC, they fully support this RING alternative.

Using as FPGA-FPGA there is no strict need to stick to anyt of the i2c speeds, and if you deployed it using CAN BUS buffers (or wired-OR configured RS422 devices) you could probably get i2c over 20MHz

-jg

the

I agree, but I think they mean chips that are actually programmed.

to I2C

etc.

Well, that could be I suppose, but my qoute was directly from Philip's web site.

reach.

vehemently

make to

the

TVs

goods

but

be a

some

they

faster

I2C

uses SPI

constitutes

low

of

it by

some

Hard telling. I had real good luck when I recently implemented my bit bang I2C stuff. It worked the first time out. However, I can easily imagine how frustrating solving a problem could potentially be. I don't own a DSO or logic analyzer so I rely allot on fully understanding the protocol before writing that first line of code. The exception to this was when I wrote a Dallas 1-wire search routine. I didn't really understand it all until I was done writing the code. I blindly implemented a flow chart that Dallas provides. I did this in PIC assembler, but the problem cries out for a recursive solution.

In my current project, I have a PIC talking to various serial eeproms and a Dallas 1307 real time clock. I2C may not be perfect, but it's doing a nice job for me.

I've never used an LM75, but I have used an LM34 and various Dallas

1-wire temp sensors. I really like the 1-wire temp sensors, but they only come in Centigrade outputs.

Or even SMBus?

the

(IC,

talk

interface is

by

and

reach.

vehemently

make to

the

OK.

Interesting. My quote was straight from Philip's site in the licensing area. Perhaps the patents are finally expired? Here is a link to a document dated as 2H 2003:

That's pretty fast. I'm guessing you don't get 100M of bus length very easily. ;-)

I believe it is not a variant but a desk-top bus that uses I2C as the signalling protocol as a foundation. It then goes on to specify the contents of the messages sent across I2C.

If he is just using it for point-to-point comms there is no need to stick to any spec at all.

With only one bus master there is no need for wire-oring of any sort, so no need for CANbus buffers either.

I think they mean any hardware implementation that handles much of the low level stuff.

I've written software to bit-bang I2C without paying a licence.

It would be pretty hard to enforce licence fees there, unlike chips that you have to make in millions.

Most problems I hear are due to people not following the I2C spec faithfully.

Yep, helps a lot. :-)

I don't have any complaints about I2C at all. It is very cunning yet masters require only a couple of I/O bits to use it.

Hmm, I only see the F-word used in weather reports where they translate the temperature for the benefit of people who couldn't/wouldn't get a grip on modern units. Typically old people. If you are making a weather station type thing then the rounding errors of the C to F conversion shouldn't be a big problem.

IANAL, but AFAIK Patents expire 17 years after their publishing date. For the I2C patent US000004689740A was published August 27th 1887, so it should be expired by now. Maybe it is also covered by another patent....

Kolja Sulimma

(someone wrote)

As someone else said, though, it is also trademarked. If you don't call it I2C you may be safe, but again, IANAL.

-- glen

Dear all,

Thank you very much for your valuable response. For those who may want to know, my thing is one of the slaves, and it has to communicate with the master who has to talk to many other slaves (components that I don't know what they are). I have to build the interface such that my thing knows when and what to respond when the master talks. I hope I could come out with something that works. =)

In this case: Some time ago I read somewhere on a phillips website that only one license is required per system. So if you have purchased a uC with I2C you can add an FPGA with an I2C slave to it without acquiring a new license. Try to find this with google.

Kolja Sulimma

want

with

my

I2C slaves can be very simple. Things to consider include your address, which must be different than other devices on the same bus. i.e. you need to know what the other slaves on the bus are so you can pick a "safe" address. As I recall Philips has a recommendation for classes of devices and ranges of addresses, but this is not part of the I2C bus specification. Another thing to consider is addressing mode, which is usually 7-bit for small devices but can be 10-bit. Using 10-bit addressing slows down your access.

Most I2C slave devices have multiple internal registers accessed using "subaddress" protocol. Take a look at a datasheet for the 24LC02 from Microchip to see how this works. When I make I2C slaves in FPGA's I usually use this protocol and attach a small RAM to allow readback of register values. This can reduce the overall device usage over multiplexing the individual registers, but you'll still need a mux to deal with read-only registers or registers that can change value from some other path than I2C.

Hope this helps, Gabor