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.

Pattern dependent receive failures with TLK1501

Other Parts Discussed in Thread: TLK1501

I'm debugging a design that uses four TLK1501s to receive four channels of custom 8B10B data at 660 Mbps/channel.  The transmitter in the system is a custom IC which is capable of generating several different test patterns to transmit via the 8B10B channels. The format of the 8B10B data is a repeating pattern of this following line:

[3 IDLEs (K28.5/D5.6)] [~2000 data symbols with test pattern data] [3 IDLES]

The design works well with certain test patterns but we see receive errors with others.  The errors occur just after the receive of the IDLE and the first couple of data symbols.  At this point, the output data from the 1501 shows a shift and the normal test pattern data is replaced with (generally predictable) erroneous data.  When the 1501 sees the trailing IDLE characters it appear to resync and the data then looks good again.  There appears to be a random chance that the 1501 will produce the erroneous data on each repeat of the line, that is we may see several good lines, then one bad line, then several more good.  When the 1501 outputs erroneous data, it does so for the entire line except for the first two characters after the idle, which are the same for every line output by the device.

The errors only occur with some test patterns, not all.  For example, if I select a ramp test pattern the data is received reliably without error, but if I select certain test patterns that output constant data across the line, these show errors.  Not all constant value test patterns fail, however: it appears to depend on the data being received.

I've attempted to trigger on erroneous data using a serial data analyzer, but have not seen erroneous data on the transmission line.  Data eyes look reasonable and don't appear to change from oen pattern to another.

The transmitters are unused in this system: I have the TXD pins pulled down to ground via a 1K resistor, the TX_EN and TX_ER inputs are floating (pulled down internally per the datasheet), and the DOUTTXx pins are floating.

Does the apparent pattern dependence suggest a possible cause for this problem?

  • One additional piece of information that may be important: the custom IC we're using as a data source has an apparent bug in its running disparity generator.  The 1501 flags the errors, and we've seen separate confirmation of the running disparity errors from two different serial analyzer scopes.

    Could the disparity errors cause decoding failures in the 1501? 

  • Hi,

    It sounds like you might have found your answer in the running disparity. If the words received by TLK1501 have an invalid running disparity, they are considered invalid words and marked as errors (RX_DV = RX_ER = 1).  If it receives four invalid codes, the TLK1501’s channel synchronization state machine (shown on p. 12 of the datasheet) will transition back to the reset state (ACQ) to try to re-align itself to the correct word boundaries. This means that it won’t be able to output any valid data until it achieves synchronization again (through comma detection or through detection of consistently valid data). I hope this helps and please let me know if you have any more question or if there problem still persists.

    Regards,

    Mike