TLK10031: Looks like the device is not functioning

Hi Omri,

Have you tried enabling PRBS data generation with this device?  If so, can you confirm that the data rate of the output meets your expectations for 10G-KR.

You may need to set the LS and HS PLL multipliers in order to meet your application.  I think this would be 10 and 16.5 for LS and HS respectively.

I've also attached a procedure for the TLK10232 for reference.  It may be useful to cross-reference for additional bring 2185.tlk10232_BringupProcedures_v2 (1).pdfup steps.

Thanks,

Drew

Hi Drew,

Thx for you answer.

I already changed the multiplier of the HS side to be 16.5, 10 is the default for the LS side.

Regarding the PRBS test, activating it for HS side is done by writing 1 to bits 12, 13, and 3 of 0x1E.000B, and bits 0, 7, 8 of same register for the LS side, and that's it? when I'm doing it, can I read the result from some register, or I must either read the output of PRBS_PASS pin or to measure the frequency by scope? I don't see any change in the status or counters registers.

I saw in the the tlk10031 doc that is say "Test Pattern Selection. Refer to TLK10031 Bringup Procedure (a separate document)
(RXG) for more information". Can you send me please this specific document of the TLK10031? In the 10232 bringup procedures doc, it talk only about AN enabled when using 10G KR mode, why is that?

Thanks

Omri

Hi Drew,

It seems that we have a more basic problem.

The PLL on the TLK is not locked not on the HS and not on the LS.

Please find some measurements done in our lab:

POWER:

• 1V - good
• 1.5V - good

GPIOs:

• LOSA - 0
• PDTRXA - 1
• PRBSEN - 0
• ST - 0
• MODE_SEL - 0
• PRTAD - 10001
• RESET_N - 1
• TESTEN - 0
• GPIO - 0

Footprint and Symbol – Correct

REFCLK: 156.25MHz – good. (I changed the clock format from LVDS to LVPECL for testing, and the result is the same…)

We also reviewed the multipliers configuration you suggested and we still see the HS data rate to be 312.5Mbps.

CHANNEL_STATUS_1 Register value is always 0x0.

Maybe this can give you some hint .

Please advise.

Thanks.

Hi,

I'm looking into this and will get back to you with an update tomorrow.

Thanks,

Drew

Hi,

The GPIO values you shared look appropriate.

CHANNEL_STATUS_1 = 0x0000 does indicate that you are receiving a HS signal (HS_LOS = 0), but it seems strange that you do not have PLL lock.  I assume your configuration is the same as before with XAUI on LS and 10G-KR on HS?  Have you verified that the LS and HS signals are the expected data rate and have a reasonable eye opening?

Also, could you verify that your MDIO access to the device is working as expected?  You could achieve this by powering on the device, reading some register values, and comparing them to the defaults in the datasheet.  Primarily questioning this since you read 0x0000.

Additionally, please note that the device must be held in reset after power up.

Thanks,
Drew

Hi Drew,

Yes, we have XAUI on LS and 10G-KR on HS. HS input data rate is correct, but output data rate is 312.5Mbps as mentioned above. We didn't check LS side.

The device is held in reset after power up and after de-asserting RESET_N the MDIO access is working fine, we do see the defaults in registers (e.g. 1E.0000 is 0x610). CHANNEL_STATUS_1 remains 0x0000 even if we shutdown the HS remote side, so I assume we cannot rely on the HS_LOS indicator until we achieve lock on PLL.

Are there any other relevant signals that we can check to rule out HW misconfiguration?

Thanks,

Adrian

Hi Adrian,

Thanks for the update.  This seems particularly odd.  I would expect that after configuring the appropriate clock multipliers, you should see PLL lock.  Are you configuring the clock multipliers?  Are you doing any additional configuration?

Thanks,

Drew

Hi,

Please correct me if I'm wrong, but I would have expected that even without any additional configuration to still get to PLL locked, as 156.25MHz frequency is the default one (e.g. REFCLK_FREQ_SEL_0). Even so we do configure the HS_PLL_MULT to 16.5x, without any effect on the locked status or data rate.

Thanks,

Adrian

Hi Adrian,

Adrian Nicolau said:

Please correct me if I'm wrong, but I would have expected that even without any additional configuration to still get to PLL locked

I believe you are correct.  I had incorrectly assumed that this was more similar to a "CDR lock" status instead of just a PLL lock.

It seems like there is a really basic issue we are overlooking if the PLL cannot lock to the REFCLK.  Is REFCLK_SEL selecting the appropriate REFCLK?  Do you have measurements of REFCLK that you can share?  Are you able to share a schematic as well?

Thanks,
Drew

Hi Adrian,

Glad you were able to resolve this issue!  I will mark this thread as resolved.

Thanks,
Drew