I2C controller chipset to interface with FPGA

How about these?

But you may still be right there :-)

Cheers, Martin

--
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt

Look at i2c BUS controllers from Philips

and the PCA9564 is a candidate. These take a parallel uC BUS and connect to i2c - so you will need to load some config registers, from the FPGA, but not many. This device goes to ~400KHz

You could also look at any small uC that has separate SPI and i2c HW - eg Philips LPC916 in TSSOP16, or most Silabs C8051F3xx devices and are about the same price as the 9564- and you get ADC/DAC and proper buffering, for free...

-jg

That should tell you something then.

Like nobody does it that way, for good reasons.

There are some controller chips but you have to write code to use them. And if you can do that, you might just as well write the code to bit-bash the I2C interface. Come on, it isn't that hard to do.

That depends - if you want to bit-bash, on a FPGA that infers a SoftCPU, and that is resource intensive. First, you need to have this CPU, then you need the time/code resource to service i2c.

Also, i2c slave is non trivial, and the external chip does it already ( or, the OP might need 5V compliant i2c, not so easy on FPGAs ! )

Thus a parallel controller could be INIT and serviced with a simple statemachine, but I would favour a small uC as a SPI-i2c buffered bridge, as that can be smarter, and has less pin-cost ( but that does have another development cycle of its own)

-jg

Certainly there is! Look for the Philips PCF8584 or PCA9564.

I2C is not particularly resource intensive, especially if only a subset of the full spec is used. It can be incorporated in the FPGA fabric without a huge development effort, and with modern FPGAs is going to take but a small corner of the FPGA. For the slave side, which it sounds like you are, the decode and data steering is probably bigger than the shift register and state machine.

no there isnt - the overhead for interfacing external i2c controller is larger than the sw needed to implement the i2c in softwre only so from that point of view there is no easy solution that makes the fpga sides simpler.

implementing i2c in fpga in hw or sw is simpler than interfacing PCFxxx pr PCAxxx

so there is no easy sandwitch-chip

Antti PS look at other posters they say the same thing I did.. and YES I do know the existance of the silicon you mentioned.

A second microcontroller :-) Connect the PIC 16FL87X to your FPGA and program the PIC to send data received on the RB port out on the I2C port or vice versa...

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

snipped-for-privacy@gmail.com schrieb:

I2C is a protocol. You can use the FPGA to talk to the uP via the I2C protocol. Or you can use another chip that talks to the uP via I2C, but then, how do you talk to the other chip? You need another protocol to do that. You can not get rid of a communication protocol implemented by FPGA logic. What you are assuming is, that there is some other protocol that is a lot easier and smaller to implement than I2C. But that depends on were your data is coming from and going to.

If your data inside the FPGA is processed bit serial I am sure that it is simpler to output it by I2C than using a parallel processor bus. However, if you have a uP inside your FPGA a peripheral chip as other posters suggested is of course simpler.

So you are down to what protocol you use for comunication inside your FPGA. Resources depend a lot on that and your data pattern. For example using SLR16s it should not take much more than three luts to send a single byte once or repeatedly over I2C. (assuming you have a slow clock available)

Kolja Sulimma

It takes fewer pins to do I2C directly than to interface the Philips parts, unless you already have a parallel bus you're using for other stuff.

But it's not particularly "simpler" to do I2C hardware yourself, at least if you care about actually meeting the full I2C specifications. I've seen a lot of bad I2C implementations that won't work under various real-world conditions. For instance, I2C masters that don't handle clock-stretching, or that don't handle arbitration. And I2C slaves that don't meet the I2C timing specs.

The software bit-banging implementations are usually (but not always) the worst as far as violating the specs.

I'm not saying that it's tremendously difficult to do it right, but it is definitely more difficult than just bolting on a chip with an 8-bit parallel interface that does all the "heavy lifting" for you. I've done it both ways. I wouldn't design in the Philips chip is a cost-sensitive high-volume product, but for a less cost-sensitive design, or if time-to- market is a major concern, it's a reasonable approach.

Eric

another alternative ( but perhaps a bit new...) is this family from Philips :

This is TSSOP16, SPI-i2c master, 3Md on SPI and 400KHz on i2c. [ It may even be a pgmd LPC916 :) ? ]

The overview does not say if the i2c side is 5V compliant.

-jg

Further to this option, Philips have more info here:

This shows the (very new) 9664, which adds a trimmed OSC,

68 byte buffer, and 50MHz databus speeds, with 1MHz i2c, so these devices are improving quite rapidly....

If such a device meant you could use the next-smallest FPGA, it would pay for itself. Could also make sense next to a MAX II or MachXO, where resource is more precious....

-jg