This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TLK3101 rx_er's happening.

On my application, several packages  of data moves on the differential buses from senter to receiver. But errores takes on the pins, for the sake of  both the tx_en and rx_er signals going high, receiver propagation error. That made troubles to my controller, and Some abondon packages can not meet my requirement. Therefor, How can I reduce or elimate the rate of errors?

  • Hi Tom,

    Please provide more information about your application so that we can figure out where the problem is. Please provide the following information:

    1. Do you have the TLK3101 devices on both sides of your link?

    2. What kind of medium connects the transmitter and the receiver? Is it a cable or a pcb trace? How long?

    3. At what data rate are you operating the devices?

    4. What kind of data are you sending across the link?

  • 1.Right, I do use TLK3101 on the both sides.

    2.A fibre laser transceiver which meets the demond of TLK3101.

    3.At present, 125MHz is the data rate. But we are going to increase it to 155MHz in the furture.

    4.A package composes of one data head(16-bit) and 28 valid data(16-bit).

  • Hi Tom,

    Thanks for the info. I understand that you are running your optical fiber link at 2.5Gbps serial data rate with a 125MHz reference clock. Please provide the settings for LOOPEN, PRBSEN, TX_EN and TX_ER pins on the transmitter-side TLK3101 device. Please confirm if you're sending out IDLE characters as expected before sending out the data? Specifically, what is the composition of the header?

    How long is the pcb trace from the optical transceiver to the TLK3101 device on both sides of the link? Is it possible to provide a scope capture of the signal close to the transmitter-side TLK3101 DOUTTXP/DOUTXN pins and receiver-side TLK3101 DINRXP/DINRXN pins?

    Best regards.

    HA.

  • It seems that this post is a few months old, but I am experiencing the same problems as Tom. This is our setup:
    We are using the TLK 3101 to interface with a fiber receiver - AVAGO AFBR-57R5AEZ. This is the same on both the sender and the receiver. We are sending 16bits of data at 125MHz. reference clock. or 2.5Gbps serial rate. The fibers we are using are MM 50/125um and are 7ft long. LOOPEN and PRBSEN are both tied to ground. The TX_ER is tied to ground and the TX_EN is used as expected, high when data is present, low for IDLE. Three IDLE clocks are sent before data is sent. There are random high RX_ER signals on the receiver TLK and sometimes they are so frequent that SYNC is lost.

    The pcb traces are about one inch long. We use a system wide clock for both receiver and transmitter of 125MHz.

    Has there been any update to this in the past few months?

  • Hi Craig,

    You seem to have correct TLK3101 device configuration. 3 IDLEs is the minimum required to achieve sync. I'd suggest you send more IDLEs and see if that makes any difference.

    For such short PCB traces, the link should have huge operating margins both in voltage and jitter. Have you probed the electrical signal into the TLK3101? if it is bad in signal integrity terms, then that may possibly be due to any of the following three factors:

    1. Incorrect receiver terminations: Both the TLK3101 and the AVAGO module do not need external receiver terminations as they already have internal 100ohm differential terminations.

    2. High reference clock jitter: Using a common clock for the entire system is good but it has to be clean enough. The general reference clock jitter spec for the TLK3101 device is 40ps peak-to-peak. Depeding upon the jitter frequency, the device can handle much higher clock jitter than the specified number.

    3. Signal integrity issues: If the electrical link between the TLK3101 and the optical module is not well impedance-controlled, the signal can be corrupted due to signal reflections and also crosstalk.

    I'd suggest first to use the LOOPEN and perform bit-error tests on the parallel side (in conjuction with a protocol device) to make sure that the problem is indeed on the serial side of the device. I'd also suggest to probe the signals on the serial link pins on both the optical module connector and the TLK3101 to confirm signal integrity issues. Please also make sure that the clock is clean.

    Best regards.

    Hassan.