First thanks for the answers to questions already posted about the TLK2711 - a great help. I have some other questions.
1. What does the TLK2711 transmit when an invalid K-code is entered into the TXD[15:0] inputs with TKLSB and or TKMSB set high indicating a K-code. For example what will it send when K15.0 is entered i.e. TXD[7:0] = 000 01111 and TKLSB is 1.
2. It is unclear what the receiver will do when it receives a comma with negative disparity. The TLK2711-SP data sheet states that the data corresponding to the comma codes should only be present on RXD[15:8] or RXD[7:0] when the comma code has positive disparity, i.e. previous running disparity is negative, see note under Table 4 “(1) Should only be present on RXD0-RXD7 when in running disparity <0". It does not mention what is present on RXD[15:8] or RXD[7:0] when the comma code has negative disparity (i.e. previous running disparity is positive). I assume that this note is misleading and that the K28.1, K28.5 and K28.7 code will appear on the output of the receiver, regardless of the previous running disparity. It is only symbol synchronisation that will not occur if one of these three codes is received with negative disparity (previous running disparity positive).
3. The data sheet states on page 9 just above table 3, “An error detected on either byte, including K codes not in table 4, causes that byte only to indicate a K.0.0 code on the RKxSB and associated data pins, where K0.0 is known to be an invalid 8B/10B code. What other errors are detected? Is it just invalid K codes, or are invalid running disparities reported i.e. running disparity in the receiver is something other than +1 or -1? Are there any other receiver errors that are detected?
4. Referring to the Power-Down Mode on Page 10. Can you confirm that RKMSB is not tri-stated in the Power-Down mode? Is the shutdown current of 3 mA (in the Electrical Characteristics Table) with the TXCLK signal active? If not, what is the shutdown current when TXCLK is active (TXCLK need to be active to perform signal detection in power-down mode)?
5. When PRBSEN =1, what appears on the RXD[15:0] and RKMSB signals? RKLSB is used to monitor the results of the PRBS test.
Thanks for your help.
Steve,
Just to clarify, the device in question is TLK2711-SP. Is this correct?
Thanks,
-Atul
Steve, could you indicate what device you are using? The TLK2711A, or the TLK2711-SP. You mention both.
This will determine which group will help answer questions. Both devices are functionally equivalent.
Wade
Hi,
I am using the TLK2711-SP and I would also like to know what is transmitted when an invalid K-code is used.
Is there any info available?
Thanks
Dave
Dave, an invalid K code will decode as a K0.0 on the RX byte.
See datasheet page 9.
The valid K codes the TLK2711; decodes are provided in Table 4. An error detected on either byte, including K codes not inTable 4, causes that byte only to indicate a K0.0 code on the RKxSB and associated data pins, where K0.0 isknown to be an invalid 8-bit/10-bit code. A loss of input signal causes a K31.7 code to be presented on bothbytes, where K31.7 is also known to be an invalid 8-bit/10-bit code.
Regards,
Thanks Wade,
That does explain what the WizardLink receiver will do if it receives corrupted bytes or invalid K codes.
Do you know what happens if one of the non-supported control codes is loaded into the transmitter.
Does it transmit the invalid K code and then the receiver at the other end reports K0.0, or does it transmit K0.0 which the receiver also reports as K0.0?
Regards
Good question.
I have just taken a look at the verilog code for the device. If I am interpreting correctly, the 5/6b portion of the invalid code will translate to all 0's.
The 3b/4b version will translate as if was normal K code.
For example an invalid Kxx.1 code will transmit as 000000 0110 or 000000 1001 depending on current running disparity. Both of these will get decoded as invalid K codes on the RX.
Where xx is any invalid K code (not 28,23,27,29 or 30)
Thanks for the reply it was helpful.
I have been investigating a small error rate in some equipment and wanted to determine at what point in the link the error occured.
Independantly it has been determined that the error rate is dependant on the rise time of the input clock signal at the WizaerLink transmitter.
There is not a data to clock setup or hold time issue.
In the data sheet the input clock rise time is only specified as 1ns typical. Is there any more information about the rise time limits?
Dave, more important than rise time, is the jitter. Slower rise time will imply more jitter.
What is your jitter on TXCLK? The datasheet has a fairly stringent 40ps pk-pk specification.
Dear Wade,
You mention that the jitter is very important. What will actually happen if the jitter is above the 40ps pk-pk? What kind of error shall we expect on the Tx side or on the Rx side?
In which cases can the TLK2711 go out of sync ?
Thank you very much.
Olivier
Increased jitter on TXCLK will decrease the eye opening of the transmitted data. Smaller eye opening will result in higher BER.
Frequency of the jitter is also very important. Jitter in the range of 100khz to several Mhz is most detrimental. Slower jitter will be tracked out, and faster jitter will get attenuated.
Are you using the -SP device or the commercial TLK2711A?
Thank you very much, Wade.
We are using the -SP device. Are there differences between the two versions?
Do you have any typical values for the eye diagram of the TXP and TXN signals?
Cheers.
Oliver, the two device are functionally the same device. They are processed from different wafer fabrication sites and testing flows may be somewhat different between the two devices.
The TLK2711-SP has the serial data total jitter (peak to peak) specified with a typical output from the transceiver as 0.28UI. This implies that if all the appropriate input conditions are met. Ie, TXCLK jitter < 40ps, <100mv pwr/gnd noise, then only 0.28 (or 28%) of the unit interval will be consumed by jitter.
There are several documents that may help.
This is for different device in the same family. The curves are representative for both.
www.ti.com/lit/an/slla149/slla149.pdf
And
http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=SLLA071
Relative to this app note, a discussion on interpretation on the forums is here.
http://e2e.ti.com/support/interface/high_speed_interface/f/138/t/94228.aspx
I would like to clarify few points again regarding the TLK2711-SP:
1) Do the outputs DINRXN and DINRXP need to be twisted or are two 50Ohm cables enough?
2) Does the PRE mode needs to be ON on both sides or only only the Tx side?
3) Using the device as Tx, is this correct to connect the following signals as such:
-- LOOPEN/LCKREFN/TESTEN/TKMSB pulled down via 1K
-- TKLSB pulled up (2V5) via 1K
-- ENABLE/PRE go to an FPGA
-- The RX signals are not used and left open.
-- The 2V5 dig is connected to a 2V5 supply via a 1µH inductor and the 2V5 ana is connected to the 2V5 dig via another 1µH inductor (so to say 2V5 ana goes through 2 1µH inductor)
4) The Rx side is connected as follow:
-- TESTEN/TKMSB/TKLSB/PRE is connected to GND
-- LCKREFN is connected to 2V5
-- GTX_CLK/LOOPEN/ENABLE come/go to an FPGA
-- DINRXP and DINRXN are implemented with 1nF series capacitors
-- The other TX signals are not used and left open.
Sorry for asking too much but we are in a trouble shooting situation.
Thank you very much!
Olivier,
It might be better to have a discussion on what issues you are having, and how you are handling byte alignment.
What symptoms do you have?
Have you read this app note? It cover synchronization. http://www.ti.com/litv/pdf/sgla001a
If necessary we can arrange a conference call to discuss. You can email me at : w a d e v b @ t i dot com.
Just remove the spaces and change the dot.
Thank you Wade, that's good idea. I will talk to my team and we will prepare a summary of the current situation. I will the get back to you.
In the meantime, can you tell me if the GTX_CLK signal is need in Rx mode? What is it doing?
Cheers