i2c to i2c switch in FPGA

[ckaa]

Hi,
Anybody ever implemented an i2c switch in FPGA? I am trying to implement a 1 to 10 i2c switch in a FPGA (functionally similar to PCA9548A from TI). I know there are ICs out there which would serve the same functionality but need to implement it in a FPGA. Any hints or suggestions about problems I would run into when trying to implement this in a FPGA would be great!
Thx

 

[barath_87]

How should this i2c switch module on FPGA take in the control register (mux select line) value via i2c??

 

[ckaa]

Well I guess I have to define a register interface in the FPGA and do the mux select via i2c.

 

[barath_87]

OK then you will have to implement an i2c slave which I think you can find here
and then use the o/p of the control reg as select line of the SDA,SCL mux. Apart from acting as a s/w i2c s/w module should also listen to all i2c transaction so that it can update the control reg.Nice one I will also try doing it in my spare time .

 

[FvM]

The PCA9548 function can't be implemented in a FPGA, because no FPGA has bidirectional (analog) bus switches as they are used in this device. SDA (and in part) SCL are bidirectional signals, they can't be "switched" by digital buffers without knowing the instantaneous data direction. An FPGA would have to implement additional logic, that determines the data direction from an I2C protocol analysis (e.g. R/W bit), assuming that all peers are behaving correctly.

In any case, the operation would be partly different from PCA9548.

 

[barath_87]

The PCA9548 function can't be implemented in a FPGA, because no FPGA has bidirectional (analog) bus switches as they are used in this device. SDA (and in part) SCL are bidirectional signals, they can't be "switched" by digital buffers without knowing the instantaneous data direction. An FPGA would have to implement additional logic, that determines the data direction from an I2C protocol analysis (e.g. R/W bit), assuming that all peers are behaving correctly.

In any case, the operation would be partly different from PCA9548.

I agree with FvM the the I2C mux module has to listen to every I2C transfer happening through it and accordingly set the direction for the selected SDA I/O buffer line. This case i2c s/w module should also know how the i2c transfer is going to takes place between the master and the slave devices so that the input buffer can be selected for the SDA when the slave is transfering data on the line.(In the beginnig SDA line is configured as o/p in i2c s/w for the slave to detect i2c start and the command bit). For SCL I think only an o/p buffer is required and it need not be controlled like SDA. Nice catch FvM I did not think about this earlier.

 

[FvM]

For SCL I think only an o/p buffer is required

The SCL mux can be implemented as a simple buffer, if no clock stretching is required. The original PCA9548 would even support multi-master I2C, once the connection matrix has been setup.

But I guess, a standard I2C "switch" application involves neither clock stretching nor multi master.

 

[ckaa]

Thanks for the info, appreciate it!

 

[supercat]

For SCL I think only an o/p buffer is required and it need not be controlled like SDA.

Many I2C slave devices never implement clock stretching; for such devices, the clock is indeed unidirectional. As FvM notes, protocol analysis will allow an FPGA to determine what is going on, though in fact protocol analysis may not always be needed. If a slave isn't using clock stretching, it must switch SDA on the falling edge of SCK and latch it on the rising edge. After each falling edge of SCK the FPGA may float SDA on the slave side, provided that (if master is driving SDA) it reasserts it prior to next asserting SCK on the slave side.

If a slave device does use clock stretching, things are much harder. During any interval when the clock is low, data will only be sent in one direction. If data is being sent to the slave, the FPGA must wait for the master to raise SCK to determine what value SDA must have on the slave side before it releases the slave's SDA. It's okay, though, if the master thinks the slave got the data before it really did, provided the FPGA buffers the bit (if the master reasserts SCK before the slave has released SCK, the FPGA should hold the master's SCK while it waits for the slave to release SCK, and then handle the next bit).

If a bit of data is being sent from the slave to the master, the FPGA should assert and release SCK after the minimum low time, and hold the master's SCK until the slave releases its.

I don't think multi-master I2C could be handled, but single-master I2C should be workable.

 

[pareshpatel204]

can anyone help me for i2c to i2c switch in fpga vhld code..
its urgent please......

 

[craftor]

I have implemented an I2C master in verilog, it can read/write I2C-based EEPROM like AT24C0x. I cut the I2C bus control into 4 steps : start, stop, write, read. And any operation on an I2C device can be assembled by these steps.
See
**broken link removed**

 

[rca]

first point, why need a i2c switch? to reduce the line capacity?, normaly all I2C components could be connected in parallel.
second point, only "analog component" are able to do a real i2c switch.

 

[FvM]

can anyone help me for i2c to i2c switch in fpga vhld code

It should be clear from the previous discussion, that the functionality of the switch has to be specified more detailed. But I fear, no one has a ready-to-use design (apart from the question, if he's willing to share it for free...)

only "analog component" are able to do a real i2c switch

The term real switch may be understood different, I think. Personally, I would name an "analog" I2C interconnect device operating at the physical layer repeater in contrast to a switch operating at the logical protocol layer.

 

[Sink0]

You could make it with external FETs. If you have space o n your board and you need it real fast....

 

[Yuphone]

Wow, Brother UP had been here.