I am needed to talk with a microcontroller through an I2C interface from my FPGA. I dont want to write a code for it as well not use an opensource core. This is partly due to space constraints and testing. Speed and cost are not constraints. So I was hoping to find a chip which would sandwich between the FPGA and I2C interface. Searched on the net but could not find any. If anyone has suggestions please let me know.
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...
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)
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.
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)
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.