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.

Question about TLK3134 PRBS/high/low/mixed frequency test modes

Other Parts Discussed in Thread: TLK3134

I'm trying to use the PRBS and high/low/mixed frequency verification features on the TLK3134 to perform BER testing on my system.  I have a verified operating hardware platform that is able to successfully receive multi-gigabit 8B10B signals from our source (a custom IC) using the TLK3134.  The custom IC implements test modes that allow system 8B10B data to be replaced with test waveform outputs that should be compatible with the TLK3134 verification features.  We'd like to use the verification features on the 3134 to run long duration BER tests to help quantify the error rates of the system.

I've enabled the PRBS waveform output on our device, and enabled the 3134 PRBS verification logic per the notes in the 3134 datasheet (section 3.4, "PRBS Test Generation and Verification Procedures").  When I read register 29 the first time, I see the expected 0xFFFD default value.  Subsequent reads show 0xFFFF, as if the verifier is seeing errors and constantly saturating.  I believe I have the registers set according to section 3.4, and have performed the datapath reset that's included in the sequence.

Does the verifier work if the chip is not being used with a loopback cable (i.e. if the source of the PRBS signal is something other than the 3134 transmitter)?  Is there any documentation on the exact bit sequence the verifier is expecting ("PRBS7" is specified, but a document showing the exact bit sequence required would be good so that I can verify the sequence our device produces).  Are there any other registers that need to be set up that aren't documented in the section 3.4 discussion?  Does the verifier attempt to sync up with the incoming signal by performing a bit crawl or search on the incoming stream?  If not, is there some requirement to sync the verifier with the source signal?

Also, I've attempted to use the low-frequency pattern verifier by setting register 16 bits 3..0 to 1001 binary, enabling the low-frequency pattern output on my test device, and checking register 21.  In this case, register 21 remains 0, apparently indicating that the 3134 is not synchronized to the input test pattern.  Reading error count register 22 gives a constant 0xFFFD value (the default never changes).  Is there a requirement to sync the low frequency signal to the verifier, or is this automatic?

Any additional documentation on the verification features would be appreciated.

  • Hi,

    The verifier does work if the chip is not being used as the generator, PRBS is a standard pattern that the TLK3134 accepts. The TLK3134 only accepts 27-1 and 223-1 patterns though as defined in section 3.4 of the data sheet. One things that you could check is to see that the PRBS you are sending is not the inverse to what the TLK3134 is expecting? I do not know of any documentation that exists that explains the exact bit sequence that the verifier is expecting I will have to check on that for you. I have to do some more research with the datasheet and possibly the EVM to verify some of the other questions for you. I will post back here when I have more information.

    Regards,

    Mike

  • Hi,

    Are you using a TLK3134 EVM or did you spin a custom board for the TLK3134 device to use in your system? How are you communicating with the TLK3134? When you say that you are writing to register 16 (Decimal) are writing to register 10 (Hex)? We have some documentation that can help explain communicating with TLK3134 as it can be confusing sometimes. The document is attached below:

    3757.TLK3134 and Sonic MDIO Supplemental App Note Rev0_2.pdf

    There is a bit in the 0x9002 register that can be manipulated so that the polarity of the RXP and RXN is inverted. Try to swap that bit to see if it is a polarity issue. Another potential area for concern is the clocking. What data rate are you running and is your input clock configured correctly for this data rate?

    Regards,

    Mike

  • Hi Mike,

    I'm using a custom-designed board, not the EVM.  I have both bit I/O connections (to pins like ST and PRBS_EN) plus an MDIO serial interface.  The pins are controllable but I've not been using them to control the 3134's behavior: all the initialization has been over MDIO (that is, I'm leaving ST high and PRBS_EN low and controlling things lik the PRBS verifier by writing to the register).  I'm using clause 22 addressing.  I have readback working, so I can verify that writes are taking place and the data is correct (the board does correctly receive 8B10B data and we've done a significant amount of data collection from the source device).  So I think my control interface to the 3134 is solid. 

    The data rate is 1.6 Gbps.

    I'll try the invert option and see if that helps.

  • Hi, 

    Were you able to determine the cause of the problem with the verifier yet?

    Regards,

    Mike

  • Yes, I was able to resolve the issue: the problem is apparently caused by having comma alignment (register 0x9002 bits 5..4 for channel 0) enabled.  My default initialization for the 3134 turns comma alignment on, because I need it to acquire the normal 8B10B data, but this apparently interferes with the PRBS verifier (I presume because the aligner sits in front of the verifier in the pipeline and the aligner is shifting the input data looking for alignment, causing the verifier to fail).

    Inversion is not required, the 3134 liked our PRBS sequence as soon as the alignment was disabled.

    Thanks for the help.