Yes No question (Using FPGA as a wire)

Dear Josyb. You answer is digitally appropriate :)

Could you guide me on this.

Is there an IO buffer in altera like in Xilinx?

Do I need to use Megafunction?

I don't know about Xilinx - wouldn't touch it with a bargepole :)

I use a component in my VHDL code:

	
LIBRARY altera; 
	USE altera.altera_primitives_components.all;
....
odsda : opndrn 
		port map ( 
				a_in	=> dp_SDaOut , 
				a_out	=> Sda
				) ;

Don't know how to do this in Verilog - wouldn't touch that with a bargepole either :)

Not sure that can work for bidirectional data.

Any kind of buffer has to know the data direction.

--- Quote Start ---

Yes, you can

--- Quote End ---

Unfortunately, I have to contradict. All existing physical level I2C repeaters or level converters are based on special hardware features, please review the respective datasheets. A similar function can't be implemented with regular FPGA IOs as far as I understand.

A repeater on a logical protocol level would be possible, but not an easy design.

P.S.:

--- Quote Start ---

Any kind of buffer has to know the data direction.

--- Quote End ---

That's exactly the point.

--- Quote Start ---

Unfortunately, I have to contradict. All existing physical level I2C repeaters or level converters are based on special hardware features, please review the respective datasheets. A similar function can't be implemented with regular FPGA IOs as far as I understand.

A repeater on a logical protocol level would be possible, but not an easy design.

P.S.:

That's exactly the point.

--- Quote End ---

And I have to admit, I was a bit quick. Using cross-connected opendrain IO would create a lock-up loop, i.e. when one of the two SDA is pulled low, the other will be pulled low as well, in its turn pulling ... you see what I mean.

Like you say a protocol solution will be elaborate. But with a dedicated Master Port on one side and a dedicated Slave Port on the other side it may reasonable feasible, because then the direction of the buffers will be predictable. Still a bit of work, though.

Can I do this in two steps?

1- Implement two SDA buffers, one on the left side and one on the right side like normal i2c SDA connection method.

2- Make another block (vhdl/verilog code) that gets SDAs from left side and right side and handles it in a way that my purpose fulfils.

==============================

extra information:

-There is only one master on the left side and

-There is only one slave on the right side.

-Both of them ofc can pull down SDA line.

==============================

Can you easily tell which i2c requests are reads, and which are writes?

If you know that, you might be able to tell at which i2c clock edge to switch the the data line buffer direction.

If the fpga's clock is enough times faster than the i2c clock you might make it work!

These low-wire-count protocols get to be a pain - the worst I've met is the 1-wire (+ground) one used on some battery gauge chips (bq20250 etc).

can you easily tell which i2c requests are reads, and which are writes?

if you know that, you might be able to tell at which i2c clock edge to switch the the data line buffer direction.

Do I really need to know this? If I implement another block that inputs two SDAs coming from the left side and coming from the right side and outputs one SDA that is really the SDA on the board)

if(left_sda or right_SDA is low) => then output SDA on the board is low.

else (In all other cases) => then output SDA on the board is high

--- Quote Start ---

Do I really need to know this? If I implement another block that inputs two SDAs coming from the left side and coming from the right side and outputs one SDA that is really the SDA on the board)

if(left_sda or right_SDA is low) => then output SDA on the board is low.

else (In all other cases) => then output SDA on the board is high

--- Quote End ---

I fear, you didn't yet understand the lock-up problem that has been explained by josyb. The problem can be overcome on the physical protocl level by using different low level, please refer to NXP PCA9515A or similar product datasheets how it can be achieved.

http://www.nxp.com/documents/data_sheet/pca9515a.pdf