Implementing a I2C IO Expander using a PLD

Dears,
I would like to implement an IO expander capable to communicate with a microcontroller via I2C. The requested number of IO is 80 and I was thinking to implement such component using a CPLD/FPGA. The MachX02 by Lattice provides hardened I2C ports which makes this device suitable for this kind of application. They also provide a reference design as starting point.
However, since I have been using Xilinx CPLD so far, I was thinking to implement the I2C an IO expander on a xilinx CPLD. However, I read that many people after implementing the I2C state machine,they ended up having no more resources for the user logic. Should I go for an FPGA instead of a CPLD?
What are your suggestion about?

Many thanks

matte87 said:

Dears,
I would like to implement an IO expander capable to communicate with a microcontroller via I2C. The requested number of IO is 80 and I was thinking to implement such component using a CPLD/FPGA. The MachX02 by Lattice provides hardened I2C ports which makes this device suitable for this kind of application. They also provide a reference design as starting point.
However, since I have been using Xilinx CPLD so far, I was thinking to implement the I2C an IO expander on a xilinx CPLD. However, I read that many people after implementing the I2C state machine,they ended up having no more resources for the user logic. Should I go for an FPGA instead of a CPLD?
What are your suggestion about?

Many thanks

Click to expand...

it depends on the cpld you are using - latest cpld are very big comparing to the past.
usually most resources will be spent the counters, or clock dividers, require to deal with a very low frequency signals.
in your case you want to have 80 i/os so it will require more registers, then normal i2c design.

If you want something in between the olden cpld's and the big fpga's, you might want to check out the ice40 series from Lattice. There's also a dev board for $25.

Also, I would just ditch I2C and go SPI. Less hassle, higher update rate for your IO's. And and AND!! if you implement it yourself
then SPI is a whole lot cheaper than I2C in terms of resources.

So if your mcu has SPI, then use that. And if it doesn't have it, why not?!?

If all you want is say 10 8-bit registers you can address and update, then the SPI slave implementation for that is going to be pretty minimal. Possibly you want some buffering so that you can write to a couple of latches first, and then with an UPDATE_ALL command you write all the latches to the output buffers.

I would say that the main constraint is going to be: find the package that you can work with and has enough IO's. Then as an afterthought check if there's enough logic resources to implement the above.

But again: if you have a limited amount of resources, forget about I2C. Way too expensive for the functionality you get in return. If you must, you must. But if you have a choice, use SPI.

- - - Updated - - -

Did a quick check, and the ones in TQFP144 package from either the ice40 or the machxo2 series should do the trick. The big-enough bga's as well obviously, but you didn't mention if you like bga or not.