Forums

I2C protocol to communicate between FPGAs

Started by greenplanet February 27, 2005
Dear all,

I am a newbie and am currently having a project to develop an I2C
protocol in VHDL.  My aim is to communicate between two Xilinx
XC4005XL, one as master and one as slave.  I wonder if any of you could
provide me with some ideas on how I should start.  I2C has 2 wires, SCL
and SDA; all I have to do is to play with these two wires?  What else
should be considered?  What I should do next?

Thanks a lot!

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.

"Jezwold" <edad3000@yahoo.co.uk> wrote in message
news:1109493349.897361.135530@o13g2000cwo.googlegroups.com...
> 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.
> ;-) 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.
"Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message
news:sjkUd.840$AB1.557@newsfe4-gui.ntli.net...
> > ;-) 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.
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&#2013266098;C interface on a chip (IC, ASIC, FPGA, etc). It is Philips's position that all chips that can talk to the I&#2013266098;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&#2013266098;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.
> 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.
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.
> 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.
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.
> 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.
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. ;-)
> 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. > > > > >
"Anthony Fremont" <spam@anywhere.com> wrote in message 
news:aQtUd.66873$cW2.23375@fe2.texas.rr.com...
> >> I see "TWI" in data sheets > 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:
> "It is Philips's position that all chips that can talk > to the I&#2013266098;C bus must be licensed."
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.
> 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.
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.
> As long as you need to send data in both directions simultaneously, > I suppose it is.
Well, just ignore the stuff you don't want.
> It does require 50% more wires though > (2-wire I2C vs. 3-wire SPI)
One more wire is not a huge burden.
> Isn't it amazing how no-one needs a ground to > communicate?
> You kinda make SPI sound like a panacea compared to I2C
Not my intention. The OP sounded like he just needed a point to point link, thus the SPI would be good enough.
> Real SPI requires chip select pins for each slave device
I know. But if he only has the one slave, that's only one pin.
> the total number of wires to 3 + > number_of_slave_devices (not counting the ground),
True, and I2C tackles that issue.
> inconvenient and wasteful IMO.
> There are also I2C devices that have a > maximum speed of 2 MHz.
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.
> AFAIK, SPI is not that much faster than that
But the SPI spec insists on a higher speed, thus if a slave say it uses SPI then the guaranteed speed is higher.
> 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.
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.
>> I2C master behaviour is easily implemented by >> bit-bashing a pair of open-collector pins. > > 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. ;-)
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.
Anthony Fremont wrote:
> "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message > news:sjkUd.840$AB1.557@newsfe4-gui.ntli.net... > >>>;-) 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.
You can also call it AccessBUS, which is a PC variant.
> 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&#2013266098;C interface on a chip (IC, > ASIC, FPGA, etc). It is Philips's position that all chips that can talk > to the I&#2013266098;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&#2013266098;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.
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. <snip> > 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.
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
"Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message
news:IevUd.2761$Qd1.1132@newsfe2-gui.ntli.net...
> "Anthony Fremont" <spam@anywhere.com> wrote in message > news:aQtUd.66873$cW2.23375@fe2.texas.rr.com... > > > >> I see "TWI" in data sheets > > 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: > > > "It is Philips's position that all chips that can talk > > to the I&#2013266098;C bus must be licensed." > > Any microcontroller with two I/O pins that can be > switched from 0V to hi-z can talk to the I2C bus.
I agree, but I think they mean chips that are actually programmed.
> 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.
Well, that could be I suppose, but my qoute was directly from Philip's web site.
> > 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. > > 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. > > > As long as you need to send data in both directions simultaneously, > > I suppose it is. > > Well, just ignore the stuff you don't want. > > > It does require 50% more wires though > > (2-wire I2C vs. 3-wire SPI) > > One more wire is not a huge burden. > > > Isn't it amazing how no-one needs a ground to > > communicate? > > > You kinda make SPI sound like a panacea compared to I2C > > Not my intention. > > The OP sounded like he just needed a point to point link, > thus the SPI would be good enough. > > > Real SPI requires chip select pins for each slave device > > I know. > > But if he only has the one slave, that's only one pin. > > > the total number of wires to 3 + > > number_of_slave_devices (not counting the ground), > > True, and I2C tackles that issue. > > > inconvenient and wasteful IMO. > > > > > > There are also I2C devices that have a > > maximum speed of 2 MHz. > > 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. > > > > AFAIK, SPI is not that much faster than that > > But the SPI spec insists on a higher speed, thus if a slave say it
uses SPI
> then the guaranteed speed is higher. > > > 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. > > 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. > > >> I2C master behaviour is easily implemented by > >> bit-bashing a pair of open-collector pins. > > > > 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. ;-) > > 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.
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.
"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:42228d04$1@clear.net.nz...
> Anthony Fremont wrote: > > "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message > > news:sjkUd.840$AB1.557@newsfe4-gui.ntli.net... > > > >>>;-) 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. > > You can also call it AccessBUS, which is a PC variant.
Or even SMBus?
> > 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&#2013266098;C interface on a chip
(IC,
> > ASIC, FPGA, etc). It is Philips's position that all chips that can
talk
> > to the I&#2013266098;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&#2013266098;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. > > 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. 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: http://www.semiconductors.philips.com/acrobat_download/various/i2c_overview_2h_2003.pdf
> <snip> > > 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. > > 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.
That's pretty fast. I'm guessing you don't get 100M of bus length very easily. ;-)
> 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 >
"Jim Granville" <no.spam@designtools.co.nz> wrote in message 
news:42228d04$1@clear.net.nz...

> You can also call it AccessBUS, which is a PC variant.
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.
> Using as FPGA-FPGA there is no strict need to stick to any 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 20 MHz
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.