UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor
Contributor
6,415 Views
Registered: ‎03-27-2014

Questions about buffer in the gtx

Hello everyone,

 

 

I have some questions about buffer in the gtx.

I think if you use the rx buffer,you must use the clock correction code in the protocol. But for the txbuffer,Nobody inserts the clock error correction code and the txbuffer is not an elastic buffer as the rx buffer.so the txbuffer is bound to overflow or uderflow, if i the reset txbuffer, data txbuffer will be lost and the transport would lost data.It seems not a correct way.

 

My question is :

1.If gtx use the rxbuffer, it must use a clock error correction code in the protocol, right?

2.Why tx buffer is not an elastic buffer?

Thanks for you help!

 

Best wishes

lan

0 Kudos
2 Replies
Historian
Historian
6,357 Views
Registered: ‎01-23-2009

Re: Questions about buffer in the gtx

I think if you use the rx buffer,you must use the clock correction code in the protocol.

 

This isn't really right...

 

Lets start with the TX side first - its easier...

 

The GTX gets a reference clock on its dedicated pins. It uses this clock for its PLLs (either CPLL or QPLL) and dividers to generate a bit clock. This bit clock is the transmission clock of the high speed serializer. The serializer takes data from a parallel domain that runs at 1/16 or 1/20 of the bit clock (depending on whether 8b10b is used). This is referred to as XCLK in some documumentation. It is also (usually) the clock that is provided on TXOUTCLK.

 

Generally the user provides data to the TX side of the GTX on a buffered version of TXOUTCLK - this is provided back to the GTX as TXUSRCLK. This has exactly the same bit rate as XCLK, but has an unknown phase (due to the BUFG and the routing). The TX elastic buffer provides an easy mechanims of transferring data from the user domain to the XCLK domain. However, it is not necessary - for low latency operation, the TX elastic buffer can be bypassed, as long as you enable the calibration step, which uses some DLL like circuit to phase match XCLK to TXUSRCLK. Nothing in this process has anything to do with rate matching - the rates are always matched.

 

On the RX side, we have much the same thing; the GTX provides RXOUTCLK, which is used by the user design and provided back as RXUSRCLK. However, things get more complicated here. RXOUTCLK can be a number of things...

 

In the case of the RX the high speed receiver - by definition - runs at the recovered clock. This will be close to the frequency of the PLL, but will not be locked to it - in fact it is locked to the clock of the device sending the data (the device on the other side of the link). The XCLK in the RX is /16 or /20 of this recovered clock.

 

One option for RXOUTCLK (and hence RXUSRCLK) is to use the recovered clock. In this case, XCLK and RXUSRCLK are frequency locked, and no rate matching is required. Again, the RX elastic buffer is used to do the clock crossing between them, and, for low latency applications and with calibration, the elastic buffer can be bypassed.

 

However, another option for RXOUTCLK is to use something derived locally (from the PLL of the GTX). This has the advantage of not having the jitter from the link, and also always being present and stable, even when there is no link. When you do this, though, RXOUTCLK (and hence RXUSRCLK) are not frequency locked with XCLK. This means that over time, there will be either more or less data than one word per RXUSRCLK; this would result in overflow or underflow of the elastic buffer. In this clocking mechanism, the only way to avoid the over/underflow is to have a protocol that allows rate matching (called clock correction in the Xilinx documentation). This allows for the insertion or deletion of identifiable "IDLE" characters from the incoming sequence to match the data rate to the RXUSRCLK rate. In this case, you must use the elastic buffer - you cannot bypass it.

 

Avrum

 

 

0 Kudos
Visitor bubbleboy
Visitor
422 Views
Registered: ‎08-05-2016

Re: Questions about buffer in the gtx


@avrumw wrote:

I think if you use the rx buffer,you must use the clock correction code in the protocol.

 

In the case of the RX the high speed receiver - by definition - runs at the recovered clock. This will be close to the frequency of the PLL, but will not be locked to it - in fact it is locked to the clock of the device sending the data (the device on the other side of the link). The XCLK in the RX is /16 or /20 of this recovered clock.

 


@avrumw Just had a question with regards to your statement that the recovered clock will be locked to the TX clock , but according to ftp://ftp.ni.com/evaluation/HighSpeedSerial_WP_Final.pdf ( under Clock Correction Characters Chapter ) . It seems that the function of a RX elastic buffer is to make sure that the recovered clock is locked with the Tx clock.

So I am a bit confused about the use of the RX elastic buffer. 

Appreciate any thoughts on this 

0 Kudos