FPGA to switch output ports

[stan001]

I'm a complete noob in FPGA, did a lot of readings recently and was wondering if this is possible for a FPGA, to use as a wire selector for different protocol on a fix 4 pins output port on RJ45 pins.

The output have 4 pins each x 8 = 32 pins on the 4x2 RJ45 connectors.

What I wanted to achieve is based on the ADDR1-4 pins from the MCU, it will connect the A1-4 or B1-4 ( up to 8 output ) to different protocol like I2C1, IC2C, SPI or UART ..

Is this something possible to be done using a FPGA ??




Output ports, 4x2 RJ45 :-
[url=https://www.rj45-modularjack.com/sale-11206289-rjsne-5381-08-stacked-rj45-4x2-port-ethernet-shield-right-angle-lpje108xagnl.html]https://www.rj45-modularjack.com/sale-11206289-rjsne-5381-08-stacked-rj45-4x2-port-ethernet-shield-right-angle-lpje108xagnl.html

4 of the 8 pins are used as data pins, the balance 4 pins are used as power pins.

[rstofer]

Sure, it seems simple enough but it's not clear to me which direction the device is controlling.  I guess the question is: Who is the master and who is the slave?

Have you considered a need for control signals on the A1..4 ports?  Data Available, Transaction Complete, that kind of thing.  Are these ports used for different protocols simultaneously?

A sort of Truth Table describing what the Addr1..4 signals are supposed to do would help.  Remember, I2C, in particular, is a master/slave arrangement that allows for multiple masters.  If something comes in on I2C how is the address field and R/W' signal going to be handled.

I think it's going to be messy because you don't have control signals.  Maybe there is some room in the Addr1..4 signals to select between data from/to the port and control to/from the port.

Electrically, this is no big deal but you need to spend a lot more time detailing what you expect to happen.

[rstofer]

If you want to forward a protocol, say I2C to the A1..A4 port (using just two pins) and decode the I2C somewhere else then this project got a whole lot easier.  In fact, it is just some glorified multiplexor.  It doesn't need to understand any of the protocols, just switch some connections around.

[asmi]

Why use FPGA in the first place? There are plenty of analog switch ICs which will do what you want.

[NorthGuy]

UART no problem.

SPI is fine, except if the output is on the master side there will be some delays through FPGA which will limit slave transmission speed somehow.

I2C, you can re-transmit, but you cannot connect. This is because I2C devices have open drain outputs pulled up by a common resistor.

Of course, you don't need FPGA to mux the lines. You can use an analog mux, such as CD4053B, to mux just about anything.

[stan001]

UART no problem.

SPI is fine, except if the output is on the master side there will be some delays through FPGA which will limit slave transmission speed somehow.

I2C, you can re-transmit, but you cannot connect. This is because I2C devices have open drain outputs pulled up by a common resistor.

Of course, you don't need FPGA to mux the lines. You can use an analog mux, such as CD4053B, to mux just about anything.

Thanks for pointing out that the I2C with a common pull-up resistors cannot go thought the FPGA ...

[stan001]

Why use FPGA in the first place? There are plenty of analog switch ICs which will do what you want.

Yes, initially I wanted to do auto-detect of comms protocol, but for a first FPGA project, it is too complicated for me... haha

I will look into analog switch IC for this too, thanks

[NiHaoMike]

Thanks for pointing out that the I2C with a common pull-up resistors cannot go thought the FPGA ...

Actually, they can, but you have to implement a state machine so it would be able to switch the direction of the forwarding as needed. It's surprisingly complex to get it right.

Apart from the suggestion of using an analog switch, some microcontrollers (most notably some newer PICs and the Cypress PSOC) have very flexible pin muxing built in. A few PICs even have some programmable logic blocks, basically the start of the convergence of FPGA and microcontroller. I predict that we'll eventually see the line between high end microcontrollers and low end FPGAs blur as multiple devices that combine a few microcontroller cores with a little programmable logic become common on the market.

[NorthGuy]

Actually, they can, but you have to implement a state machine so it would be able to switch the direction of the forwarding as needed. It's surprisingly complex to get it right.

The situation where both sides pull low cannot be modelled with directional forwarding.  For example, master pulls SCL low - you see this and pull the slave's SCL low. Slave decides to stretch the clock and pulls SCL low too. But you don't see this because slave's SCL is already low. Thus you cannot pass this to the master's side. When master releases the SCL, it will see its SCL go up.

[BrianHG]

A few dual 4x analog mux/switch like 74HC4052 or 8x1 74HC4051 would be my pick.

Yes I have done this before in FPGA, however, the FPGA was also the master I2C/MSOI and it knew when to switch the direction of the I2C data line when I2C was in use.

[Foxxz]

Today on Foxxz's "how to solve a problem badly"...

Could you do something like this to deal with I2C without much logic in the way of the FPGA? Assign the pins to be pullups or just use a pullup on the lines?

[FenTiger]

Use tristate IOs. Tie the data pin low and drive the tristate enable.

[NiHaoMike]

The situation where both sides pull low cannot be modelled with directional forwarding.  For example, master pulls SCL low - you see this and pull the slave's SCL low. Slave decides to stretch the clock and pulls SCL low too. But you don't see this because slave's SCL is already low. Thus you cannot pass this to the master's side. When master releases the SCL, it will see its SCL go up.

There are ASICs doing just that, I forgot exactly how they dealt with that problem.

Probably easier to just implement a master I2C controller in the FPGA and control that over SPI.