How to feed rx_dataout back to tx_datain in Cyclone IV GX transceiver?

ORZ, no reply?!

Was my question posted unclear? Pls enlighten me.

--- Quote Start ---

In short, How can I transmit the received data with the recovered clock?

--- Quote End ---

You can add a FIFO between RX_DATAOUT and TX_DATAIN, where each of the input and output is sync'ed to the appropriate clock domain.

The size of the FIFO depends on the maximum difference between input and output clock rates you need to compensate for. If new data arrives and the FIFO is full, you must drop a data word; likewise if you need to transmit data and the FIFO is empty to need to stuff a null word.

Other than that the logic design should be reasonably straightforward.

--- Quote Start ---

You can add a FIFO between RX_DATAOUT and TX_DATAIN, where each of the input and output is sync'ed to the appropriate clock domain.

The size of the FIFO depends on the maximum difference between input and output clock rates you need to compensate for. If new data arrives and the FIFO is full, you must drop a data word; likewise if you need to transmit data and the FIFO is empty to need to stuff a null word.

Other than that the logic design should be reasonably straightforward.

--- Quote End ---

Hello Ak6dn, thank you for your response!

I have already considered this solution. In this case, It means dropping some frames , which is not acceptable in this project.

The transmitted data should be exactly the same as received data.

--- Quote Start ---

Hello Ak6dn, thank you for your response!

I have already considered this solution. In this case, It means dropping some frames , which is not acceptable in this project.

The transmitted data should be exactly the same as received data.

--- Quote End ---

Well, the only way to guarantee that, with independent sources for RX and TX clocks, is to implement an infinite length FIFO. Clearly not practical, or possible.

If you require absolutely a mirror image of the RX input on the TX output then the only alternatives are as follows:

1) guarantee that the REFCLK on the TX side is ALWAYS higher in frequency that the RX clock, so a FIFO would never fill, you can always send data faster than receiving it. A small FIFO would be necessary to handle crossing the clocking boundary, but it would need only be a few locations (eg, 4 or 8).

2) Phase lock the TX clock to the RX clock thru a PLL, so that your TX frequency is IDENTICAL / phase locked to the RX frequency. Then you can just connect the RX and TX data lines together, no FIFO needed, maybe just a pipeline register. Most of the altera PLLs support a clock switchover capability.

--- Quote Start ---

1) guarantee that the REFCLK on the TX side is ALWAYS higher in frequency that the RX clock, so a FIFO would never fill, you can always send data faster than receiving it. A small FIFO would be necessary to handle crossing the clocking boundary, but it would need only be a few locations (eg, 4 or 8).

--- Quote End ---

There is no guarantee that Tx side is always higher, Since the recovered RX clock is beyond my control.

--- Quote Start ---

2) Phase lock the TX clock to the RX clock thru a PLL, so that your TX frequency is IDENTICAL / phase locked to the RX frequency. Then you can just connect the RX and TX data lines together, no FIFO needed, maybe just a pipeline register. Most of the altera PLLs support a clock switchover capability..

--- Quote End ---

Tx clock? Which clock do you mean? if you mean the ref_clk, it should only came from crystal. How am I supposed to do that?

Could you give me some details, or reference about how to do it?

In addition, do you mean there is no way the transceiver could transmit the recovered data with recovered clock all by transceiver itself? I have tried all the clock related parameter setting of transceiver, but no luck. Is there some statement in datasheet describe this? How am I to convince my boss it can't be done all by transceiver itself?

--- Quote Start ---

There is no guarantee that Tx side is always higher, Since the recovered RX clock is beyond my control.

--- Quote End ---

Mostly true, unless you can (not always practical/possible) select a TX clock (ie, ref clk) frequency that is always higher than the highest possible RX clock. The RX clock will not be unbounded; SFP modules don't work that way. The RX will only lock on signals within a specific tolerance, and will go unlocked to a nominal frequency if the input signal is out of range. At least this is my experience with OCx and 10G SFP modules.

This alternative was given in terms of listing possible solutions; it may not be practical in most instances where you cannot generate a TX refclock to be 65/64 (for example) times the RX clock.

--- Quote Start ---

Tx clock? Which clock do you mean? if you mean the ref_clk, it should only came from crystal. How am I supposed to do that?

Could you give me some details, or reference about how to do it?

--- Quote End ---

The TX clock (ref clk in your schematic) may be generated by an external crystal oscillator during normal operation, but when you go into 'loopback mode' you could generate the TX ref clk from the SFP recovered RX clock instead, as a special, diagnostic mode, or as a design feature. Lots of telecom equipment has a feature to lock transmitted data signals to an external reference (ie, like a GPS stratum clock) or in some cases to lock to the timing of an incoming link (as one might do to support synchronous ethernet).

--- Quote Start ---

In addition, do you mean there is no way the transceiver could transmit the recovered data with recovered clock all by transceiver itself? I have tried all the clock related parameter setting of transceiver, but no luck. Is there some statement in datasheet describe this? How am I to convince my boss it can't be done all by transceiver itself?

--- Quote End ---

I have not seen that capability in any SFP module I have ever used. It would require coupling between the electrical TX and RX signal paths. Remote loopback as a diagnostic function usually is done be hairpinning the signal inside the interface SERDES device and wrapping it back around. Hairpinning within the SFP itself is something I have never seen. It is certainly technically possible that it can be done within a module (both electrical side and optical side loopback) but I am just not familiar with any modules that have this capability.