--- Quote Start ---
I want to know if it's possible to use the recovered clock to feed the transmitter's reference
--- Quote End ---
It might be possible. You would need to use Quartus to check.
Transceivers have an external reference pin for the transceiver block reference clock (REFCLK). The REFCLK is the transmit clock source, and the initial reference clock for the receiver. When the receiver is initializing, it uses REFCLK to lock the receiver clock-and-data recovery (CDR) unit PLL this is called lock-to-reference (LTR) mode. Then the CDR tries to lock to the incoming data stream this is called lock-to-data (LTD) mode. In the case where all the clocks are synchronous, then the recovered LTD clock has the same frequency as REFCLK, but it has difference phase noise.
What you are asking (if I interpret your question correctly) is whether you can take a clock from the CDR, i.e., the LTD clock, and then use it for the REFCLK input of another transceiver block. I'm not sure that this is possible, it will depend heavily on the FPGA clocking resources. For example, the clock you want needs to route from the CDR onto a global or local clock network, and then back to the REFCLK multiplexing logic on the transceiver block inputs. If you are at the board-design stage, then you could take the CDR clock output off the FPGA to a jitter cleaner PLL, and then route the output of that PLL back to a REFCLK pin. If you look on the SiLabs web site, there is a paper on synchronous Ethernet that discusses this technique.
--- Quote Start ---
I know it can be done through a fPLL but that's very limiting because you can only use one fPLL per bank so you'd only be able to route 2 inputs into 2 outputs (I'm not sure if the outputs have to be on different banks) and I don't know how much is jitter influenced by this.
--- Quote End ---
I've tried something similar with a global clock input. The global clock pin could not be routed to the transceiver REFCLK, but Quartus would allow routing the clock to a PLL and then a PLL output to the REFCLK. Quartus generates a warning about "excessive jitter" for this setup. This was acceptable in the test I was doing. Since you mention an fPLL, you're using a newer device, so there might be a few more clocking options. If Quartus generates warnings about clock jitter, then you probably don't want to accept that method as your final implementation.
In your application, if the input video stream clock is asynchronous relative to the video wall clock, then just buffer a small amount of data before displaying the images over all the destination displays. The only rate difference you have to worry about is the source relative to the destination. If you do the math for the time taken for a one frame difference to accumulate give the ppm errors between clocks, you might find it is quite a long time. If you buffered 1 second of frames, and had enough space for 1 second more in your buffer (in case the source clock is faster than the wall clock), I'm sure it would take a while to overflow or underflow the buffer.
Cheers,
Dave
Honored Contributor
