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.

  • TI Thinks Resolved

TCI6638K2K: Performing ATT and BOOST Calibration for PCIe Interface

Prodigy 70 points

Replies: 13

Views: 396

Part Number: TCI6638K2K

In Errata: KeyStoneII.BTS_errata_usagenote.28 the work around is to perform ATT/BOOST calibration.

We did this successfully for the SRIO interface but for the PCIe interface I am getting really strange results.

Note PCIe interface does not fail all the time. In fact it fails only with High temperature. We are configured for x1 Lane PCIe @ 5.0 Gpbs.

While PCIe is full active and functional I read the following value of the registers:

COMLANE_1F8 : 0x04010000

LN1_OK : 0x0
LN0_OK : 0x0
LN1_SIG_LEVEL_VALID : 0x0
LN0_SIG_LEVEL_VALID : 0x0
CMU_OK : 0x1

PLL_CTRL : 0x10000002

PLL_ENABLE_VAL : 0x0
PLL_OK : 0x1
LN1_OK_STATE : 0x0
LN0_OK_STATE : 0x0
LN1_SD_STATE : 0x1
LN0_SD_STATE : 0x0


Since we are using lane 0 of PCIe phy, and it is fully up and running I am expecting the LN0 values to be set in the above registers.

Furthermore, when I try to read the value for the ATT and BOOST set in the Serdes, I am not able to RXValid for lane0.  The API is in csl_serdes2.h and I am copying it here:

static inline void CSL_SerdesWaitForRXValidPerLane(uint32_t base_addr,
uint8_t lane_num)
{
uint32_t stat;
uint32_t timeout = 100000000;
stat = (CSL_SerdesReadSelectedTbus(base_addr, lane_num+1, 0x2) & 0x020)>>5;
while ((stat != 1) && (timeout != 0))
{
stat = (CSL_SerdesReadSelectedTbus(base_addr, lane_num+1, 0x2) & 0x020)>>5;
timeout--;
}
}

So it seems that there is something special about the PCIe mode for Serdes that is not covered by the documents. Please help.

Ziad A.

  • Guru 62440 points
    Hi,

    For PCIE Serdes, it is PHY-A 2 lanes (instead of PHY-A 4 lanes). The register you need to look at is Table 16-1. Memory Mapping for PHY-A 2 Lane Sub-Systems in the Serdes user guide.

    However, some registers are the same as those defined in Table 16-2. Memory Mapping for PHY-A 4 Lane Sub-Systems. For the PCIE Serdes, PCIE lane 0 (0-based) is the lane 1 (0-based) in the Serdes, PCIE lane 1 (0-based) is the lane 2 (0-based) in the Serdes.

    That is why you saw LN_1 is active / set when use use PCIE Serdes 0.

    Older CSL code may have bugs in this lane index conversion and there were PCIE diagnostics (BER, ATT/BOOST test) failure. It was fixed around 2018 Q2. Please use the latest PRSDK 5.3 release for K2H for Serdes work.

    Regards, Eric
  • In reply to lding:

    Can you please send a link to download PRSDK 5.3
  • Guru 62440 points

    In reply to user5923610:

    We don't support part number 6638K2K, but this is the same as 66AK2H, software-dl.ti.com/.../index_FDS.html

    Regards, Eric
  • In reply to lding:

    I downloaded the latest CSL and diag. I do not see the changes. Although I see V1 directory, the diagnostic tools still refer to files in V0 (older version) not new one. I am still confused how function: Serdes_Diag_Att_Boost_Calibration in serdes_diag.h refer to the new library. It still calles CSL_SerdesWaitForRXValid which is defined the same way as before.

    Can you also explain why I am not getting Lane1 OK set in COMLANE_1F8 and PLL_CTRL even though the PCIe link is up and running.
  • Guru 62440 points

    In reply to user5923610:

    Hi,

    I created a setup of PCIE x 2 lane test between TI K2H EVM and another device. I knew the PCIE link is operating properly with GEN2 x 2 lanes. I looked at:
    - the CMU (0x2320BF8): 0x0001_0000
    - PL_CTRL (0x2321FF4): 0x1000_0000

    Those values are even different from you case (GEN2 x 1). I agreed that those LNx_OK and LNx_SIG_LEVEL_VALID, LNx_SD_STAT, LNx_OK_STATE bit doesn't give any clear indication.

    I also tried another Serdes PHY-4 (Hyperlink) and looked at above registers and those fields are meaningful.

    The Serdes is provided from a third party with limited information in the document. We may not get further explanation and so we suggest to use the Serdes code inside CSL (called by Processor SDK RTOS) PCIE examples as it is. If there is any issues, we can debug.

    Regards, Eric
  • Guru 62440 points

    In reply to lding:

    Hi,

    For the CSL_SerdesWaitForRXValid(), this function is not changed and it is common for PCIE and other interfaces. What is your question? " I am not able to RXValid for lane0", do you mean you code get stuck when configured as x1 lane? But I thought x1 is working for you.

    For me, x 2 lane worked and PCIE is functioning (judged by pcie_debug0 register 0x2180_1728) it is in L0 state.

    Regards, Eric
  • In reply to lding:

    Attached to the TI I have an FPGA which is driving PRBS31 pattern to the Keystone PCIe interface lane 0.

    To do ATT BOOST calibration the first thing is to get valid by running CSL_SerdesWaitForRxValid() I used Lane number 1 and lane number 0 as well as 2 and 3 for good measure. None of them return a valid.

    I do the same thing while the FPGA connection is in PCIe mode. i.e., there is a PCIe on the other side and I can do lsspci -v and verify that the link is up. I do the same thing and again  CSL_SerdesWaitForRxValid() never return with lane valid signal. 

    Ziad A.

  • Guru 62440 points

    In reply to user5923610:

    Hi,

    When you run the PCIE test (the one with lspci and link up), is that correct that FPGA has some setting into PCIE mode? And in the K2HK side you used the PCIE driver example under pdk_k2hk_4_0_xx\packages\ti\drv\pcie\example\sample. This RTOS PCIe driver also called CSL_SerdesWaitForRxValid() with serdes_lane_enable_params.operating_mode = CSL_SERDES_FUNCTIONAL_MODE; The code passed, correct? And which lane (0, 1, 2, 3) has this signal detection valid? Is it lane 1?

    When you run the PRBS31 test, you have some configuration that made FPGA into PRBS31 transmission mode, and K2H side is the RTOS diagnostics pdk_k2hk_4_0_xx\packages\ti\diag\serdes_diag with CSL_SERDES_DIAGNOSTIC_MODE? We have this tested with K2H to K2H connection and didn't have any issue? Is it possible that FPGA PRBS31 generation problem?

    Regards, Eric
  • In reply to lding:

    I'll double check the first issue with the driver and get back to you. I assume you are right but have not looked into the driver code much since it has been working fine.

    But regarding what I am doing, is that I run the CSL_SerdesWaitForRxValid() with PCIe up and I tested all Lane numbers. Non read back a valid.

    I also did the same experiment with the FPGA driving PRBS31 and I see no difference in the results from  CSL_SerdesWaitForRxValid().

    Ziad

  • In reply to user5923610:

    Hi Eric,

    I talked to our software team about the driver code and they mentioned that since our system is Linux, we are not using the drivers you mentioned. Furthermore, they indicated that CSL_SerdesWaitForRxValid() does not seem to be used in the driver used.

    Does this help?

    Ziad 

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.