TLK1501 end point jitter question

Hi Jim,

The required setup time for the data prior to the RX_CLK is 5.5ns, so RX_CLK jitter should not come anywhere close to affecting the data latency. The RX_CLK phase will be able to track wander of the incoming data if there are latency changes through the fiber, and the difference between the RX_CLK phase and the data phase will always be within the setup and hold timing window.

Best regards,

Matt

Matt,

thanks for taking the time to respond.  While I think I understand your response, I think that it doesn't allay my fears about this current application.

First, I guess I was more interested in jitter numbers that were presented here:

http://www.ti.com/lit/an/scaa064/scaa064.pdf

Maybe there is no way to get the jitter #s other than to put things physically together and measure them, but I thought there could be a way for me to figure it out from the datasheet. 

To restate the problem:

0)data source > TLK1501 transmitter > fiber > TLK1501 receivers > DAC
1)data source > TLK1501 transmitter > fiber > TLK1501 receivers > DAC
....
7)data source > TLK1501 transmitter > fiber > TLK1501 receivers > DAC

Since jitter in my clock at my DACs will cause error in the output of my DACs, I need to know how much jitter I can expect in RX_CLK and between RX_CLKs.

Thanks

Hi Jim,

This app note for the CDCVF2310 and CDCVF25081 is to show that these two clocking devices can meet the 40ps pk-pk jitter requirement for the TLK1501 reference clock input. The RX_CLK output from the TLK1501 device is recovered from the data stream and data from the TLK1501 RXD parallel bus is valid on the rising edge of RX_CLK. This parallel bus runs at maximum of 100MHz (10ns period). From the data in the app note, the worst case pk-pk jitter on the serial data stream from the transmitter was between 100 and 200ps. The parallel data on the RXD pins is guaranteed by the datasheet to be available 5.5ns before the rising edge of RX_CLK, so that should leave plenty of margin.

Am I misunderstanding and is skew between the 8 RX_CLKs the concern? Do all of the DACs need to change their outputs within very tight timing? I think this may be a bigger challenge since the phase for each of the RX_CLKs will be different since RX_CLK is recovered from the data stream.

Best regards,

Matt

Yes, I think that you might be misunderstanding things. 

If we were to think of a perfect reference clock on the receive side. And then we compared the 8 RX_CLKs rising edges to that perfect clock rising edge (every cycle), let's call that difference between rising edges between each of the RX_CLKs and the perfect clock: skew[7:0](cycle). 

I'd want to to have each

skew[0](cycle x)-skew[0](cycle x+1)

skew[1](cycle x)-skew[1](cycle x+1)

skew[2](cycle x)-skew[2](cycle x+1)

...

skew[7](cycle x)-skew[7](cycle x+1) to be a defined number.  I am going to want it to be a small #.

Notice, that I only care about the change from cycle to cycle, therefore I can tolerate different latencies between the 8 different TX to RX paths.  I just need to make sure that those latencies don't change much each cycle.

Thanks

Hi Jim,

What type of cycle to cycle jitter is needed? From the measurements in the app note, the number could theoretically be close to 170ps (this may be a little pessimistic since the measurments in the app notes are peak to peak jitter). Since jitter is the key parameter, would it be an option to run the RX_CLK output to an 8-channel jitter cleaner? This would reduce the cycle to cycle jitter to a few picoseconds if this level of performance is needed.

A couple of options would be: LMK03806 (14 output high performance jitter cleaner) or the CDCE62002 + CDCLVD1208 (2 channel jitter cleaner and 1:8 LVDS buffer).

Matt

Matt,

thank you for the guidance, I think the jitter cleaner/attenuator route will address the issue.

I wanted to ask another question about the TLK1501 regarding the latency (I know I mentioned that this was not an issue earlier, but I might have misspoke and I'd like to understand the TLK1501 better).

The data sheet says:

"The transmit latency is fixed once the link is established. However, due to silicon process variations and implementation variables such as supply voltage and temperature, the exact delay varies slightly. The minimum transmit latency (Tlatency ) is 34 bit times; the maximum is 38 bit times."

"The receive latency is fixed once the link is established. However, due to silicon process variations and implementation variables such as supply voltage and temperature, the exact delay varies slightly. The minimum receive latency (Rlatency) is 76 bit times; the maximum is 107 bit times."

So, in a different case than before,  if I have 2 TLK1501 (together on the same board A, driven off same clk) transmitting data over a fiber and then recovered by 2 TLK1501 (on the same board together on board B), am I correct in assuming that the data will come out of the 2 TLK1501 on different cycles? 

Is there a way to guarantee that the data will come out on the 2 TLK1501 in the same cycle?

Thank you

Hi Jim,

There is not a way to guarantee this between two devices without some external logic to deskew the lanes. The system would need to be able to handle 31 bit times of latency (max value of 107 minus min value of 76) on the high speed side - this translates to a variance of 1.55 parallel clock cycles.

Another option might be to use the TLK2521 which is pin compatible and functionally equivilant to the TLK1501. It has a tighter receiver latency spec (88 to 95 bit times @ 1Gbps) which translates to a variance of 0.35 cycles on the parallel side.

Best regards,

Matt