08-20-2018 04:55 AM
I am designing a PHY for PON applications in 10Gbps data rate. I am using GTY transceivers and also I am using the BCDR quick lock circuit, that is presented in XAPP1252. My FPGA is a XCVU125 Virtex Ultrascale device and I am working in Vivado v2017.4.
I have implemented a design and I have used a single patch cord, to connect the transmitter of the SFP back to the reception. The transmitter sends a very long preamble of 0x5555... and then goes off (sending 0x0000....). By probing different nodes of the design, I have found that the BCDR circuit requires about 18ms to achieve a clock and data recovery. Definitely, this is a "long" time, and I want to minimize this time as much as possible.
Also I have probed the DRP port, and I have seen that the circuit does not send any command - or data into the transceiver.
So, I think that the circuit does not operate at all. Have you got any suggestions please?
My GTY instances came from the wizard with the above configuration. I am using 64b/66b Asynchronous Gearbox with 32 bit datapath.
Is any chance that the DRP port is disabled with this configuration? I have tried to change stepSize, threshold and waitTime values, but the lock time gets worse.
Any suggestions please?
Thank you in advance.
08-21-2018 12:43 AM
Two comments (that may or may not help) :
1. SFPs are (by definition) AC coupled. Sending a very long string of zeros may not do what you expect.
2. The average transition density for most self-clocked serial protocols is about 25%, and CDRs are designed to work well with this. Your test pattern "preamble" (5555) has a transition density of 50%, double the usual amount. I'm not sure whether that will make a difference in practice.
08-21-2018 12:51 AM
did you connect everything as Figure 16?
08-30-2018 07:52 AM
I believe one of the features of the PON protocols is that they have a synchronous reference clock that is a reference clock is shared between the transmitter and receiver. It doesn't sound like you have this. Is this the case? If not you might have better success with just locking to the reference clock and using the oversampling.