GTY transceiver simulation, CDR, periodic data error

[upside_down]

I have tried to simulate the behaviour of the GTY transceiver to understand it better, before receiving a VU+ board. My goal is to design a 10G MAC + PCS IP.

I wanted to see what happens if there is a 10G ethernet connection between two different VU+ boards. Obviously, their reference clocks do not have exactly same frequency (even the difference is 0.1ppm, it is not 0). Assume that one GTY transceiver gets 156.250015MHz (thinking it was exactly 156.25MHz) as a reference frequency (MGTREFCLK0), and the other gets 156.249999MHz. Of course the CDR logic should be able to synchronize them properly to avoid high BER due to the phase and frequency mismatch.  

I wanted to simulate this property of GTY transceivers. To do that I instantiated two GTY transceivers from two different quads (let's call them Quad1 and Quad2) using the wizard. The other settings were exactly the same as 10GBASE-R defaults. TX and RX reference clocks were the same (156.25MHz). In testbench I connected the TX port of the transceiver from Quad2, to the RX ports of the transceiver from Quad1 and Quad2. Also I toggled the simulated reference clock of the Quad1 at every 3200000ps (156.25MHz) and that of Quad2 every 3200030ps (156.24853517MHz), of course such a big difference is not practically the case, but I did it to be able to see the behaviour in simulation. When I ran simulation, I got periodic PRBS mismatches and high BER.

•  Is my simulation an overkill?
•  Will such periodic errors occur in real life scenario when the clocks have small enough difference, or will the CDR circuit eliminate the problem?
•  If the answer of the second question is NO what should I do to eliminate the problem?
•  If the answer of the second question is YES how is it eliminated? Is there any documentation or question you can suggest?

If you more information I can provide as soon as I see your comment

Thanks! 

[guozhenp]

GTY has Clock Correction to compensate the different clock rate in 8B10B.

Please read UG578 and search "clock correction" for it.

64B66B is similiar but different. Ethernet protocol use IFG (inter-frame gap) to compensate the clock rates.

Please search "clock compensate" in IEEE802.3, section 4 for it.

If you use Xilinx 10G Ethernet IP core, the IP has already included the clock compensate function.

[upside_down]

@guozhenp  In this example I selected the RXPROGDIVCLK as a source for RXOUTCLK, and later tried my luck with RXOUTCLKPMA (which according to the documentation is a recovered clock) but the result did not change. Can it have a different reason?

[guozhenp]

You will need the "clock compensate" logic to solve the issue.

1. There should be also many IDLE, not only payload data in the data stream. (Ethernet uses IFG) So that you can add/remove IDLEs as you like.

2. There needs a buffer in your RX side logic, e.g buffer write clock 3200030ps and read clock 3200000ps. As the read clock is faster, the buffer will become empty. Then you can add IDLE in your RX data. If the write clock is faster, you can delete ILDE to avoid the buffer becomes full.

[upside_down · Accepted solution]

@guozhenp  Thanks for the reply, I solved the problem now. I used recovered clock of one of the transceivers as a master RXUSRCLK2 for both transceivers instead of using their own (different) corresponding recovered clocks. But your answer helped me to, now I know the importance of clock compensation and will use it.