FPGA work as bridge I2C in, out issue
In I2C communication, open collector drivers are used. The protocol depends on the level on the line being the 'wire-OR' of all the drivers.

This means that, on a local interface, a pin may be low because it is being pulled low by a remote driver, or it's being pulled low by itself.

Obviously any buffer between that sits between this interface and the remote ones must be able to distinguish why the line is low. If it's low because a remote is pulling it low, then it too must pull low to transmit that. If it's low because the local driver is pulling it low, then it must not, otherwise the line would get stuck low, and nothing more would happen.

Various strategies are used by vendors of (for instance) opto isolators designed for I2C. Their output pulls low to a different level to the typical local interface, and voltage sensors can distinguish which driver is pulling it low. But it's all rather flaky and depends on the local driver having 'typical' good performance.

As an I2C bus is designed to be bus connected, by far the best way to connect the FPGA to the bus is to implement an input and an o/c driver for each of the two pins, and connect to the two I2C bus wires. This retains the direct connection of all the items already on the bus. The minimal programming so that the FPGA does not disrupt bus traffic is to not drive the o/c outputs. To participate in bus traffic will require an I2C protocol stack in the FPGA.

A robust way to break the path through the FPGA is to implement two I2C stacks in the FPGA, one facing each way, to relay messages. While this may seem quite a heavy option, I2C interfaces are available as pre-written IP for FPGAs, and it eliminates the flakiness of trying to implement a dumb pass-through.