11-08-2011 12:55 AM
I am working on a GTP/GTX design in my ML507. I need to set a 8b/10b optical communication, which has to be fully deterministic. I have some problems understanding the operation of the device - especially the CDR and the RX buffer (I have been reading the documentation for a quite long time and things are not getting clear).
I implemented the design using two ML507 boards, one as a TX and the other as RX. The TXUSRCLK is clocked by REFCLK and the RXUSRCLK by RECCLK. I displayed both clocks (TXCLOCK from the transmitter and RXCLOCK from the receiver) in an osciloscope to observe what happens.
The problem: every time I reset the receiver, the RXCLK locks with a different phase compared to TXCLK. The received data is correct (I verify this using the ChipScope), but for my aplication deterministic behaviour in crucial.
I would appreciate any advice about finding the solution to this problem.
11-08-2011 03:26 AM
I found an interesting article about deterministic optical link and now I understand what is happening. It seems that the GTX uses a 20 bit barrel shifter as a part of the serial to parallel conversion process. Data is latched into the barrel shifter on the word clock and then is shifted N positions untill data is lined up properly on a word boundary. Since the position of the barrel shifter is arbitrary when the link is initialized, this constitutes an uknown delay.
This problem may be resolved using the DRP to temporarly unlock the internal PLL and relocking it to a new position; this process should be repeated many times untill the desired barrel shifter position is achieved.
The question is: does anybody know where I can find some information about the DRP addresses for the GTX module? Is this the correct approach? Is it possible to perform such a procedure with the elastic buffer bypassed?
11-09-2011 10:25 AM
I'll try to help you out - I have a couple of questions.
- Are you using oversampling in your design?
- What is your data rate and reference clock frequency?
- When you ask about more information about the DRP addresses, I'm assuming you've already looked at Appendix D in UG198?
11-09-2011 11:11 AM
Thanks for your answer.
I'm working with a line rate of 2 Gb/s, and the reference clock frequency is 100 MHz. I have bypassed the elastic buffer for I need determinism. I am not using the oversampling since I understood that it is intended for lower line rates (im not sure about that).
If I understood well, the serial data from the CDR is converted to 20bit parallel data in the SIPO. The sipo does not care about the alignment, it just packs 20 bits together and sends them to the comma alignment module. The recovered clock from the CDR is also divided, and its alignment is matched to the unaligned parallel data from the SIPO. There is a barrel shifter inside the "Comma detection and alignment" block that performs the comma alignment. That's why the phase of teh recovered (parallel) clock does not mach the phase of the transmitter clock. Im I right?
So what I want to do is to somehow look inside the barrel shifter to know how much is the data "shifted" to correct that delay.
I have read the Appendix D of the UG198, yet It is not clear to me which parameter I need to read from.
I will appreciate any help you'll give me.
11-09-2011 01:16 PM
You are correct in your understanding - oversampling is only needed for low data rates. As far as the phase alignment, you can use RXPMASETPHASE and the instructions on p. 207-209 in UG198 to set up for manual phase alignment. The DRP information relating to the barrel shifter is something you'll need to open a WebCase about, as the exact DRP information you're seeking isn't in the User's Guide. Sorry I couldn't help more.
07-26-2012 05:41 AM
the system I am working ona t the moment is rather similar to the one described above, however I am puzzled what exactly abovementioned Phase alignment does. As per UG196 or UG198 this phase alignment insures SIPO parallel clock to phase match RXUSRCLK, but the phase relationship between the data (comma aligned 16-bits) and RXUSRCLK after this alignment is still not fixed.
To simplify the question. I want my RXRECCLK to be deterministically phase aligned with incoming data, without using any buffers.